43. Очереди сообщений. Jms

Java Message Service (JMS) — стандарт промежуточного ПО для рассылки сообщений, позволяющий приложениям, выполненным на платформе J2EE, создавать, посылать, получать и читать сообщения. Коммуникация между компонентами, использующими JMS, асинхронна (процедура не дожидается ответа на своё сообщение) и независима от исполнения компонентов.

JMS поддерживает две модели обмена сообщениями: «от пункта к пункту» и «издатель-подписчик».

Модель «от пункта к пункту» характеризуется следующим:

Каждое сообщение имеет только одного адресата

Сообщение попадает в «почтовый ящик», или «очередь» адресата и может быть прочитано когда угодно. Если адресат не работал в момент отсылки сообщения, сообщение не пропадёт.

После получения сообщения адресат посылает извещение.

Модель «издатель-подписчик» характеризуется следующим:

Подписчик подписывается на определённую «тему»

Издатель публикует своё сообщение. Его получают все подписчики этой темы

Получатель должен работать и быть подписан в момент отправки сообщения

44. Веб сервисы. Soap

Web-сервисы. В самом общем виде понятие Web-сервиса можно определить как сервис (услугу) которая предоставляется через WWW с использованием языка XML и протокола HTTP.

Web-сервисы могут инкапсулировать как простейшие бизнес-функции типа «запрос-ответ», до полномасштабных взаимодействий бизнес-процессов. Службы могут создаваться заново или строиться на основе существующих приложений методом «обертывания».

Свойства Web-сервисов. Все Web-сервисы обладают имеют следующими свойствами:

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

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

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

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

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

• открыты и основаны на стандартах, технической основой Web-сервисов являются XML и HTTP, значительная часть технологии Web-сервисов создана с использованием проектов с открытым исходным кодом;

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

• являются динамическими, поскольку имеется возможность обнаруживать службы в процессе функционирования, при этом имеется возможность из распространения не влияя на работу клиентов, которые их используют;

• являются действенным средством интеграции унаследованных приложений.

SOAP – это основанный на XML протокол, определяющий механизм обмена сообщениями. Протокол SOAP появился в 1998 году как W3C спецификация. В ранних версиях спецификации SOAP расшифровывался как Simple Object Access Protocol. В последних версиях этот термин не никак расшифровывается. На момент написания данной книги последней была версия 1.2 от апреля 2007 года (спецификация находится по адресу http://www.w3.org/TR/2007/).

Хотя SOAP имеет много общего с XML-RPC, но имеются и принципиальные отличия. Во-первых протокол SOAP не различает вызов процедуры и ответ на него, а просто определяет формат послания (message) в виде документа XML, который может содержать вызов процедуры, ответ на него, запрос на выполнение каких-то других действий или просто текст, а, во вторых, SOAP послание представляет собой самоописываемый документ, включающий, в частности, описания пространств имен. Структуру SOAP послания определяет соответствующая XML Schema. Для пересылки SOAP посланий обычно используется HTTP POST метод, хотя можно использовать и другие протоколы, такие как FTP, SMTP.

SOAP послание включает два элемента: заголовок (Header) и тело (Body), которые помещаются в контейнер (Envelope). SOAP послание представляет собой правильный XML документ. Заголовок является факультативным элементом, а тело – обязательным.

В качестве примера рассмотрим пример сервера, который находит синоним слова с посредством вызова метода getSynonym.

<?xml version="1.0" encoding="Windows-1251"?>

<SOAP-ENV:Envelope

SOAP-ENV:encodingStyle=

"http://schemas.xmlsoap.org/soap/encoding/"

xmlns:SOAPENV="

http://schemas.xmlsoa.org/soap/envelope/"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:SOAPENC="

http://schemas.xmlsoap.org/soap/encoding/">

<SOAP-ENV:Body>

< getSynonym>

<word xsi:type="xsd:string">аэроплан</word>

< </getSynonym >

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

В теле запроса в элемент word, который имеет тип XSD string, помещается исходное слово. В ответ на запрос клиенту поступает ответное послание, которое имеет вид:

<?xml version="1.0" encoding=" Windows-1251"?>

<SOAP-ENV:Envelope

xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<SOAP-ENV:Body>

<getSynonymResponse

SOAP-ENV:encodingStyle=

"http://schemas.xmlsoap.org/soap/encoding/">

<getSynonymResult xsi:type=

"xsd:string">самолет</getSynonymResult>

</getSynonymResponse>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Рассмотрим пример создания простейшей службы, которая может находить синоним.

Имеется много разных систем поддержки работы с Web-сервисами. Одной из популярных является Apache eXtensible Interaction System (AXIS).

Создание серверной части не вызывает проблем. Для работы с AXIS достаточно написать текст сервиса. Для этого создаем файл SynonymService.java:

// SynonymService.java

public class SynonymService {

public String getSynonym(String word) {

//Находим в словаре требуемый синоним

…………….

//Возвращаем синоним

return "" + synonym;

}

}

Данный файл необходимо переименовать в SynonymService.jws и не компилируя поместить в каталог webapps (при работе с AXIS). После этого сервис готов к использованию

Клиентская часть приложения сложнее. При работе с AXIS вначале создается объект класса service, который предназначен для установления связи с Web сервисом. Он предоставляет экземпляр класса call, который заносятся параметры запроса, в частности, адрес и имя Web-сервиса "getSynonym". После того как запрос сформирован, Axis обращается к Web-услуге посредством вызова метода invoke (). Запрос направляется серверу приложений, работающему по указанному в запросе адресу. На сервере запускается сервлет AxisServiet, который разбирает SOAP послание, находит требуемый .jws файл, компилирует и запускает с требуемыми параметрами. После выполнения требуемых действий сервлет формирует SOAP послание в которое помещается результат. Послание отправляется клиенту. Там оно разбирается. Для клиента результат доступен как результат выполнения метода invoke () [36].