Первоначальные размышления о Web-сервисах

Web-службы дают нам новую парадигму сопровождения электронного бизнеса, вводя ориентированную на сервисы архитектуру для приложений, основанных на стандартах XML. Поскольку стандарты XML открыты, такие сервисы могут быть реализованы на любой платформе, которая поддерживает такие стандарты. Платформа JavaTM 2, Enterprise Edition (J2EE) является основной платформой, поддерживающей разработку таких Web-служб, использующих существующие технологии J2EE. Программа J2EE BluePrints дает рекомендации по архитектуре, руководящие принципы дизайна и инструкции, которые помогают разработчикам наиболее эффективно использовать платформу J2EE и различные технологии на ее основе. В этой статье мы рассмотрим несколько основных идей программы J2EE BluePrints о развивающемся мире Web-служб.

Потребность в BluePrints при работе с Web-службами

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

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

Далее рассматриваются конкретные случаи и даются некоторые рекомендации, которые могут помочь в создании Web-служб. Набор перечисленных ниже рекомендаций является предварительным и, по мере развития технологий Web-служб, программа BluePrints будет расширять и обновлять этот список.

Представляем приложение J2EE как Web-службу

При рассмотрении архитектуры, основанной на Web-службах, первый вопрос, который приходит в голову, заключается в том, что же происходит с существующими корпоративными приложениями? Необходимо ли нам отказаться от всех из них и начать заново? Простой ответ - НЕТ. Бизнес-логика существующих приложений может быть легко повторно использована и представлена в виде Web-служб на основе платформы J2EE.

Платформа J2EE позволяет разрабатывать приложения, которые смогут обслуживать множество различных типов клиентов (Web-клиенты, клиентские приложения, клиенты MIDP, КПК и др.) Первый пример приложения в программе J2EE BluePrints, Java Pet Store, показывает, как построить законченное приложение J2EE, основанное на архитектуре Model-View-Controller (MVC). Эта архитектура позволяет разработчику отделить модель приложения от логики управления и отображения. Паттерн проектирования Front Controller (который представлен как часть приложения Java Pet Store Demo) представляет гибкий способ взаимодействия между представлением и контроллером приложения. Такой гибкий способ взаимодействия делает добавление и модификацию представлений очень простой. Таким образом, проект приложения, основанный на архитектуре MVC, позволяет создавать новое представление приложения, используя старую бизнес-логику. Одно из представлений может быть реализовано в виде Web-службы, как это показано на рисунке.



Рис. 1: Создаем представление в виде Web-службы для сужествующих приложений J2EE

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

Обрабатываем запросы к Web-службам

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

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

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


<BillingRequest>
    <CustomerName>customer1</CustomerName>
    <CustomerId>1234</CustomerId>
    <UserDetails>
    <Name>John Doe</Name>
    <AcctNo>12345678</AcctNo>
    <PIN>9999</PIN>
    </UserDetails>
    <PaymentDetails>
        <BankName>Some Bank</BankName>
        <RoutingNo>12345678901234</RoutingNo>
        <Amount>1234.12</Amount>
    </PaymentDetails>
</BillingRequest>

Пример 1: Первый формат биллингового запроса.

<BillingRequest>
    <CustomerName>customer2</CustomerName>
    <CustomerId>6789</CustomerId>
    <Details>
        <BankName>Some Bank</BankName>
        <AcctNo>12345678</AcctNo>
        <RoutingNo>12345678901234</RoutingNo>
        <PIN>9999</PIN>
        <Amount>1234.12</Amount>
    </Details>
</BillingRequest>

Пример 2: Второй формат биллингового запроса.


Биллинговая Web-служба может принять решение сделать эти две различных формы запросов более удобными и гибкими для клиента. Какой бы ни была причина принятия двух различных форм запроса одной Web-службой, биллинговой службе может потребоваться только информация об учетной записи, направлении и форме платежа для выполнения транзакции в интересах клиента. В таком случае, вместо повсеместной обработки двух различных форм запросов, гораздо проще для Web-службы следовать общему внутреннему формату при дальнейшей обработке. Такой общий внутренний формат может быть похож на приведенный в примере 3 документ XML:

<BillingRequest>
    <CustomerId>6789</CustomerId>
    <AcctNo>12345678</AcctNo>
    <PIN>9999</PIN>
    <RoutingNo>12345678901234</RoutingNo>
    <Amount>1234.12</Amount>
</BillingRequest>

Пример 3 : Общий внутренний формат биллингового запроса.


Общий формат упростит обработку, хотя это и потребует от провайдера Web-служб предварительно обрабатывать запрос, для того чтобы убедиться, что он содержит всю необходимую информацию, и преобразовывать его в этот внутренний формат. Безусловно, будет правильным реализовать предварительную обработку и преобразования непосредственно в компонентах Web – при этом любая ошибка во входящем запросе будет обработана перед тем, как начнется основная обработка запроса. Это сохранит драгоценное время и позволит избежать излишних трюков на уровне компонент EJB, в которых находится бизнес-логика. Поддержка единственного внутреннего формата запроса избавляет бизнес-логику от необходимости включать в себя знания о различных форматах запросов. Это уменьшает связность приложения и позволяет сделать очень простым добавление других форматов запросов для новых клиентов. Встроенная поддержка XSLT в интерфейсах программирования приложений JAXP позволяет эффективно использовать эти интерфейсы для предварительной обработки и преобразований.

Безопасность: Во время предварительной обработки входящих запросов безопасность также должна контролироваться Web-службой непосредственно на уровне компонент Web. SSL является наилучшим решением для обеспечения безопасности. Добавим, что имя пользователя и пароль также могут быть включены в каждый запрос. Еще один способ обеспечения безопасности заключается в том, чтобы регистрировать клиентов Web-службы в офлайне и предоставлять онлайновый доступ к службе посредством основанного на формах механизма авторизации платформы J2EE.

Обработка документа: После того, как пользователь был авторизован и документ проверен на корректность, следующим шагом будет обработка содержимого XML-документа. Обработка XML-документа может быть выполнена двумя способами: посредством DOM и посредством SAX. Интерфейсы программирования приложений (API) Java для обработки XML (JAXP) поддерживают оба способа обработки.API Объектной Модели Документа (DOM) преобразует документ в дерево, которое легко может быть просмотрено для получения необходимой информации. SAX API преобразует документ XML в серии событий, которые обрабатываются определенными пользователем способами. Рисунок 2 иллюстрирует оба способа обработки XML-документов.



Рис. 2: Способы обработки XML-документов: SAX и DOM

Ниже описаны основные моменты, которые разработчик Web-служб должен учесть при принятии решения, какой способ обработки использовать для разбора XML-документов.

Разбор документов с использованием DOM: Эта модель обработки XML склонна к интенсивному использованию памяти и каналов передачи информации. Тем не менее, программирование с использованием DOM API очень просто, поскольку эти интерфейсы программирования дают возможность так же эффективно строить дерево, как и его просматривать. Доступность программных интерфейсов более высокого уровня, таких как JDOM и DOM4J, поверх DOM позволяет значительно упростить разбор документов DOM. Объектные модели DOM особенно полезны в том случае, если документ XML подвергается изменениям в процесс обработки запроса. Это возможно потому, что очень легко добавлять, удалять или изменять содержание XML-документа представленного в виде дерева DOM. Построение дерева XML-документа и его использование лучше всего реализуется в рамках одной виртуальной машины Java. При взаимодействии с другими системами или виртуальными машинами будет лучше обслуживать документ в виде XML, а не в виде DOM, поскольку сериализация крупных объектов DOM является весьма ресурсоёмкой. К тому же, если запрос к Web-службе порождает многоступенчатый процесс обработки, может оказаться лучшим решением разделять входящие XML-документы в логические фрагменты DOM и передавать соответствующий фрагмент на соответствующий шаг обработки. Реализация такого механизма позволит уменьшить излишнюю обработку цельного XML-документа на различных шагах обработки.

В качестве примера рассмотрим XML-документ, приведенный ниже. Этот запрос может прийти к Web-службе, которая реализует функциональность Центра обработки заказов. XML-документ содержит полную информацию – такую как персональная информация о пользователе, детали заказа, информация о заказанном товаре и способе доставки и др. - то, что необходимо для обработки заказа, размещенного клиентом. Для весомости аргументов будем считать, что документ большой.

<CustomerOrder>
    <UserDetails>
        <Name>John Doe</Name>
        <UserId>doedoe</UserId>
        <CredirCard>4354543545</CreditCard>
        <CardType>VISA</CardType>
        <Expiry>10/2005</Expiry>
        <!-- Other User information -->
    </UserDetails>
    <OrderDetails>
        <OrderId>1234</OrderId>
        <OrderType>URGENT</OrderType>
        <!-- Other Order information -->
    </OrderDetails>
    <ItemDetails>
        <ItemName>some item</ItemName>
        <ItemId>KJ3423</ItemId>
        <!-- Other Item information -->
    </ItemDetails>
    <ShippingDetails>
        <Name>John Doe</Name>
        <Street>1234, some street</Street>
        <!-- Other Address information -->
    </ShippingDetails>
</CustomerOrder>

Пример 4: XML-документ, содержащий детали заказа.


Для обработки заказа, Web-служба должна реализовать полный процесс обработки. К примеру, эта Web-служба должна получить подтверждение платежеспособности кредитной карты пользователя, убедиться, что заказанные товары доступны, подтвердить заказ и т.д. XML-документ, вероятно, будет существовать до завершения всего процесса обработки. Имеет смысл обрабатывать документ, используя DOM, т.е. создавая дерево DOM и используя его в течение всего процесса. Также может быть принято решение хранить состояние процесса обработки как часть XML-документа. В этом случае модель DOM является идеальной, поскольку дерево DOM легко модифицировать. Если планируется реализовать процесс на основе архитектуры Enterprise JavaBeansTM, реализованной во многих виртуальных машинах, или с использованием других Web-служб, имеет смысл разделить большой документ на логические фрагменты, например, фрагмент, представляющий персональные данные (UserDetails), фрагмент представляющий детали заказа (OrderDetails) и т.д. Эти фрагменты могут быть посланы отдельным реализациям рабочего процесса для дальнейшей обработки. Таким образом, везде можно избежать обработки всего XML-документа.

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

Обработка с использованием SAX: Этот способ обработки XML предлагает последовательный доступ к содержанию XML-документов. Он является действительно быстрым, хотя программирование с использованием SAX сложнее, чем программирование с использованием DOM. SAX идеально подходит для XML-документов, которые читаются однократно и обрабатываются так, что в документе не происходит никаких изменений. В качестве примера рассмотрим документ, содержащий конфигурационную информацию. Предположим также, что XML-документ - большой.

<ConfigInfo>
    <ServerName>someserver</ServerName>
    <ServerPort>7000</ServerPort>
    <Protocol>HTTPS</Protocol>
    <Login>YES</Login>
    <!-- Other configuration information -->
</ConfigInfo>

Пример 5: XML-документ с информацией о конфигурации.


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

Формируем ответ Web-службы

После обработки запроса настает время для генерации содержания ответа. Также как и входящий запрос, ответ также должен быть XML-документом. Формирование содержания посредством DOM наиболее удобно в данном случае. Гибкость, которую предоставляет дерево DOM по отношению к модификации, оказывается весьма кстати при создании ответа. Является хорошей практикой генерировать ответ непосредственно перед отправкой в Web-компонентах службы. Формирование ответа на уровне web-компонент позволяет настраивать формат ответа, используя при этом общий внутренний формат для обработки запроса. Это дает возможность упростить бизнес-логику и избежать дублирования кода. Формирование ответа на уровне компонент Web также дает возможность собирать всю требуемую информацию перед построением ответа. Таким образом, исключается полный обход дерева DOM.Существует также дополнительное преимущество применения единообразных преобразований ко всем ответам, когда это производится на уровне компонент Web. Такие преобразования могут быть осуществлены либо посредством использования механизма Servlet Filters, либо посредством тегов JavaServer PagesTM.

Стили взаимодействия Web-служб

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

Первое, на что нужно обратить внимание, это обмен сообщениями. Протокол Простого Доступа к Объектам (SOAP) развивается в качестве стандарта обмена XML-документами. SOAP является сетевым протоколом на линиях IIOP и JRMP. Этот протокол основан на текстовой информации и использует формат кодирования данных, основанный на XML, и HTTP/SMTP для передачи сообщений. SOAP не зависит от языков программирования, используемых на платформе, на которой исполняется приложение. В связи с этим, SOAP является перспективным стандартом для обмена сообщениями между Web-службами. Программные интерфейсы Java для обмена сообщениями на XML (Java API for XML Messaging, JAXM) поддерживают обмена сообщениями на SOAP. Конечно, надо заметить, что хотя SOAP и является развивающимся стандартом для обмена сообщениями, также может быть использована передача XML-документа посредством метода HTTP POST.

При рассмотрении частого обмена множеством сообщений, содержащих незначительное количество информации, становится очевидной некоторая неэффективность этого процесса. Необходимо всегда учитывать тот факт, что создание сообщения SOAP требует некоторых накладных расходов. Некоторая цена есть и у отправления сообщений SOAP. Так что, вместо отсылки небольших порций информации туда и обратно (другими словами, создавая хорошо гранулированный доступ к информации), обмен информацией должен происходить в сгруппированном виде. Хорошо гранулированный обмен сообщениями снижает производительность. Другие важные затраты при хорошо гранулированном доступе возникают при передаче данных по сети в виде задержек и ограничений на ширину канала. Такой доступ делает разработку Web-служб затруднительной ввиду повышенной осторожности, с которой надо отнестись к обработке ошибок (например, отладке и обработке тех ошибок, которые возникают на стадии разработки хорошо гранулированного доступа, и т.п.) Отсылка информации как части запроса и отсылка всех ответов за один раз упрощает проектировку и обработку ошибок и повышает производительность.

Следующее что надо учесть, это уровень связности. Это можно также представить как спор между RPC и обмене сообщениями, основанном на документах. Хорошей практикой является использовать основанный на документах обмен поверх SOAP. При таком подходе XML документ (который содержит запрос) передается как часть полезной нагрузки сообщения SOAP. Адресат получает полезную наргузку, разбирает XML-документ и отвечает. Такой обмен сообщениями приведет к уменьшению связности, поскольку у взаимодействующих объектов нет нужды знать об удаленных методах. Более того, поскольку все существенные данные передаются как часть документа, все взаимодействия будут содержательными.

Web-службы и интеграция с традиционными системами

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

Платформа J2EE с готовностью отвечает на этот вопрос. Архитектура Connector, реализованная на основе платформы J2EE, позволяет традиционным системам соединяться и использоваться приложениями J2EE. На рисунке 3 схематично показана архитектура, использующая Web-службы для интеграции с традиционными системами.



Рис. 3 : Интеграция традиционных систем с Web-службами

Архитектура J2EE Connector определяет стандарт для связи платформы J2EE с гетерогенными корпоративными информационными системами (КИС). В число КИС можно включить ERP-системы, СУБД, мэйнфреймовые системы обработки транзакций и традиционные приложения, написанные не на языке программирования Java. Определяя набор масштабируемых и безопасных механизмов, основанных на транзакциях, архитектура J2EE Connector позволяет интегрироваться КИС с серверами приложений и корпоративными приложениями.

Таким образом, как показано на рисунке 3, традиционные системы могут быть связаны с корпоративными приложениями, запущенными на платформе J2EE, что может быть представлено как Web-служба. Это позволяет быстрее выводить на рынок продукты, использующие J2EE, без переделки традиционных систем. Это также позволяет воспользоваться преимуществами сильно интегрированной обработки транзакций и особенностями в обеспечении безопасности традиционных систем. Ничего не стоит, в случае если нет существенной бизнес-логики, получить доступ к традиционным системам через связующее звено архитектуры Connector, прямо с уровня Web-компонент (JSP/сервлетов) или напрямую из программ на Java.

Заключение

В этой статье обсуждались некоторые ранние идеи программы J2EE BluePrints в мире Web-служб и новые возможности платформы J2EE, которые позволят разрабатывать Web-службы. Были представлены некоторые идеи, как существующие корпоративные приложения на платформе J2EE и традиционные системы могут предоставлять свои функции в качестве Web-служб. Обсуждались также некоторые предварительные идеи о том, как обрабатывать входящие запросы к Web-службам и генерировать ответы. Как только открытые стандарты XML окончательно сформируются и появятся реализации технологий Web-служб, программа J2EE BluePrints будет поддерживать обновление списка лучших советов, принципов разработки и примеров приложений, которые позволят разработчикам расширить существующие приложения и создать новые, разрабатывая Web-службы.

Теги: web services