1.4.3Взаимодействие в рамках сервисно-ориентированной архитектуры

В рамках сервисно-ориентированной архитектуры можно выделить три компонента:

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

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

• Пользователь сервиса – потребитель услуг веб-сервиса, предоставляемого провайдером сервиса. Для поиска подходящего провайдера сервиса он использует реестр веб-сервисов.

Таким образом, процесс взаимодействия в рамках сервисно-ориентированной архитектуры можно разделить на несколько этапов:

• Публикация. В ходе этого этапа провайдер сервиса заносит данные о своем веб-сервисе в реестр веб-сервисов.

• Поиск. На этом этапе пользователь сервиса с помощью реестра веб-сервисов производит поиск нужного ему веб-сервиса.

• Использование потребителем сервиса веб-сервиса предоставляемого провайдером сервиса.

Рис. 1.3. Взаимодействие в рамках сервисно-ориентированной архитектуры.

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

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

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

1.5Веб-сервисы и другие технологии

1.5.1История развития

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

1.5.2COM, DCOM

В начале 90-х годов предложила архитектуру Component Object Model (COM), которая позволяла многократно использовать компоненты различных производителей, оформляя их в библиотеки со стандартным интерфейсом. При этом взаимодействие осуществлялось в рамках одного локального компьютера. По мере развития локальных сетей и Интернета перед разработчиками встала задача создания большого количества распределенных приложений, например по архитектуре клиент-сервер. При этом они могли пользоваться сокетами, для передачи данных по сети. Такой способ взаимодействия требовал разработки собственного протокола, больших трудозатрат и, как следствие, привносило дополнительный источник ошибок в разрабатываемое приложение.

В этой ситуации компания Microsoft выпустила в середине 90-х расширенную компонентную модель Distributed COM (DCOM). С помощью этой технологии клиенты получили возможность вызывать COM компоненты не только с локальной машины, но и по сети. DCOM позволяет переносить локальную межпроцессную связь с помощью сетевого протокола по сети. При этом увеличивается время отклика вызываемого компонента, однако ни клиент, ни вызываемый компонент не знают о том, что вызов происходит по сети (Рис. 1 .4), а не в рамках локальной машины.

Рис. 1.4. Архитектура DCOM.

1.5.3CORBA, IIOP

Технология CORBA (Common Object Request Broker Architecture), разработанная группой OMG, является аналогом технологии COM от Microsoft. В этой технологии используются диспетчеры объектных запросов (Object Request Broker, ORB), которые являются аналогами COM компонентов. Для обеспечения коммуникации ORB по сети был создан протокол IIOP (Internet InterORB Protocol).

Основное преимущество CORBA состоит в том, что клиенты и серверы могут быть написаны на любом языке программирования. Это возможно потому, что объекты определяются с высоким уровнем абстракции, обеспечиваемым языком определения интерфейса IDL (Interface Definition Language). Взаимодействия между объектами, клиентами и серверами обрабатываются с помощью диспетчеров объектных запросов ORB. Однако написание распределенных приложений с помощью CORBA - это очень сложная задача. Для того чтобы обеспечить преобразование IDL на различные языки программирования, приходится ограничиваться теми базовыми концепциями, которые реализованы в поддерживаемых языках. Таким образом, IDL является для них чем-то вроде общего знаменателя.

1.5.4Java RMI

Технология вызова удаленных методов была предложена компанией Sun для создания распределенных приложений Java-to-Java. В них методы удаленных Java-объектов могут вызываться из других виртуальных машин Java (JVM), наиболее вероятно находящихся на различных узлах сети. Коммуникация по сети осуществляется с помощью протокола JRMP (Java Remote Method Protocol).

Работа RMI зависит от многих уникальных особенностей языка Java, в частности сериализации объектов. Поэтому для работы с использованием RMI клиент и сервер должны быть написаны на Java и исполняться на виртуальных машинах Java. С одной стороны это является достоинством этой технологии, так как она не накладывает дополнительных ограничений на механизм общения и обладает простотой реализации. Однако с другой стороны это ограничивает ее применение языком Java.