Главная » Java, Web, XML » Сервлеты класса JAXMServiet

0

Класс JAXMServiet добавляет к классу HttpServiet три метода. Первый метод

protected static MimeHeaders getHeaders (HttpServletRequest req);

заносит все поля HTTP-заголовка запроса req в объект класса MimeHeaders. Второй метод

protected void putHeaders(MimeHeaders headers, HttpServletResponse resp);

формирует HTTP-заголовок ответа resp из заранее подготовленного объекта headers.

Третий метод

public void static setMessageFactory(MessageFactory factory);

заносит В сервлет экземпляр factory класса MessageFactory.

В                          JAXMServlet Всегда есть объект класса MessageFactory.

Это защищенное (protected) поле сервлета. Оно называется Объект, на который ссылается msgFactory, по умолчанию создается в методе init () обычным для системы JAXM методом: msgFactory = MessageFactory.newlnstance();

Кроме введения трех новых методов и переопределения метода init (), создающего объект msgFactory, класс JAXMServlet реализовал один из методов doxxx(), а именно метод doPost (). Эта реализация вначале читает HTTP- заголовок и содержимое запроса:

MimeHeaders headers

InputStream is = req.getlnputStream() ;

и воссоздает исходное SOAP-послание в виде объекта класса soAPMessage, ИСПОЛЬзуя объект msgFactory:

SOAPMessage msg = msgFactory. createMessage (headers, is);

Затем SOAP-послание msg передается на обработку методу onMessage(). Об этом методе поговорим чуть ниже.

Если сервлет обслуживает асинхронный прием посланий, не требующих ответа, то на этом работа метода doPost () и сервлета заканчивается, а в объект resp заносится код ответа сервера "204 No Content".

Если же сервлет работает по принципу Р2Р, осуществляя синхронную передачу посланий, то в объект resp заносится результат работы метода onMessage (). Он-то и будет ответом SOAP-сервера на запрос клиента.

На этом метод doPost о завершает свою работу.

Таким образом, в сервлете класса JAXMServlet обработка SOAP-послания и формирование ответа на него выполняется не методом doPost а методом onMessage (), не ВХОДЯЩИМ В класс JAXMServlet. Метод onMessage () Должен быть определен во всяком классе, расширяющем класс JAXMServlet, но не переопределяющем его метод Post о .

Кроме того, сервлет, расширяющий класс JAXMServlet, реализует собой либо Web-службу, работающую с клиентом синхронно, либо Web-службу, работающую асинхронно. Реализация осуществляется так. ‘ Если Web-служба будет работать асинхронно, то сервлет должен реализовать интерфейс OnewayListener, если СИНХрэННО — интерфейс ReqRespListener. В каждом из этих интерфейсов описано всего по одному методу. Это и есть тот метод onMessage () , О котором МЫ говорили.

В интерфейсе OnewayListener метод onMessage О не возвращает результат, его заголовок таков:

public void onMessage(SOAPMessage msg);

В интерфейсе RegRespListener результатом метода будет новое SOAP- послание:

public SOAPMessage onMessage (SOAPMessage msg) ;

Если метод возвратил null, то ответ не будет передан клиенту.

Итак, если мы хотим создать синхронную Web-службу, основанную на пакете SAAJ, то расширяем класс JAXMServiet и реализуем интерфейс ReqRespListener, определяя метод onMessage о . Схема сервлета такова:

import javax.xml.messaging. *;

public class SyncSAAJServlet extends JAXMServiet implements ReqRespListener {

public SOAPMessage onMessage(SOAPMessage msg) {

// Разбираем послание msg, формируем ответное послание…

}

}

Если же мы решили создать асинхронную Web-службу на основе пакета JAXM, то в сервлете, расширяющем класс JAXMServiet, следует реализовать интерфейс OnewayListener. Вот схема такого сервлета:

import javax.xml .messaging. *;

public class AsyncJAXMServlet extends JAXMServiet implements OnewayListener!

public void                       msg){

// Разбираем послание msg…

}

}

В листинге 6.7 показана реализация синхронной Web-службы, выводящей полученное послание в свой стандартный вывод и посылающей клиенту подтверждение в получении запроса. Реализация сделана в системе SAAJ сервлетом, который мы назвали AckJAXMServlet.

jp Листинг®^ Сервлет, отправляющий клиенту подтверждение                                                 |

import javax.xml.messaging.*; import j avax. xml. soap. * ;

public class AckJAXMServlet extends JAXMServlet

implements ReqRespListener { public SOAPMessage onMessage (SOAPMessage msg) { try{

System.out.println("Содержимое пслученнсгс запроса:\п") ; msg.writeTo(System.out);

SOAPMessage reply = msgFactory.createMessage(); SOAPEnvelope env = reply.getSOAPPart().getEnvelope();

env.getBody().addChildElement(

env.createName("Response"))

. addTextNode ("Запрос получен. ") ;

return reply;

}catch(Exception e) {

System.err.println(e);

return null;

}

}

}

Послания процедурного стиля

Процедурный стиль SOAP-послания, предполагающий вызов удаленной процедуры, расположенной на SOAP-сервере, и получение ее результата, реализован в технологии Java пакетом JAX-RPC. Впрочем, средства пакета JAX-RPC позволяют реализовать и документный стиль SOAP-посланий.

Реализация пакета JAX-RPC основана на механизме обращения к методам удаленных объектов RMI (Remote Method Invocation), с которым можно познакомиться, например, по книге [10]. Механизм RMI так глубоко спрятан в пакет JAX-RPC, что вы можете ничего про него и не знать. Он проявляет себя только в том, что удаленные объекты должны реализовать интерфейс, расширяющий интерфейс Remote из пакета java. rmi. Такой интерфейс называется удаленным (remote) или распределенным (distributed) интерфейсом. Про интерфейс Remote тоже можно ничего не знать, потому что он пуст, он не содержит констант и заголовков методов. Пометка "extends Remote" в заголовке удаленного интерфейса означает только, что объекты этого типа будут распределенными объектами, доступными удаленным клиентам.

Итак, при создании Web-службы средствами JAX-RPC сначала записывается удаленный интерфейс, а Web-служба строится как реализация этого удаленного интерфейса.

Суть механизма RMI заключается в том, что после того как клиент обратился к методу удаленного объекта, на его машину пересылается программный код, называемый заглушкой (stub). Заглушка оформлена как класс Java, реализующий удаленный интерфейс, но реализация содержит не Web- услуги, а средства сетевого соединения, создания SOAP-посланий, включая их сериализацию, и средства пересылки SOAP-посланий.

На сервере тоже создается дополнительный профаммный код, называемый серверной заглушкой или связкой (tie). Связка получает сообщение от клиентской заглушки, десериализует содержащееся в нем SOAP-послание, извлекает из него аргументы Web-услуги и передает их Web-службе. Результат выполнения Web-услуги проходит обратный путь. Он сериализуется связкой и пересылается клиентской заглушке. Та десериализует полученное сообщение, извлекает из даго результат Web-услуги и передает клиенту как результат обращения к удаленному методу. Эта схема показана на рис. 6.2.

Таким образом, с точки зрения клиента создается обычный локальный объект Java, и обычным образом выполняются его методы, как будто они работают прямо на клиентской машине.

Рис. 6.2. Механизм JAX-RPC

Литература:

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

По теме:

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