В
первой статье было введение в основные интерфейсы JTAPI, а именно: JtapiPeer, провайдер, адрес, терминал, вызов и соединение. Это основа, на которой мы будем опираться и продолжим в этой статье.
Начиная с этой статьи, я оставлю простую теорию и углублюсь в объекты Jtapi, используя примеры кода. Разумеется, каждый фрагмент кода будет поддерживаться соответствующей теорией для разработки и глубокого анализа каждого объекта.
Эта итерация будет сконцентрирована на интерфейсах JTapiPeer и Provider и представит способ дальнейшего использования внутри приложения с использованием двух примеров классов. Первый ProviderService в основном показывает, как использовать JtapiPeer для создания экземпляра и предоставления объекта Provider для второго класса JTapiDiscovery, целью которого является просто обнаружение адресов и терминалов из домена поставщика.
Предварительные условия для исходного кода
Для того чтобы скомпилировать и запустить исходный код, вам нужна библиотека JTapi в вашем пути к классам и, конечно же, УАТС, оснащенная соответствующими программными службами JTAPI. Большинство поставщиков УАТС бесплатно предоставляют реализацию библиотеки JTapi для своей платформы. Для любой помощи, пожалуйста, оставьте комментарий.
ProviderService: полезный вспомогательный класс для остальной части руководства
Учитывая, что создание провайдера является первым шагом для любого приложения, я решил создать вспомогательный класс ProviderService, который будет использоваться в оставшейся части учебника для извлечения провайдера из JTapiPeer.
Класс ProviderService следует следующим образом:
package org.devrealm.jtapitutorial.bootstrap;
import javax.telephony.JtapiPeer;
import javax.telephony.JtapiPeerFactory;
import javax.telephony.JtapiPeerUnavailableException;
import javax.telephony.Provider;
public class ProviderService {
private static ProviderService instance;
private static Provider provider;
private ProviderService() {
bootStrap();
}
private void bootStrap(){
try {
JtapiPeer peer = JtapiPeerFactory.getJtapiPeer("");
String[] myServices = peer.getServices();
String providerString=myServices[0]+
";login=user;passwd=passwd";
provider = peer.getProvider(providerString);
} catch (JtapiPeerUnavailableException e) {
e.printStackTrace();
}
}
public static Provider getProvider(){
if (instance == null){
instance = new ProviderService();
}
return provider;
}
}
ProviderService — это вспомогательный класс, который реализует шаблон Singleton (см. Раздел Ресурсы ). Класс предоставляет открытый статический метод getProvider, который возвращает объект Provider для любого другого класса, запрашивающего его.
Помимо обычных одноэлементных вещей, этот класс представляет метод bootStrap () строка 17. Используя этот метод, класс создает объект Provider и делает его доступным.
Напомним из предыдущей статьи, интерфейс JTapiPeer представляет конкретную реализацию API телефонии Java от поставщика. Поэтому первое, что делает этот класс, — это получение экземпляра JTapiPeer с использованием статического метода JtapiPeerFactory, JtapiPeerFactory.getJtapiPeer («»), как вы можете видеть в строке 19. Имея экземпляр JTapiPeer на месте, метод bootStrap извлекает все доступные сервисы, которые может предоставить этот узел (строка 20).
- В зависимости от реализации этого интерфейса поставщиком может быть получено более одной услуги, если, например, объект программного обеспечения телефонии подключен к более чем одной подсистеме телефонии (например, услуга / сервер JTapi, подключенная к двум УАТС, приведет к двум службам).
Следующим шагом является создание providerString в строке 21, который будет включать соответствующую службу, имя пользователя и пароль для пользователя службы JTapi. Имея providerString в руках, мы продолжаем и запрашиваем Provider у JTapiPeer с помощью метода peer.getProvider (provideString) в строке 23.
Важные вещи для запоминания из этого класса:
- Использование JtapiPeerFactory.getJtapiPeer («»); мы получаем реализацию поставщика API-интерфейса Java-телефонии (строка 19).
- Имея в виду JtapiPeer, мы создаем строку providerString, которая состоит из службы Jtapi (в большинстве случаев будет только одна), имя пользователя и пароль для этой службы (строка 21).
- Из объекта JtapiPeer мы извлекаем объект Provider, используя Provider provider = peer.getProvider (providerString); (строка 23).
Имейте в виду, что вышеупомянутые три простых шага являются основой для инициализации всех приложений Java-телефонии.
Далее мы переходим к классу JTapiDiscovery, где провайдер начинает действовать.
JTapiDiscovery: поставщик в действии
Одна из вещей, которую должно делать любое приложение JTapi, — это сначала извлечь все доступные адреса и терминалы (или иным образом все запрошенные адреса и терминалы) и, возможно, поместить их в область хранения, чтобы позже использовать из остальной логики приложения. , Это именно то, что делает следующий класс, JTapiDiscovery .
Класс JTapiDiscovery следует следующим образом:
package org.devrealm.jtapitutorial.discovery;
import javax.telephony.Address;
import javax.telephony.Provider;
import javax.telephony.ResourceUnavailableException;
import javax.telephony.Terminal;
import org.devrealm.jtapitutorial.bootstrap.ProviderService;
public class JTapiDiscovery {
public static void main(String[] args) {
Provider provider = ProviderService.getProvider();
//Print all the available addresses of the system.
try {
Address[] addresses = provider.getAddresses();
System.out.println("Avaialable Addresses : ");
for (int i = 0; i < addresses.length; i++) {
System.out.println("Address : "
+addresses[i].getName());
}
} catch (ResourceUnavailableException e) {
e.printStackTrace();
}
//Print all the available terminals of the system.
try {
Terminal[] terminals = provider.getTerminals();
System.out.println("Avaialable Terminals : ");
for (int i = 0; i < terminals.length; i++) {
System.out.println("Terminal : "
+terminals[i].getName());
}
} catch (ResourceUnavailableException e) {
e.printStackTrace();
}
//Always remember to shutdown the provider,
//otherwise the application won't return.
provider.shutdown();
}
}
Поэтому класс JTapiDiscovery , использующий предыдущий класс ProviderService , сначала получает объект Provider (строка 13) и начинает работать с этим.
Если вы посмотрите на Javadoc Jtapi, интерфейс провайдера предоставляет набор полезных методов для извлечения адресов, терминалов, возможностей и т. Д. Из домена провайдера. Таким образом, в строке 17 извлекается и распечатывается массив адресов. Аналогично, в строке 28 извлекается и распечатывается массив терминалов.
Обратите внимание, что это не фактический объект, который распечатывается, а имя адреса или рассматриваемого терминала каждый раз. Как мы увидим в следующих статьях, интерфейс Address или Terminal среди других методов предоставляет метод getName () для получения уникального имени объекта. Метод getName () является основным способом взаимодействия с конечными пользователями, поскольку объект Address известен пользователю только по его имени, например по добавочному номеру его телефонного аппарата.
Также обратите внимание, что методы Provider provider.getAddresses () и provider.getTerminals () генерируют исключение типа ResourceUnavailableException, которое должно обрабатываться, когда, например, кто-то запрашивает адрес или терминал, который не существует или не предоставляется этой службой Jtapi.
Наконец, в строке 39 вызывается метод Provider provider.shutdown () . Этот метод запрашивает у Поставщика переместить состояние Provider.SHUTDOWN и приложение для возврата. Состояния провайдера и переходы между состояниями — следующий вопрос для обсуждения.
Государства провайдера
Объект Provider может находиться в любом из следующих трех состояний:
- Provider.IN_SERVICE: это состояние указывает на то, что провайдер в настоящее время активен и доступен для использования.
- Provider.OUT_OF_SERVICE: это состояние указывает, что поставщик временно недоступен для использования. Многие методы в API телефонии Java недопустимы, когда поставщик находится в этом состоянии. Поставщики могут вернуться к работе в любое время, однако приложение не может предпринять никаких прямых действий, чтобы вызвать это изменение .
- Provider.SHUTDOWN: Это состояние указывает на то, что поставщик навсегда больше не доступен для использования. Большинство методов в API телефонии Java недопустимы, когда поставщик находится в этом состоянии. Приложения могут использовать метод Provider.shutdown () в этом интерфейсе, чтобы провайдер перешел в состояние Provider.SHUTDOWN.
Когда сначала создается экземпляр Provider с использованием метода JtapiPeer.getProvider (providerString) , возвращаемый объект Provider находится в состоянии IN_SERVICE и может использоваться сразу.
Когда приложение вызывает provider.shutdown () , поставщик переходит в состояние SHUTDOWN, JTAPI постоянно теряет связь с подсистемой телефонии, и приложение может предположить, что поставщик больше не будет работать, поэтому приложение должно обработать полное завершение работы. Приложения вызывают метод Provider.shutdown (), когда они больше не намереваются использовать поставщика, как правило, непосредственно перед выходом. Этот метод предназначен для того, чтобы позволить Провайдеру выполнить любую необходимую очистку, которая не будет обрабатываться, когда объекты Java собираются мусором. Метод
Provider.shutdown () приводит к тому, что поставщик переходит в состояние Provider.SHUTDOWN, где он будет оставаться неопределенно долго. Если поставщик уже находится в состоянии Provider.SHUTDOWN, этот метод ничего не делает.
Также полезным для разработчика может быть метод Provider, provider.getState () . Этот метод возвращает постоянное целочисленное значение, которое обозначает состояние поставщика следующим образом:
- Provider.IN_SERVICE: постоянное значение 16
- Provider.OUT_OF_SERVICE: постоянное значение 17
- Provider.SHUTDOWN: Постоянное значение 18
На рисунке ниже показаны допустимые переходы состояний для объекта Provider.
Вывод
Любое приложение Java Telephony, которое вы планируете реализовать, будет использовать объект Provider в качестве исходного объекта для начала взаимодействия с подсистемой телефонии. Интерфейс Provider предоставляет дополнительные методы, которые здесь не обсуждались, но будущие статьи, в которых будет описываться остальная часть будущего JTapi, представят весь потенциал интерфейса Provider.