ИСМ-06-2:
37. Этапы создания Web-сервисов. Проблемы внедрения .
Этапы создания Web-службы:
1Создание приложения, реализующего функциональность Web-службы (класс Java или .Net, компонент EJB или COM, унаследованное приложение (legacy application), написанное, скажем, на COBOL или PL, хранимая процедура базы данных и т.д.)
2 Создание описания интерфейса Web-службы (чаще всего на языке WSDL (Web Services Description Language). Описание интерфейса определяет набор операций, которые поддерживает данная Web-служба, а также количество и тип параметров этих операций. Ссылка на интерфейс Web-службы может публиковаться в реестрах служб, таких, как UDDI .В некоторых случаях, однако, нет необходимости создавать в явном виде файл с описанием интерфейса, поэтому и этот шаг приходится выполнять не всегда.
3 Опубликование описания интерфейса в реестре служб. (необязателен, нужен если мы хотим, чтобы службу могли найти во внешнем (public) реестре служб и, возможно, вызвать)
4 Развертывание Web-службы на сервере (Web service deployment).
Два логических компонента участвуют в вызове Web-службы:
клиентское приложение, инициирующее вызов, и
серверная часть, принимающая запрос клиента и непосредственно осуществляющая вызов.
На шаге развертывания необходимо предпринять действия, которые позволят осуществить вызов Web-службы на стороне сервера. Необходимые для развертывания действия зависят от реализации Web-службы, платформы, на которой она работает, протокола, по которому ее вызывают, а также конкретных продуктов, обеспечивающих транспорт и среду работы Web-службы.
5 Создание описания реализации Web-службы.
Создание WSDL-документ, содержащего информацию о реализации службы. Этот документ должен содержать ссылку на интерфейс Web-службы, который он реализует, и также может публиковаться в реестрах служб, таких, как UDDI. Одному и тому же интерфейсу могут соответствовать несколько различных реализаций (и, соответственно, их описаний).
6 Опубликование описания реализации в реестре служб. Этот шаг является необязательным, необходим в том случае, если мы хотим, чтобы службу могли найти во внешнем реестре служб и, возможно, динамически вызвать.
7 Создание клиентского приложения для доступа к Web-службе. Как правило, на основе описания реализации Web-службы создается так называемый proxy-класс, который используется клиентским приложением и скрывает в себе все сложные подробности вызова Web-службы (например, использование API-реализации протокола SOAP).
Проблемы организации CОА
1) безопасность
2) проблема хостинга Web-служб.
3) проблемы составления композиций Web-служб.
Четыре основных сценария создания Web-служб в зависимости от исходных данных
Сценарии создания Web-службы |
||
|
Интерфейс Web-службы не определен |
Интерфейс Web-службы определен |
Реализации не существует |
разработка «с нуля» |
разработка «сверху вниз» |
Реализация существует |
разработка «снизу вверх» |
«встреча посередине» |
Разработка "снизу вверх" ( приложение, реализующее функциональность Web-службы, уже существует) "оборачивают" унаследованные приложения, предоставляя, таким образом, современный, универсальный интерфейс к коду на устаревшем языке программирования. Используя готовую реализацию и современные средства разработки Web-служб, автоматически генерируется описание Web-службы. Далее, используя автоматизированные средства разработки, необходимо развернуть службу на сервере приложений, а затем, при необходимости, опубликовать в реестре служб.
Разработка "с нуля" (не существует ни реализации, ни интерфейса службы) - прежде всего, необходимо реализовать программный компонент, собственно, несущий в себе функциональность будущей Web-службы (любой язык программирования). Далее необходимо выполнить те же действия, что и в предыдущем сценарии.
Разработка "сверху вниз" (имеется описание интерфейса Web-службы (обычно на языке WSDL), однако реализация еще не создана). Прежде всего необходимо реализовывать службу на некотором языке программирования. При этом важно, чтобы реализация в точности соответствовала заявленному интерфейсу. Современные средства разработки позволяют по описанию Web-службы создать так называемый "скелет" (skeleton) - основу будущей реализации, на которую программист должен нарастить "мышцы", добавив в методы классов необходимую функциональность.
Сценарий "встреча посередине" (в наличии имеется как реализация службы, так и описание ее интерфейса.) В этом случае может возникнуть проблема несоответствия имеющейся реализации заявленному интерфейсу. Решить эту проблему можно, например, "обернув" имеющуюся реализацию в новую, соответствующую интерфейсу службу.
Инструменты разработки для автоматизированного создания Web-служб
IBM WebSphere Studio Application Developer
Microsoft Visual Studio.NET)
BEA Systems - BEA WebLogic Server 6.1.
IBM, BEA, Oracle, и Borland, (наряду с Microsoft) являются лидерами в области создания различного рода решений для Web-служб.
© ism-06-2.ru