Содержание


Разработка конвергентных приложений нового поколения с применением SIP и асинхронных Web-сервисов

Comments

С развитием таких технологий, как мгновенный обмен сообщениями, телефония на базе интернет-протокола (IP) и видео поверх IP, начала появляться новая волна приложений, объединяющих несколько технологий поверх IP. Чтобы поддерживать эти технологии, такие как Session Initiation Protocol (SIP) и IP Multimedia System (IMS), поставщикам телекоммуникационных услуг (TSP) требуется обеспечить соединение и обмен информацией между новыми сетями IMS и старыми системами, такими как сети Transaction Capabilities Application Part (TCAP) и Signaling System #7 (SS7). Для асинхронного соединения двух сетей разрабатываются новые конвергентные приложения на основе SIP и Web-сервисов.

В этой статье для обсуждения передовых методов и накопленного опыта при разработке приложений, готовых к производственной эксплуатации, мы будем использовать TCAP-приложение. Обсуждение затрагивает следующие вопросы.

  1. Каковы преимущества и недостатки использования в сети TSP синхронных Web-сервисов по сравнению с асинхронными?
  2. Как разработать конвергентное приложение нового поколения с применением SIP и Web-сервисов?
  3. Как синхронизировать SIP- и HTTP-сервлеты в конвергентном приложении?
  4. Следует ли подумать об использовании HTTP KeepAlive для повышения качества связи?
  5. Как разрабатывать и отлаживать приложения при их тестировании на производительность и надежность? Это необходимо для развертывания телекоммуникационных приложений операторского класса в сети TSP.

Синхронные и асинхронные Web-сервисы в сети сервис-провайдера

При разработке конвергентных приложений ответные сообщения на вызовы Web-сервисов могут передаваться синхронно или асинхронно.

Однако все не так просто. Есть два уровня, на которых можно провести черту между ними. Сообщение может быть синхронным или асинхронным на уровне приложения, при этом код приложения либо ожидает ответного сообщения, либо немедленно передает управление и позднее, когда приходит ответ, информирует приложение с помощью обратного вызова.

Сообщение может быть синхронным или асинхронным и на уровне связи, когда контейнер либо ожидает низкоуровневых ответов по "проводу", либо продолжает обработку и передает ответ, когда тот в конечном итоге приходит по "проводу" в другом потоке.

Таким образом, существуют четыре возможных конфигурации:

  • синхронное приложение синхронной связью;
  • синхронное приложение с асинхронной связью;
  • асинхронное приложение с синхронной связью;
  • асинхронное приложение с асинхронной связью.

Ответные сообщения коммуникационного уровня

При разработке конвергентных приложений за обработку ответных сообщений на коммуникационном уровне отвечает контейнер. По умолчанию обработка этих ответов осуществляется синхронно, так что контейнер ждет ответного сообщения и не продолжает обработку в этом потоке.

Для достижения асинхронной связи необходимо установить свойство com.ibm.websphere.webservices.use.async.mep в контексте клиентского запроса с логическим значением true. Когда это свойство задействовано, к сообщениям запроса и ответа добавляются заголовки WS-Addressing, содержащие дополнительную информацию о маршрутах. Затем эти сообщения, когда они поступают, обрабатываются в другом потоке контейнера. Это освобождает текущий поток, позволяя обрабатывать другие задачи, не дожидаясь ответного сообщения.

Передача сообщений синхронными приложениями Web-сервисов

При синхронной передаче сообщений приложением Web-сервиса код приложения блокируется в ожидании ответного сообщения. Это имеет ряд преимуществ и недостатков.

Преимущества:

  • более простой код, так как нет необходимости обрабатывать контекст – сообщение обрабатывается в процессе передачи;
  • меньше состязаний, так как все сообщения обрабатываются последовательно в коде без необходимости прерывать поток обратными вызовами;
  • упрощается отладка, так как все сообщения обрабатываются последовательно, и поток не разбивается обратными вызовами и прерываниями.

Недостатки:

  • если вызов остается зависшим, это может привести к проблемам биллинга, потому что приложение не может обрабатывать входящие вызовы, пока они ожидают ответных сообщений. Чем больше время ожидания, тем более несправедливой будет плата, взятая с абонента;
  • из-за синхронного поведения приложения, которое дожидается каждого сообщения, требуется больше ресурсов при меньшей интенсивности вызовов.

Синхронный метод, хотя он и проще, не обеспечивает надежности и не отвечает требованиям приложения в сети TSP.

Передача сообщений асинхронными приложениями Web-сервисов

При разработке асинхронных Web-сервисов существуют два способа обработки ответов: опрос и обратный вызов.

В сети TSP важно, чтобы ответ на запрос Web-сервиса обрабатывался сразу после его получения контейнером. Поэтому в этой статье мы сконцентрируемся на использовании метода обратного вызова. Этот метод возвращает управление приложению, чтобы оно могло продолжать обработку других сообщений, не ожидая ответного сообщения. Этот метод более регулярный, чем метод опроса, и гарантирует, что ответ будет обработан немедленно. Метод опроса допускает задержки из-за отсутствия реагирования и цикла опроса.

В следующем примере кода показано, как использовать обработчик обратных вызовов. Контейнер вызывает этот обработчик, когда получает ответ Web-сервиса на отправленный ранее запрос.

Листинг 1. Пример кода, определяющего класс обработчика асинхронных обратных вызовов
// Определение обработчика асинхронных обратных вызовов
ServiceCallbackHandler asyncHandler = new ServiceCallbackHandler(param1,param2);
// Запуск обработчика обратных вызовов
Future<?> response = AsyncResponseMessage(message, asyncHandler);

// Определение класса обработчика обратных вызовов
public class ServiceCallbackHandler implements AsyncHandler<SendResponse> {	
// Определение параметров, передаваемых обработчику обратных вызовов
private int param1 = 0;
private SipApplicationSession param2 = null;		
// Определение метода обработчика асинхронных обратных вызовов
	public ServiceCallbackHandler(int param1, SipApplicationSession param2) {
			param1 = dialogId;
			param2 = appSession;
	}

	public void handleResponse(
		Response<SendResponse> response) {
		// Сюда добавляется логин предприятия	
	}
}

Некоторые из преимуществ метода обратного вызова:

  • ответ обрабатывается немедленно, без ожидания;
  • приложение может продолжать обработку и обработать больше трафика, поскольку ресурсы не связаны необходимостью ожидания ответов;
  • приложение не заблокировано в ожидании ответа. Это позволяет ему в любое время немедленно обрабатывать вызовы SIP, такие как отбой, а также генерировать правильные записи биллинга.

Эти преимущества очень важны в среде сервис-провайдера, так как с абонента берется плата только за время разговора и, возможно, за дополнительные ресурсы и услуги. Кроме того, для достижения удовлетворенности абонентов очень важно, чтобы звонки обрабатывались как можно быстрее.

Недостатки метода обратного вызова:

  • в случае ошибки, если ответ потерян, он может оставить ресурсы зависшими;
  • код может оказаться более сложным. Существует необходимость согласования сеансов, чтобы гарантировать, что ответное сообщение относится к нужному вызову;
  • требуется дополнительная обработка ошибок и очистка кода;
  • объект Future не упорядочиваем, что означает, что в среде высокой готовности управление, возвращаемое обработчиком обратных вызовов, реплицироваться не может. Это означает, что когда происходит переключение на другой ресурс, отменить необработанные обратные вызовы не представляется возможным.

Эти недостатки усложняют разработку, но не перевешивают преимущества.

Разработка конвергентных приложений нового поколения с применением SIP и Web-сервисов

Новым телекоммуникационным приложениям требуется доступ как к традиционным сетям, так и к сетям нового поколения. Этого можно добиться путем разработки конвергентных приложений, использующих протокол SIP для взаимодействия с сетью следующего поколения и HTTP для доступа к традиционным протоколам. В этой статье, чтобы проиллюстрировать это, мы будем использовать пример приложения TCAP. У нашего приложения есть SIP-интерфейс, обеспечивающий связь с сетью IMS, а также интерфейс HTTP, который общается с TCAP через Web-сервисы. Наше приложение нового поколения размещается в WebSphere Application Server Network Deployment и использует основные возможности WebSphere.

В данном примере приложение запускается, когда сервер приложений получает новый SIP-вызов. Затем приложение инициирует транзакцию TCAP с интерфейсом Web-сервиса TCAP.

Для этой статьи мы используем простой поток вызовов, как показано на рисунке 1, чтобы имитировать простое приложение TCAP. Для простоты на рисунке не показаны процесс обработки заголовков Session Description Protocol (SDP) и ISDN, сообщения промежуточного медиасервера SIP и сообщения, которые могут потребоваться для имитации других частей обмена TCAP, таких как дополнительные сообщения Begin.

Рисунок 1. Пример последовательности вызова SIP/TCAP
Пример последовательности вызова SIP/TCAP
Пример последовательности вызова SIP/TCAP

Обзор примера конвергентного приложения нового поколения на основе SIP и TCAP

Приложение состоит из трех основных взаимодействий:

  1. Обработка входящих сеансов SIP.
  2. Генерация событий запроса TCAP:
    1. отправка исходящего запроса Web-сервиса TCAP;
    2. обработка входящего ответа Web-сервиса TCAP.
  3. Прием событий индикации TCAP:
    1. обработка входящего запроса Web-сервиса TCAP;
    2. отправка исходящего ответа Web-сервиса TCAP.

Мы предполагаем, что вы знакомы с методами разработки стандартных сервлетов SIP JSR 116. Было бы полезно также ознакомиться со спецификацией TCAP JSR 11, описывающей протокол TCAP. Оба архива JSR доступны на Web-сайте Java Community Process.

Конвергентное приложение состоит из двух основных частей. Первая часть представляет собой сервлет SIP для обработки входящих и исходящих SIP-сообщений. В результате этих SIP-сообщений сервлет SIP инициирует исходящий запрос Web-сервиса (в данном случае конвергентное приложение выступает в роли клиента Web-сервиса). Вторая часть – это сервлет HTTP, который используется для обработки любых входящих вызовов Web-сервисов (в данном примере конвергентного приложения он выступает в качестве сервера Web-сервисов). Оба компонента имеют общую структуру данных, которая называется данными приложения.

Разработка сервлета SIP

Сервлет SIP разработан с использованием стандартных методов программирования сервлетов SIP JSR 116. Более подробную информацию о том, как разрабатывать SIP-сервлеты, можно почерпнуть из следующих статей DeveloperWorks: Протокол инициирования сеанса в WebSphere Application Server V6.1. Часть 1 и Часть 2.

Функция init() – это стандартная функция init() JSR 116. Основная обработка входящих и исходящих сообщений SIP осуществляется в стандартном блоке обработки doInvite() JSR 116. В этой статье мы не будем описывать процесс программирования сервлетов SIP, а вместо этого сосредоточимся на тех аспектах, которые относятся непосредственно к отправке и приему Web-сервисов TCAP.

Первым шагом будет обработка сообщения SIP INVITE и ответ 200 OK. Следующий шаг – создание сообщения TCAP BEGIN с соответствующими параметрами диалога и компонентов. Чтобы постепенно построить объект запроса, нужно написать ядро кода приложения TCAP с помощью сеттеров и геттеров TCAP (таких как setQualityOfService()).

Кроме того, нужно задать некоторые уникальные параметры для каждого вызова, такие как dialogID. Для этого мы создали вспомогательный метод getNewDialogueId() для генерации уникальных идентификаторов dialogID для данного конкретного сеанса TCAP. Программист должен написать код реализации, который действительно создает уникальный идентификатор для каждого вызова. Сгенерированный dialogID сохраняется в объекте applicationData следующим образом: applicationData.setDialogId(utils.getNewDialogId(applicationData));

На следующем шаге создается закодированный URI, который позднее, когда приложение будет обрабатывать запросы Web-сервисов, переданные ему из интерфейса TCAP, будет использоваться для создания конфигурации сродства сеансов (session affinity). Для этого сначала извлекается IBMApplicationSession , а затем вызывается encodeURI(), как показано в листинге 2. При сродстве сеансов сообщения, предназначенные для определенного сеанса приложения, всегда направляются в один и тот же сеанс в кластере.

Листинг 2. Пример кода, генерирующего шифрованный URI, который будет использоваться для сродства сеансов
IBMApplicationSession ibmSess = (IBMApplicationSession) appSession;

// Получение моей конечной точки HTTP
InetAddress in = InetAddress.getLocalHost();
appEncodedUri =
 ibmSess.encodeURI("http://"+in.getHostAddress()+":9080/tcap/AttTCAPHttpApp");

При развертывании приложения в кластерной среде оно должно использовать IP-адрес прокси-сервера, предстоящего кластеру серверов приложений, а не адрес хоста (in.getHostAddress()). Кроме того, если система имеет конфигурацию с балансировщиком внешней нагрузки и разрешенной переадресацией MAC-адресов, приложение должно использовать адрес обратной связи с присвоением балансировщику виртуального IP-адреса для создания шифрованного URI. Это особенно важно при переходе на резервный ресурс, когда WebSphere использует идентификатор сеанса приложения в шифрованном URI для маршрутизации запросов к репликам отказавших серверов приложений.

Отправка исходящих запросов

Теперь мы готовы отправить запрос, например, запрос TCAP Begin. Для этого вызовем метод sendWS(), который используется для настройки и передачи запроса Web-сервиса в интерфейс TCAP. Этот метод исключает много работы по программированию, необходимой для создания асинхронных запросов. Он использует JAX-WS для передачи асинхронного запроса SOAP через HTTP, а также устанавливает асинхронный callbackHandler для обработки ответа, описанный в разделе Передача сообщений асинхронными приложениями Web-сервисов. Разработчик TCAP-приложения должен определить callbackHandler так, чтобы он корректно обрабатывал асинхронные ответные сообщения Web-сервисов из интерфейса TCAP.

Мы используем зашифрованный URI, который мы получили ранее, чтобы обеспечить сродство сеансов приложения для данного конкретного запроса, как показано в листинге 3.

Листинг 3. Пример кода для создания зашифрованного URI в сообщении TCAP-запроса
// Включение шифрованного URI в сообщение запроса конкретного сеанса приложения
componentAndDialogRequest.setEncodedURI(applicationData.getAppEncodedUri());

После возврата sendBegin() мы фиксируем текущее состояние приложения TCAP, установив состояние объекта applicationData, которое сохранится в контексте сеанса приложения в случае отказа, как показано в листинге 4.

Листинг 4. Пример кода, меняющего состояние текущего вызова
// Установка соответствующего состояния после передачи Begin
applicationData.setState(Constants.BeginSentState);

Затем мы сохраняем его в сеансе приложения, как показано в листинге 5.

Листинг 5. Пример кода корректировки атрибута текущего вызова
// Сохранение данных приложения в сеансе приложения
appSession.setAttribute(Constants.APP_DATA, applicationData);

И, наконец, мы запускаем обработчик таймера, как показано в листинге 6, для обработки сценария, при котором обработчик обратных вызовов клиента Web-сервиса не отвечает, что приводит к тайм-ауту. Этот обработчик отвечает за обработку ситуации тайм-аута, разрешает ее с правильным последующим сообщением TCAP и, при необходимости, прекращает сеанс связи.

Листинг 6. Пример кода, вызывающего таймер для отслеживания состояния текущего вызова
// Запуск первого таймера для отслеживания ответа WS от интерфейса TCAP
timerService.createTimer(appSession, 
applicationData.getWSBeginSentWaitingForResponseTimer(), true,
	Constants.WSBeginSentWaitingForResponseTimer);

Обработка асинхронных ответных сообщений

Когда контейнер получает ответ на ранее отправленный запрос, он вызывает нужный метод обратного вызова. Ответное сообщение в клиенте обрабатывается обработчиком обратных вызовов путем реализации метода handleResponse() в классе ServiceCallbackHandler, как описано в разделе Передача сообщений асинхронными приложениями Web-сервисов.

Когда вызывается этот обработчик, сначала нужно получить текущий контекст приложения. Это делается с помощью dialogID, который мы использовали в запросе, как показано в листинге 7.

Листинг 7. Пример кода для извлечения сеанса вызова, связанного с обратным вызовом
// Получение уникального ID диалога из сообщения обратного вызова
dialogID = Integer.toString(response.get().getDialogId());

// Извлечение уникального ID диалога из сообщения обратного вызова
appSession = (SipApplicationSession) sContext.getAttribute(dialogID);
applicationData = (SampleApplicationData) appSession.getAttribute(Constants.APP_DATA);

Этот обработчик выполняет также всю необходимую обработку для прерывания сеанса SIP, например, при поступлении сообщения ABORT из TCAP-интерфейса. Вся эта обработка основана на текущем состоянии вызова, которое уже было установлено в запросе.

Разработка сервлета HTTP

Как уже говорилось, приложение выступает также в качестве сервера Web-сервисов путем внедрения HTTP-сервлетов. Таким образом, когда интерфейс TCAP получает сообщение от парного TCAP, он затем отправляет в приложение новый запрос Web-сервиса, содержащий события индикации.

Обработка входящего запроса Web-сервиса

Когда интерфейс TCAP получает входящий запрос (H1), он передает вызов нужному сеансу приложения, используя encodedURI из запроса. Для этого TCAP-интерфейс использует encodedURI, полученный ранее в сценарии вызова (WS1), и устанавливает это значение в конечной точке для исходящего запроса.

Для обработки этого сообщения нужно создать сервлет HTTP, расширив класс javax.servlet.http.HttpServlet следующим образом: public class SampleTCAPHttpApp extends javax.servlet.http.HttpServlet

Как и модель программирования сервлета SIP JSR 116, сервлет HTTP обеспечивает стандартные функции, такие как init(), doGet(), doPost() и т.п. В нашем случае мы запускаем функцию init(), поскольку некоторые вещи понадобятся во всех сеансах.

Сначала нужно создать новую messageFactory, а затем контекст JAXB, который будет использоваться для обработки запроса SOAP. Фактически есть два разных контекста JAXB, которые мы используем в примере приложения. Первый используется для чтения XML-файла конфигурации, второй – для печати объекта, который принят после демаршализации запроса SOAP (листинг 8).

Листинг 8. Пример кода создания нового контекста JAXB для обработки сообщения SOAP
msgFactory = MessageFactory.newInstance();
jbc = JAXBContext.newInstance(new Class[] { 
org.xmlsoap.schemas.soap.envelope.ObjectFactory.class,
listener.jain.protocol.ss7.tcap.ObjectFactory.class });
jbcpo = JAXBContext.newInstance("listener.jain.protocol.ss7.tcap");

Затем нужно заняться обработкой функции doGet(). Эта функция вызывается, когда из TCAP-интерфейса поступает запрос от Web-сервиса. Первое, что нам нужно сделать, это получить контекст сеанса приложения, а затем объект applicationData, который мы создали в стадии исходящего запроса, как показано в листинге 9.

Листинг 9. Пример кода для извлечения сеанса вызова, связанного с сообщением HTTP/SOAP
// Извлечение сеанса SipApplication для получения контекста.
HttpSession httpSession=request.getSession();
IBMSession extSession = (IBMSession)httpSession;
IBMApplicationSession ibmAppSession = extSession.getIBMApplicationSession();
SipApplicationSession appSession = (SipApplicationSession)ibmAppSession ;
SampleApplicationData applicationData = 
	(SampleApplicationData) appSession.getAttribute(Constants.APP_DATA);

Примечание. JSR289 исключает необходимость использования этих специальных интерфейсов для доступа к сеансу приложения.

Теперь мы можем передать запрос методу processReceivedMessage, который проанализирует и распечатает сообщение, как показано в листинге 10.

Листинг 10. Пример кода, преобразующего сообщение SOAP в объект Java
// Обработка полученного сообщения 
(анализ сообщения, его распечатка и
 изменение состояния приложения) 
componentAndDialogRequest = 
processReceivedMessage(request, headers, 
	applicationData, appSession);

Теперь запрос SOAP преобразован в объект Java™, и для доступа к данным можно использовать различные геттеры и сеттеры. После выхода из doGet() стек автоматически отправит ответ HTTP 200 OK, завершив этот диалог HTTP.

Итак, мы обработали сообщение и отправили ответ, но может быть и другая специфичная для приложения логика, которую нужно реализовать.

Синхронизация сервлетов SIP и HTTP в конвергентном приложении

Типичное конвергентное приложение нового поколения устанавливает связь с устройствами IMS с помощью сообщений SIP со стороны клиента, а также взаимодействует с ресурсами сети SS7 с помощью компонентов TCAP, встроенных в сообщения SOAP, со стороны сервера, как показано на рисунке 2. Вызов IMS, инициированный клиентом SIP, обычно запускает последовательность асинхронных событий TCAP между приложением нового поколения и интерфейсом стека TCAP. Например, после того как приложение нового поколения отправляет вызов Web-сервиса с сообщением BEGIN TCAP, интерфейс TCAP может вернуть приложению событие асинхронного обратного вызова с указанием результатов сообщения BEGIN, обработанного в сети SS7. Более того, интерфейс TCAP может инициировать и асинхронные вызовы Web-сервиса (например, сообщение CONTINUE TCAP), возвращаемые приложению. Приложение должно отслеживать и контролировать состояние каждого вызова на основе описанных выше событий SIP и TCAP и гарантировать, чтобы в исключительной ситуации (например, когда CALLBACK не поступает до истечения предельного срока), принимались соответствующие меры для отмены вызова и корректного перераспределения ресурсов сети.

Рисунок 2. Типичное конвергентное приложение нового поколения, взаимодействующее как с устройствами IMS, так и с традиционными ресурсами сети SS7
Типичное конвергентное приложение нового поколения
Типичное конвергентное приложение нового поколения

На рисунке 3 показано, как в нашей среде реализуется типичный высокоуровневый поток. Он иллюстрирует начало сеанса SIP, за которым следуют несколько запросов и ответов Web-сервисов.

Рисунок 3. Последовательность состояний примера приложения
Последовательность состояний примера приложения
Последовательность состояний примера приложения

Здесь конвергентное приложение контролирует и обрабатывает каждый вызов как конечный автомат. Событие S3 (сообщение ACK от клиента) запускает приложение для отправки WS1, первого события запроса Web-сервиса. Если в ответ на WS1 своевременно не поступит обратный вызов, приложение повторит передачу запроса WS1 до трех раз; затем передаст в интерфейс TCAP сообщение ABORT и прервет связь с клиентом. Если полученный обратный вызов указывает на ошибки при обработке сообщения WS1, конвергентное приложение также может прервать вызов. В противном случае приложение следит, поступил ли входящий асинхронный запрос Web-сервиса (H1 сообщение) в ожидаемые сроки. Если нет, приложение также может передать ABORT и прервать вызов. В противном случае оно может передать ответ H1, а также второй исходящий запрос Web-сервиса (WS2), который будет обработан точно так же, как WS1. Такое взаимодействие между конвергентным приложением и интерфейсом TCAP можно повторять много раз, пока клиент не завершит вызов (посредством SIP-сообщения BYE) или пока сеть SS7 не прервет связь (посредством TCAP-сообщения END).

Чтобы описанный выше конечный автомат функционировал правильно, конвергентное приложение должно синхронизировать SIP- и HTTP-сервлеты, установленные в конвергентном контейнере WebSphere Application Server. Это связано с тем, что экземпляр SIP-сервлета и экземпляр HTTP-сервлета, управляющие одним и тем же вызовом, как правило, работают в разных потоках. Если обоим сервлетам разрешается считывать и редактировать один и тот же конечный автомат без синхронизации, логика конечного автомата работать не сможет. Давайте рассмотрим, как эта проблема решается в нашей среде.

  • Событиями и обратными вызовами Web-сервиса SIP управляет только SIP-сервлет.
  • Только SIP-сервлет может отправлять исходящие сообщения Web-сервиса.
  • Сервлет HTTP управляет входящими запросами Web-сервиса, но не имеет прямого доступа к соответствующему конечному автомату. Вместо этого он получает обработчик для SIP -сервлета из памяти контекста. Единственный способ, которым он может обновить состояние или инициировать действие конечного автомата – это вызов процедуры SIP-сервлета посредством обработчика. Напомним, что это делалось в потоке Web-контейнера. Если в потоке SIP-контейнера происходит что-то еще, мы можем столкнуться с состоянием состязаний.
  • Процедуры SIP-сервлета, вызываемые HTTP-сервлетом, синхронизируются самим SIP-сервлетом.
  • В компоненте SIP-сервлета приложения используются таймеры SipAppliationSession. Это означает, что HTTP-сервлет не может получить прямой доступ или непосредственно управлять событиями тайм-аута, но может делать это через обработчика SIP-сервлета.
  • SIP-сервлет гарантирует, что новое событие тайм-аута не будет запущено для того же вызова, если в очереди ожидает другое событие тайм-аута или пока ожидание тайм-аута не будет отменено.

Использование HTTP KeepAlive для повышения производительности

Протокол HTTP имеет простую парадигму запрос-ответ. Когда клиент решает связаться с сервером, он открывает TCP-соединение, чтобы отправить на сервер сообщение HTTP-запроса. Затем сервер использует то же соединение, чтобы отправить клиенту ответное HTTP-сообщение. Транзакция завершается, когда закрывается соединение TCP-сокета. Этот сценарий повторяется для каждого запроса/ответа HTTP между клиентом и сервером. Такой медлительный и не очень эффективный подход вызывает значительные проблемы с производительностью.

HTTP KeepAlive решает эту проблему, значительно снижая накладные расходы, связанные с созданием и разрывом TCP-соединений. Он позволяет клиенту посылать несколько запросов по одному и тому же TCP-соединению, не разрывая его. Это делается путем отправки дополнительной информации заголовка в сообщениях запрос/ответ HTTP.

В нашем примере приложения мы реализовали HTTP KeepAlive в TCAP-интерфейсе для того, чтобы значительно повысить производительность. В WebSphere KeepAlive включен по умолчанию.

Отладка приложений при тестировании производительности и надежности сети

При разработке и внедрении телекоммуникационных систем операторского класса в сети TSP должны соблюдаться особые требования по эксплуатационной готовности, надежности и устойчивости. Одно из них заключается в том, что система и приложение должны иметь надежность в пять девяток и гарантировать высокую готовность, не имея единой точки отказа.

При полноценном развертывании приложений такого типа в сети TSP система подвергается особым испытаниям, называемым испытаниями на надежность сети. Это означает тестирование приложения под большой нагрузкой с имитацией различных условий отказа. Приложение должно быть в состоянии надлежащим образом обрабатывать отказы, регистрируя полезную информацию об ошибках. Кроме того, приложение должно полностью восстанавливаться после отказа под постоянной нагрузкой.

Важно также выполнить тщательное нагрузочное тестирование под полной нагрузкой, чтобы убедиться, что система или производительность не ухудшаются с течением времени. Для этого требуется выполнение нагрузочных тестов в течение 72 часов или более длительного времени.

Эта методология тестирования значительно затрудняет диагностику и устранение ошибок, которые очень трудно воспроизвести и которые происходят при большой интенсивности вызовов (листинг 1). Включение трассировки приводит к негативным последствиям и в условиях высокой интенсивности вызовов не очень эффективно.

Ниже приведены некоторые советы, которые помогут при отладке.

  1. Сделайте регистрацию лаконичной, чтобы записывалось минимальное количество сведений.
  2. Регистрируйте данные сообщения в сценариях ошибок. Когда возникает ошибка, в журнал должно записываться достаточно данных. Один из методов, который работает очень хорошо, - это запись истории нескольких последних сообщений в кольцевой буфер, откуда ее можно считать, когда возникает состояние ошибки. Важно отметить, что вызов, завершившийся ошибкой, может не быть причиной ошибки, которая могла произойти гораздо раньше. Данные, хранящиеся в памяти, должны содержать все регистрируемые события, вызванные сообщением во время своего прохождения. Это позволит увидеть поток не только неудавшегося сообщения, но и сообщений, предшествующих ему.
  3. Очистка условий ошибки. При возникновении ошибки выполняйте очистку. Это может быть прерывание сеансов, сброс таймеров, отмена обработчиков обратного вызова или очистка всех структур данных, которые могут в ней нуждается.
  4. Легко забыть, что таймеры нужно сбрасывать. При использовании таймеров для отслеживания событий и гарантии своевременного поступления сообщений очень важно сбросить эти таймеры, когда сообщение получено.
  5. Передайте информацию сеанса обработчику асинхронного вызова. Это предоставит вам доступ к дополнительным сведениям, которые нужно регистрировать при возникновении условия отказа.
  6. При запуске HTTP- и SIP-сервлетов позаботьтесь об инициализации общих данных приложения и запуске таймеров в функциях Init, так как первым может инициализироваться либо SIP-, либо HTTP-сервлет.
  7. Как было сказано в разделе Синхронизация SIP- и HTTP-сервлетов в конвергентном приложении, нужно позаботиться о том, чтобы SIP- и HTTP-сервлеты были правильно синхронизированы.

В процесс отладки может входить использование таких инструментов, как снифферы для записи сетевых пакетов. Проанализировав эти пакеты, можно увидеть поток сообщения и, самое главное, как долго сообщение передается между компонентами. Это поможет определить, не кроется ли проблема в компоненте, которому для обработки сообщения требуется слишком много времени.

Самая трудная часть отладки – это отслеживание пути сообщения в системе, так как оно может иметь разные идентификаторы в разных компонентах, и эти идентификаторы необходимо увязать друг с другом. Это возвращает нас к пункту о лаконичности записей и регистрации достаточного количества информации, чтобы проследить прохождение вызова в системе.

Примечание. Новый WebSphere Application Server V7 Feature Pack for Communications Enabled Applications (CEA) содержит множество новых функций, которые упрощают разработку конвергентных приложений. Одна из этих функций, называемая уведомлением конвергентных Web-сервисов (converged Web service notification), поддерживает сродство Web-сервисов как для исходящих, так и входящих запросов. Это упрощает наше приложение, поскольку больше не нужно создавать двунаправленные Web-сервисы.

Заключение

Из этой статьи вы узнали, как использовать инструментарий WebSphere Application Server для создания и отладки конвергентных приложений, поддерживающих как SIP, так и Web-сервисы. Эти конвергентные приложения позволяют соединить старые технологии традиционных сетей с новыми технологиями на основе IP-сети. Вы узнали о возможностях, которые можно выбрать в зависимости от требований приложения, включая синхронные или асинхронные Web-сервисы и использование HTTP KeepAlive для повышения производительности. Теперь вы умеете создавать приложения и принимать конструктивные решения на основе уроков, извлеченных из нашего примера приложения TCAP.


Ресурсы для скачивания


Похожие темы


Комментарии

Войдите или зарегистрируйтесь для того чтобы оставлять комментарии или подписаться на них.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=WebSphere, SOA и web-сервисы
ArticleID=646369
ArticleTitle=Разработка конвергентных приложений нового поколения с применением SIP и асинхронных Web-сервисов
publish-date=04112011