9. Моделирование систем с soa-архитектурой
Стратегия крупнейшего в мире производителя ПО IBM Software Group направлена на создание более эффективной и конкурентоспособной формы бизнеса ‑ «бизнеса по требованию/запросу)» (On Demand Business). Для реализации этой стратегии был разработан новый подход к организации и интеграции корпоративных приложений и появлению сервис-ориентированной архитектуры (Service-Oriented Architecture, SOA) корпоративных информационных систем, [29].
9.1. Композитная структура программ
Традиционные программы имеют «монолитную» модульную структуру, состоящую из жёстко связанных подпрограмм (рис. 9.1а). Эти связи организует программист ещё на этапе кодирования программы. На этапе выполнения эти связи не могут изменяться, а подпрограммы находятся в монопольном владении основной программы. Никакая другая программа не имеет доступа к этим подпрограммам.
Монолитную структуру программ в корне изменяет переход к композитным (компонентным) структурам, в которых некоторые из подпрограмм выводятся из состава монолитной программы и передаются на хранение в отдельный сервер, где организуется их выполнение по запросу вызывающей программы (рис. 9.1б). Причём запрашивать такую услугу может не только программа-поставщик, но и любая другая компонента корпоративной информационной системы.
(а)
(б)
Рис. 10.1. Монолитная (а) и композитная (б) структура программ
Таким образом, структура композитной программы оказывается распределённой между сервером приложения и сервером, на котором хранятся её компоненты. Вырванные из контекста основной программы подпрограммы становятся автономно управляемыми модулями, которыми могут пользоваться другие, не обязательно композитные, программы (с помощью того же механизма доступа «по запросу»). Таким образом, композитная организация программ является ещё одним способом их интеграции в единую программную систему, основанную на общем способе взаимодействия своих компонент. Этот способ интеграции начинает всё шире использоваться для интеграции корпоративных информационных систем, приходя на смену достаточно сложным системам интеграции корпоративных приложений, таким как Enterprise Application Integration (EAI).
9.2. Концепция soa
Уточним некоторые определения концепции SOA.
Сервис или служба (service) – это относительно небольшой автономный программный модуль, который хранится отдельно от основной программы, в специальном хранилище (реестре или репозитории) другого компьютера, и обладает следующими свойствами:
каждый сервис реализует элементарную бизнес-функцию, которая является компонентом одного или нескольких бизнес-процессов предприятия;
сервис могут многократно использовать (путём запроса его выполнения на удалённом сервере) несколько (или даже все) корпоративные приложения, причём, ‑ не обязательно композитные);
SOA-приложение обычно использует сразу несколько сервисов и имеет (но, ‑ не обязательно) композитную (составную) структуру;
для доступа к сервису можно использовать несколько технологически независимых интерфейсов;
выделенные приложению сервисы слабо связаны между собой, но используемые при их вызове коммуникационные протоколы обеспечивают некоторую возможность их взаимодействия.
Архитектурный стиль SOA преобразует модульную структуру программ так, что она может расширяться или изменяться по заросу, т.е. способна включать в себя любой дополнительный набор существующих сервисов и в любой момент изменять свой состав. Очевидным преимуществом этого стиля является повышенная гибкость и адаптируемости программ, поскольку замена или модернизация одной из программных компонент не сказывается на остальных. Следует также подчеркнуть, что SOA-приложения компонуются из уже готовых к исполнению сервисных модулей, не зависимо от того, на каких языках программирования и на каких программно-аппаратных платформах они разрабатывались, так что и сами SOA-приложения считаются также «языково» и «платформно» независимыми.
Известны и другие технологии реализации сервисов в информационных системах - CORBA16, DCE17, DCOM18, Java RMI19. Архитектуры, реализованные с использованием данных технологий можно также назвать ориентированными на сервисы, но при этом каждая из них определяет свои собственные форматы данных, протоколы обмена этими данными, программные интерфейсы. Поэтому они не являются универсальными, что значительно сужает сферу их применения.
Использование Web-сервисов. Более универсальной и хорошо освоенной является сервисная архитектура, базирующаяся на использовании Web-сервисов глобальной сети Интернет. Она может функционировать практически в любой программно-аппаратной среде, поэтому нашла широкое применение в корпоративных информационных системах, функционирующих в инфраструктуре внутрикорпоративных (интранет-) сетей.
Web-сервис (Web service) ‑ это программный модуль, хранящийся (вместе со своим описанием) в реестре Web-сервера предприятия и идентифицируемый URI20 -идентификатором. Интерфейсы таких сервисов определяются на языке XML. Программы «потребители сервисов», находящиеся на клиентских компьютерах, могут взаимодействовать с Web-сервисами (в соответствии с их описаниями) с помощью XML-сообщений, поддерживаемых SOAP-протоколами Интернета (рис. 9.2). Такой способ доступа потребителей к Web-сервисам называют доступом «по запросу» или «по требованию».
Рис. 9.2. Архитектура доступа к Web-сервисам
Структура Web-сервиса включает три компонента:
Провайдер сервисов (Service Provider), который является владельцем репозитория Web-сервисов.
Потребитель сервисов (Service Requestor), которым в нашем случае является любое корпоративное приложение (вновь созданное или унаследованное).
реестр сервисов (Service Broker), в котором провайдер публикует (регистрирует) каждый сервис.
Система доступа к Web-сервисам использует три протокола:
UDDI21 - определяет способ описания и регистрации каждого сервиса в реестре (для провайдеров) и способ поиска требуемого сервиса (для потребителей). UDDI-реестры выступают в качестве посредника (брокера) в архитектуре SOA;
SOAP22 - протокол, обеспечивающий обмен данными между провайдером веб-сервисов и их потребителями. Его можно сравнить с конвертом, в который потребители вкладывают свои запросы на услугу;
WSDL23 - язык описания Web-сервисов, ссылки на которые хранятся в UDDI-репозитории;
Система доступа работает так: Провайдер публикует все свои сервисы в Реестре. Потребитель посылает Провайдеру запрос на поиск нужного ему сервиса в Реестре. Найдя запрошенный сервис, Провайдер возвращает заказчику его адрес в Репозитории. Используя этот адрес, Потребитель обращается к нужному сервису и подключает его к своему приложению (выполняя правила пользования данным сервисом, описанные стандартным образом на этом же ресурсе).
К основным характеристикам SOA, отличающим ее от других архитектур, следует отнести:
Распределённость ‑ функциональные компоненты корпоративных приложений могут быть расположены в разных, территориально рассредоточенных вычислительных системах, которые могут взаимодействовать между собой через локальные сети и Интернет;
Слабосвязанные интерфейсы ‑ отсутствие жестких связей между элементами системы упрощает конфигурирование системы и координирование работы ее элементов;
Базирование на международных стандартах взаимодействия открытых систем (SOAP –один из протоколов реализации эталонной модели взаимодействия открытых систем ВОС/OSI24);
Возможность динамического поиска и подключения нужных функциональных модулей;
Система нацелена на поддержку бизнес-процессов предприятия с использованием сервисов, ориентированных на решение определенных бизнес-задач.
Переход к SOA-архитектуре означает глубокие изменения в функциональности и способах интеграции корпоративных приложений. SOA-ориентированные КИС, такие, например, как SAP ERP компании SAP, постепенно вытесняют монолитные корпоративные информационные системы, сложные как во внедрении, так и в модернизации.
Обязательным условием построения и внедрения архитектуры системы на основе SOA является использование единой интеграционной платформы ‑ так называемой сервисной шины предприятия (Enterprise Service Bus, ESB).
Рис. 9.3. Модель КИС с SOA-архитектурой
ESB-шина образует однородную среду информационного взаимодействия внутрикорпоративных (intranet-) и внешних (extranet-) приложений25 и является фундаментом для их интеграции (рис. 9.3). Она определяет, кем, где, каким образом, и в каком порядке должны обрабатываться запросы на сервисное обслуживание времени выполнения.
SОА-архитектура хорошо зарекомендовала себя при построении крупных корпоративных информационных систем. Ведущие разработчики и интеграторы таких систем – компании IBM и SAP, ‑ предлагают достаточно мощные интеграционные платформы для SOA-архитектур: IBM WebSphere Application Server и SAP NetWeaver Application Server.