Еще одна документная модель?
Выпуск Apache Axis2 1.1 сулил множество замечательных возможностей приверженцам инфраструктрур Web-сервисов серии Apache. Мы рассмотрим сам Axis2 в одной из следующих публикаций, но в данной статье мы попытались проникнуть внутрь Объектной Модели AXIs (AXIOM) - модели XML документа, лежащей в основе Axis2. AXIOM - одна из основных инноваций в Axis2, и одна из причин того, что Axis2 показывает гораздо лучшие рабочие характеристики, чем оригинальный Axis. Данная статья познакомит вас с тем, как работает AXIOM, как AXIOM складывается из разных частей Axis2, и, наконец, как рабочие характеристики AXIOM соотносятся с рабочими характеристиками других объектных моделей документов Java™.
Документные модели - обычный подход к обработке XML. Для разработки Java доступны многие их виды, в том числе разные реализации исходной спецификации W3C DOM, JDOM, dom4j, XOM, и другие. Каждая модель претендует на наличие каких-то преимуществ по сравнению с другими, будь то рабочие характеристики, функциональная гибкость или строго соблюдаемое соответствие стандарту XML, и каждая имеет преданных сторонников. Итак, зачем Axis2 потребовалась новая модель? Для ответа на этот вопрос нужно знать, как структурированы сообщения SOAP, и, в особенности, как добавляются расширения к базовой инфраструктуре SOAP.
Обнаружение SOAP
Сам SOAP это просто тонкая оболочка, обертка, в которую заключена полезная XML информация приложения. В Листинге 1 приведен пример программы, где все элементы SOAP имеют префикс soapenv. Основную часть документа составляют данные приложения, являющиеся содержимым элемента soapenv:Body.
Листинг 1. Образец SOAP
|
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Header/> <soapenv:Body> <matchQuakes xmlns="http://seismic.sosnoski.com/types"> <min-date>2001-01-06T11:10:43.446Z</min-date> <max-date>2001-10-24T19:49:13.812Z</max-date> <min-long>-150.94307</min-long> <max-long>-22.594208</max-long> <min-lat>-11.44651</min-lat> <max-lat>55.089058</max-lat> </matchQuakes> </soapenv:Body> </soapenv:Envelope> |
Несмотря на простоту базовой оболочки SOAP, она делает возможной неограниченное добавление расширений посредством использования необязательного компонента header (заголовок). Заголовок обеспечивает место для добавления метаданных любого типа, которые сопутствуют данным приложения, будучи невидимыми ему (Вы можете включать данные приложения в заголовок, хотя нет убедительной причины, по которой вы бы предпочли сделать это вместо того, чтобы использовать компонент body (тело) для данных приложения). Расширения, добавляемые к SOAP (такие, как все семейство расширений WS-*) могут использовать заголовок для своих собственных целей, не влияя на приложение. Это позволяет расширениям действовать как самостоятельные дополнительные приложения, где конкретные функции расширения необходимые приложению могут быть выбраны во время ввода в действие, а не включены непосредственно в программный код.
В Листинге 2 показаны те же данные приложения, что и в Листинге 1, но с добавлением информации об адресации WS-Addressing. В то время, как исходное сообщение SOAP можно было бы, вероятно, передать лишь посредством транспортного протокола HTTP (поскольку HTTP обеспечивает двустороннее соединение для немедленной передачи ответа клиенту), приведенная в Листинге 2 версия может быть обработана и другими протоколами, поскольку имеет метаданные ответа, непосредственно включенные в SOAP сообщение с запросом. Было бы даже проще включить этап промежуточной буферизации передаваемых данных при обработке сообщения в Листинге 2, поскольку метаданные содержат информацию о координатах места, куда посылается запрос, и места, куда должен быть доставлен ответ.