Главная » Java, Web, XML » Протокол WS-Routing и его реализация

0

Протокол WS-Routing (Web Services Routing Protocol), разработанный корпорацией Microsoft в 2001 году (http://msdn.microsoft.com/library/en-

предназначен для создания и отправки SOAP-посланий, не требующих ответа и подтверждения получения. Послание, отправленное по протоколу WS-Routing, может на своем пути пройти несколько промежуточных серверов (actors), которые могут сделать предварительную обработку послания (forward message path). Это делает и обычное SOAP-послание, но протокол WS-Routing, в отличие от протокола SOAP, определяет точный порядок прохождения промежуточных серверов. Это позволяет спланировать последовательность обработки послания промежуточными серверами. Хотя протокол не предназначен для двусторонней связи, он позволяет отследить обратный путь (reverse message path) для посылки ответного послания.

Послание, созданное по правилам протокола WS-Routing, можно отправить не только по протоколам HTTP или SMTP, но и прямо по протоколу TCP или UDP, причем промежуточные серверы могут по своему усмотрению менять транспортный протокол.

Итак, главная цель протокола WS-Routing — обеспечить точный маршрут прохождения SOAP-послания от отправителя до получателя. Дополнительно можно задать обратный маршрут. Для достижения этих целей в заголовок SOAP-послания <Header> вкладывается элемент <path>, в котором вложенным элементом                      указывается адрес URI отправителя, элементом <to> — адрес URI получателя, а элементами <via> — адреса URI промежуточных серверов. Элементы <via> записываются внутри элемента <fwd> и показывают маршрут от отправителя к получателю. Порядок прохождения промежуточных пунктов соответствует порядку записи элементов <via>. Обратный маршрут, если он нужен, указывается элементами <via>, вложенными в элемент <rev>. Все эти элементы определены в пространстве имен с идентификатором

Простейшее послание не содержит промежуточных адресов и адреса отправителя. Оно выглядит примерно так:

<env:Envelope

xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Header>

<m:path xmlns:m= "http: //schemas .xmlsoap.org/rp/">

<m:action>http://s ome.com/update</m:act ion> <m:to>soap://D.com/endpoint;up=udp</m:to>

<m: id>uuid: 09233523-345b-4351-b623-5dsf35sgs5d6</m: id> </m:path> </env:Header>

<env:Body>

< ! — Содержимое послания… —>

</env:Body> </env:Envelope>

В этом примере показаны еще два обязательных элемента SOAP-послания, составленного по протоколу WS-Routing.

Обязательный элемент <action> указывает строкой URI программу-обработчик послания.

Обязательный элемент <id> содержит строку URI, однозначно идентифицирующую данное послание. Это полезно для связи друг с другом подряд идущих посланий или для ссылки ответного послания на послание, вызвавшее ответ. Ссылка производится элементом  например:

<relatesTo>uuid:09233523-345b-4351-b623-5dsf35sgs5d6</relatesTo>

Заметьте, что адрес получателя в элементе <to> указан строкой URI со схемой soap:. Эта схема URI ко времени написания книги еще не была утверждена комитетом IETF, хотя ее введение давно витает в воздухе. Схема soap: аналогична схеме http:, но добавляет параметр up (underlying protocol), указывающий транспортный протокол. По умолчанию принимается протокол TCP.

Если надо указать промежуточные серверы, например,             и              то к

посланию добавляется элемент <fwd> и вложенные в даго элементы <via>:

<env:Envelope

xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">

<env: Header>

<m:path xmlns :m="http: //schemas. xmlsoap. org/rp/"> <m:action>http://some.com/update</m:action> <m:to>soap://D.com/endpoint</m: to> <m: fwd>

<m:via>soap://В.com</m:via> <m: viaosoap://C. conK/m: via> </m:fwd>

<m:id>uuid:09233523-345b-4351-b623-5dsf35sgs5d6</m:id>

</m:paith> </env:Header>

<env:Body>

< ! — Содержимое послания… —> </env^:Body>

</env:Envelope>

Наконец, если нужно указать обратный путь, то добавляются элементы <frorn> И <rev>:

<env:Envelope

xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Header>

<m:path xmlns:m="http://schemas.xmlsoap.org/rp/">

<m:action>http://www.notification.org/update</m:action> <m:to>soap://D.com/endpoint</m:to>

<m:fwd>

<m:via>soap://B.com</m:via> <m:via>soap://C.com</m:via>

</m:fwd>

<m:rev>

<m:via/> </m:rev>

<m:from>mailto:ivanov@some.com</m:from>

<m:id>uuid:09233523-345b-4351-b623-5dsf35sgs5d6</m:id>

</m:path>

</env:Header>

<env:Body>

<!—Содержимое послания… —> </env:Body>

</env: Envelope>

В этом примере пустой элемент <m:via/> указывает, что выбор обратного пути возлагается на транспортный протокол.

В стандартную поставку JAXM ЖДЛ" пакет com. sun.xml.messaging, jaxm.soaprp, содержащий всего два класса — SOAPRPMessageFactorylmpl И

SOAPRPMessagelmpl — реализующих протокол WS-Routing и создающих SOAP-послания с профилем, названным "SOAP-RP".

Класс soAPRPMessageimpi расширяет класс soAPMessage, поэтому его экземпляр можно создать приведением экземпляра класса soAPMessage, полученного методом createMessage О , К нужному типу:

SOAPRPMessagelmpl soaprpMsg =

(SOAPRPMessagelmpl)mf.createMessage();

Затем, методами класса soAPRPMessageimpi и методами, унаследованными от класса soAPMessage, создаем SOAP-послание профиля SOAP-RP. При этом полезны следующие методы класса soAPRPMessageimpi:

•          public void newMessageido — создает элемент <id> и его содержимое — уникальный идентификатор послания;

?         public void setAction (Endpoint actor) —создает элемент <action> С

адресом actor;

?        public void setFrom (Endpoint from) — создает элемент <from> с адре

сом отправителя from;

•         public void setTo (Endpoint to) — создает элемент <to> с адресом получателя to;

•         public void setRelatesTo (String id) — создает ССЫЛКУ <relatesTo> на послание с идентификатором id;

?        public void updateFwdMessagePath (Endpoint actor, int position) — добавляет элемент <via> с адресом actor в позицию position элемента <fwd>;

?         public void updateRevMessagePath (Endpoint actor) — добавляет Элемент <via> с адресом actor в начало элемента <rev>.

При разборе послания полезны аналогичные методы:

•         public string getSOAPRPMes sage Id () — возвращает содержимое элемента <id> — уникальный идентификатор послания;

•          public Endpoint getsOAPRPAction () — возвращает содержимое элемента <action>;

•          public Endpoint getFrom () — возвращает содержимое элемента <from> с адресом отправителя;

?      public Vector getSOAPRPFwdMessagePath () — возвращает содержимое

элемента <fwd>;

?    public Vector getSOAPRPRevMessagePath () — возвращает содержимое элемента <rev>.

После создания и/или изменения послания следует обратиться к методу

public void saveChanges();

Пример использования этих методов приведен в листинге 6.4.

Связь с поставщиком сообщений

Связь с поставщиком сообщений устанавливается одним из двух способов.

Первый способ — связаться с заранее определенным поставщиком, называемым поставщиком по умолчанию. Это осуществляется последовательным применением двух методов класса ProviderConnectionFactory:

ProviderConnectionFactory pcf = ProviderConnectionFactory. newlnstance () ; ProviderConnection pc = pcf. createConnection () ;

Второй способ — найти поставщика сообщений через систему именования JNDI (Java Naming and Directory Interface) (см., например, [10]) по его JNDI-имени:

Context ctx = new

ProviderConnectionFactory pcf =

(ProviderConnectionFactory)ctx.lookup("SomeProvider");

ProviderConnection pc =

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

И В ТОМ, И В Другом случае получаем объект рс типа ProviderConnection. Интерфейс ProviderConnection описывает четыре метода работы с поставщиком услуг.

Установив связь с поставщиком, надо получить сведения о нем первым методом интерфейса ProviderConnection:

public ProviderMetaData getMetaData () ;

Этот метод заносит сведения о поставщике в объект типа ProviderMetaData. Объект содержит имя поставщика и номер версии поставщика, состоящий из двух чисел                                                               записанных через точку, вроде "1.2". Их можно получить методами

public String getName () ; public int getMajorVersionO ; public int

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

public String[] getSupportedProfiles () ;

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

Создание SOAP-послания и его отправка

Создание SOAP-послания осуществляется методами класса MessageFactory из пакета SAAJ, так же, как это делалось в предыдущем разделе этой главы, но сначала надо получить экземпляр класса MessageFactory вторым методом интерфейса ProviderConnection

public MessageFactory createMessageFactory(String profile);

Затем, используя полученный экземпляр, создаем SOAP-послание с дополнениями, если они нужны, и отправляем его получателю. Создание послания сильно зависит от выбранного профиля. В листинге 6.4 создается SOAP-послание профиля SOAP-RP.

Отправка SOAP-послания выполняется третьим методом интерфейса ProviderConnection:

public void send (SOAPMessage message);

Как видите, метод send () не возвращает никакого значения и не требует, чтобы клиент, пославший сообщение, ждал ответа. Тем не менее, после работы надо закрыть связь с поставщиком четвертым методом интерфейса

ProviderConnect ion.;

public void close О;

Листинг 6.4 показывает пример клиента системы JAXM, создающего SOAP- послание профиля  с дополнением.

? Листинг 6.4. Создание и асинхронная отправка SOAP-послания

import j ava.net.*; import javax.xml.messaging.*; import j avax.xml.soap.*; import javax.activation.*;

import com.sun.xml.messaging.jaxm.soaprp.*; public class Client JAXM {

public static void main (String [ ] args) {

String from ="http://same.com/soaprp/sender"; String to = "http://another.com/soaprp/reeeiver";

try{

EToviclerCbnneetionFaetory pcf =

ProviderConnectionFactory.newlnstance(); ErcviderCbnneetion pc = pcf.createConnection();

EroviderMetaData metaData = pc. getMetaData (); string[] supportedProfiles =

metaData.getSupportedProfiles(); String profile = null;

for (int i=0; i < supportedProfiles.length; i++){

if (supportedProfiles[i].equals("soaprp")){ profile = supportedProfiles[i]; break:;

)

}

MessageFactory =

SOAPRPMessagelmpl soaprpMsg =

(SOAPRPMessagelmpl)mf.createMessage();

soaprpMsg.setFrom(new Endpoint(from)); soaprpMsg.setTo(new Endpoint(to));

URL =

new

=

soaprpMsg.createAttachmentPart(new DataHandler(uri));

ар.setContentType("text/xml");

soaprpMsg.addAttachmentPart(ap);

pc.send(soaprpMsg);

pc.close();

}catch(Exception e) {

System.err.println(e);

}

}

}

Итак, мы научились писать клиентские приложения Web-служб на основе пакетов SAAJ и JAXM. Посмотрим, как можно создавать SOAP-серверы с помощью этих пакетов.

В технологии Java SOAP-серверы реализуются классами специального вида, называемыми сервлетами. Сервлеты подробно описаны в книгах [10, 11]. Нам не обязательно знать все тонкости их создания и употребления, приведем здесь только необходимые сведения о них.

Литература:

Хабибуллин И. Ш. Разработка Web-служб средствами Java. — СПб.: БХВ-Петербург, 2003. — 400 с: ил.

По теме:

  • Комментарии