Основы создание web - служб

Лабораторная работа.

Тема : «Создание web – служб»

1 Цель работы

Цель работы – создание web –службы для использования её приложениями и закрепить навыки создания распределенных приложений.

2 Основные теоретические положения

Генезис Web

Изначально World Wide Web была сетью документов. Web-серверы общались с клиентами по протоколу HTTP (Hypertext Transfer Protocol) и пересылали информацию в форме гипертекстовых документов, созданных средствами языка HTML (Hypertext Markup Language). Такие документы отображались в браузерах и содержали ссылки на другие документы. Этого было вполне достаточно для удовлетворения запросов создателей Web — ученых, которым было необходимо средство для обмена различными документами: результатами исследований, лабораторными протоколами, отчетами и т.п. Таким образом, Web появился как документно-ориентированная сеть.

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

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

Появление разнообразных мобильных устройств привело к тому, что вместо традиционных браузеров многие коммерческие Web-приложения теперь помимо протокола HTTP поддерживают и протокол WAP (Wireless Access Protocol) и способны возвращать информацию не только в стандарте HTML, но и в стандарте, удовлетворяющем пользователей, обращающихся к сервисам через мобильные устройства, — WML (Wireless Markup Language).

Естественно, электронная коммерция не может ограничиваться простой обработкой транзакций — следующим логических шагом в развитии Web стала интеграция бизнес-процессов различных компаний. Таким образом на свет появляется сервис-ориентированный Web. В его основе лежат две относительно новые технологии — SOAP (Simple Object Access Protocol) и XML (Extensible Markup Language). Согласно этому сценарию Web состоит из набора серверов приложений, обменивающихся информацией в формате XML по протоколу SOAP.

Основой сервис-ориентированного Web является Web-сервис — набор логически связанных функций, которые могут быть программно вызваны через Internet. Информация о том, какие функции предоставляет данный Web-сервис, содержится в документе WSDL (Web Service Description Language), а для поиска существующих Web-сервисов предполагается использование специальных реестров, совместимых со спецификацией UDDI (Universal Description, Discovery and Integration).

Сервис-ориентированный Web

Web-сервисы(службы) представляют собой технологию интеграции приложений, которая может использоваться в Internet. В качестве примера возможного использования Web-сервисов рассмотрим планирование путешествий. Обычно в такой ситуации требуются: заказ билетов на самолет, бронирование мест в гостинице, аренда автомобиля и, возможно, использование услуг местных компаний, организующих экскурсии.

Традиционно используя Internet, вам придется посетить сервер авиакомпании, сервер гостиницы или сети гостиниц, сервер компании по аренде автомобилей и сервер компании, специализирующейся на организации экскурсий в выбранном вами месте. Все эти действия могут занять достаточно много времени, прежде чем вы достигнете цели. И при этом ни одна из задействованных вами компаний не будет знать, каковы ваши планы, а следовательно, не сможет оптимизировать ваше время. Проблема заключается в том, что компании, специализирующиеся на отдельных областях — авиа, гостиничной, прокате автомобилей и т.п., в большинстве случаев замкнуты сами на себя и используют собственные средства хранения и представления данных.

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

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

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

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

Рассмотрев практическое применение Web-сервисов, обратимся к стандартам, лежащим в основе этих сервисов.

Стандарты для Web-сервисов

Как мы уже знаем, в основе Web-сервисов лежат Internet-стандарты. Эти стандарты определяют протоколы, а не способы их реализации. Такое утверждение является залогом успеха Internet — ни одна компания не может влиять на Internet-стандарты и задавать собственные правила игры. Например, стандарты Web-сервисов разрабатываются совместно такими компаниями, как IBM, Microsoft, Ariba и некоторыми другими, и обсуждаются комитетом World Wide Web Consortium (W3C).

Web-сервисы базируются на трех основных Web-стандартах:

• SOAP (Simple Object Access Protocol) — на протоколе для посылки сообщений по протоколу HTTP и другим Internet-протоколам;

• WSDL (Web Services Description Language) — на языке для описания программных интерфейсов Web-сервисов;

• UDDI (Universal Description, Discovery and Integration) — на стандарте для индексации Web-сервисов.

Рисунок 2 1

На рис. 2-1 показано, как эти три стандарта взаимодействуют друг с другим.

Серверы приложений являются хранилищами Web-сервисов и делают их доступными через протоколы HTTP GET, HTTP POST и HTTP SOAP.

Существующие Web-сервисы описываются в WSDL-документах, которые располагаются либо на сервере приложений, либо в специальных XML-хранилищах. WSDL-документ может ссылаться на другие WSDL-документы и документы XSD (XML Schema), в которых описаны типы данных, используемые Web-сервисами. XML-хранилища используются для управления WSDL-документами. Внутри WSDL-документа находится адрес (URL) Web-сервиса. Web-сервисы описаны и проиндексированы в бизнес-реестре, содержащем адреса (URL) WSDL-документов.

В следующих разделах мы рассмотрим три основных Web-стандарта, на которых базируются Web-сервисы SOAP, WSDL и UDDI, более подробно.

SOAP — Simple Object Access Protocol

SOAP — это стандарт для отсылки и получения сообщений по Internet. Изначально этот протокол был предложен фирмой Microsoft в качестве средства для удаленного вызова процедур (RPC, Remote Procedure Call) по протоколу HTTP, а спецификация SOAP 1.0 (Userland, Microsoft, Developmentor) была тесно связана с Component Object Model. Фирма IBM и ряд других компаний, в том числе Lotus, внесли определенный вклад в развитие этого протокола, и его стандарт был направлен на рассмотрение комитетом W3C.

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

SOAP-сообщения бывают двух типов: запрос (Request) и ответ (Response). Запрос вызывает метод удаленного объекта, ответ возвращает результат выполнения данного метода. На рис. 2 и 3 приведены примеры запроса и ответа в формате SOAP.

Рисунок 2 2

Рисунок 2 3

Спецификация SOAP определяет формат кодирования, который, в свою очередь, задает способ представления данных в XML-формате.

Одной из первых реализаций протокола SOAP была Java-версия, созданная фирмой Developmentor. Компания IBM выпустила собственную Java-версию, известную под названием IBM SOAP4J, доступную на