Разработка бизнес-процессов работы библиотеки

Сервис-ориентированное моделирование

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

На рисунке 7.11 приведена SOMF-диаграмма взаимодействия сервисов.



Рис. 7.11 SOMF-диаграмма взаимодействия сервисов
Семантическая связь бизнес-процессов с сервисами приведена в таблице 1.
Таблица 7.1 (Семантическая связь бизнес-процессов с сервисами)

Сервис	Бизнес-процесс
A	Выдать книгу
B	Получить книгу
C	Редактировать информацию о читателе
D	Исключить читателя
E	Принять нового читателя
F	Редактировать данные о книгах
G	Принять новую книгу
H	Списать старую книгу
I	Перегруппировать книги по залам | Просмотреть данные о книгах в зале
J	Составить итоговый отчет за месяц
K	Изменить данные о залах
L	Добавить новый зал
M	Упразднить зал
N	{Исключить тех, кто не прошел перерегистрацию}
O	Составить список должников
P	Составить список читателей младше 20
Q	Составить список читателей с редкими книгами
R	Составить отчет по уровню образования читателей
S	Найти информацию о книге | Найти информацию по читателю

Теперь раскроем архитектуру созданного программного средства (см. рис. 7.12), с тем, чтобы потом продемонстрировать взаимосвязи между программным средством и сервисами, которые вызываются в процессе работы по запросу пользователя.

Слева от блоков программных компонентов указано, какие сервисы они вызывают. Справа от сервисов указана шина ESB, посредством которой они взаимодействуют путем обмена сообщениями.



JMS JMS JMS JMS JMS JMS
SOAP/HTTP SOAP/HTTP SOAP/HTTP SOAP/HTTP JDBC


Visual Basic
Рис. 7.12 Архитектура программного средства

4. Взаимодействие сервисов с ESB

На рисунке 7.12 продемонстрирована общая архитектура системы и интерфейсы, связывающие ее компоненты.

Java Message Service (JMS) — стандарт промежуточного ПО для рассылки сообщений, позволяющий приложениям, выполненным на платформе J2EE, создавать, посылать, получать и читать сообщения. Коммуникация между компонентами, использующими JMS, асинхронна (процедура не дожидается ответа на своё сообщение) и независима от исполнения компонентов. Сами сервисы будут реализованы с использованием платформы J2EE, но ESB обеспечит прозрачность реализации за счет описания контрактов сервисов.

Рассмотрим структуру входных и выходных сообщений JMS для разработанных сервисов.

Сообщение содержит три основные части:

• 
  заголовок содержит необходимые данные для идентификации и маршрутизации сообщений.
  
• 
  блок параметров сообщения содержит дополнительные настройки для обеспечения связей с другими поставщиками и пользователями. Может быть использован для создания стандартных полей и фильтров.
  
• 
  тело сообщения одного из пяти типов:
  

• 
  текст;
  
• 
  map-объект (список пар имя-значение);
  
• 
  поток байтов;
  
• 
  поток данных примитивных типов;
  
• 
  объект.
  

Будем в качестве данных передавать объекты, поскольку этот метод лучше подходит для обработки данных, поведение которых можно описать как поведение объектов.

Интнрфейсное приложение взаимодействует с шиной ESB по протоколу SOAP. Simple Object Access Protocol (SOAP) — основанный на XML протокол, предназначен для обмена информацией в распределенных системах. SOAP устанавливает стандарт взаимодействия «клиент-сервер» и регламентирует, как должен осуществляться вызов, а также, как должны передаваться параметры и возвращаемые значения. Для представления любой информации, передаваемой от клиента к серверу, и наоборот, используется XML.

Java DataBase Connectivity, сокращенно JDBC — соединение с базами данных на Java — платформно-независимый промышленный стандарт взаимодействия Java-приложений с различными СУБД, реализованный в виде пакета java.sql, входящего в состав Java SE. Входными и выходными данными являются сообщения, которые в качестве тела содержат SQL-запросы.

На рисунке 7.13 показано, как поставщики и клиенты сервисов взаимодействуют с ESB посредством интерфейсов.



Рис. 7.13
Для реализации корпоративной сервисной шины будем использовать WebSphere Enterprise Service Bus.

К основным возможностям и характеристикам WebSphere Enterprise Service Bus относятся:

• 
  Поддерживает большое число протоколов для работы с сообщениями, что позволяет использовать различные способы перемещения данных и взаимодействия с продуктами семейства WebSphere;
  
• 
  Использует большое число моделей взаимодействия;
  
• 
  Использует расширенные Web-службы для внедрения самых передовых функций;
  
• 
  Использует все преимущества полного пакета клиентских приложений для расширения вашей среды;
  
• 
  Минимизирует разъединенность за счет использования встроенной функции-посредника для обработки правил интеграции;
  
• 
  ПО WebSphere Integration Developer, входящее в комплект поставки, ускоряет разработку правил интеграции;
  
• 
  Поддерживает решения многих независимых поставщиков ПО и обеспечивает расширенную поддержку ПО WebSphere Adapter;
  

Использует в качестве основы платформу WebSphere.[5]

WebSphere Enterprise Service Bus - это платформа, которая делает возможной гибкую интеграцию приложений и помогает предприятиям решать задачи сервис-ориентированной архитектуры СОА (Service-Oriented Architecture). ESB позволяет потребителям и производителям сервисов взаимодействовать друг с другом без установления прямой взаимозависимости. Все сервисные компоненты, публикуемые в WebSphere ESB, должны иметь хорошо определенный интерфейс. Это обеспечивает прозрачность реализации сервисов и позволяет ESB оперировать понятиями виртуальных агентов, под которыми могут пониматься сервисы, приложения, веб-сервисы, взаимодействующее посредством ESB. Cоздать интерфейс сервиса можно в программе WebSphere Integration Developer. Для создания интерфейсов сервисов будем использовать язык интерфейсов WSDL в соответствии с требованиями на внешние взаимодействия для платформы WebSphere Enterprise Service Bus[7].

Шаблоны контрактов на поведение определяют стили взаимодействий и особенности служб. Мы предлагаем для нашего примера с ESB четыре базовых шаблона:

• 
  синхронный запрос информации с ограниченным временем ожидания;
  
• 
  синхронное обновление с подтверждением/уведомлением об ошибке и ограниченным временем ожидания;
  
• 
  асинхронный запрос информации;
  
• 
  обновление с асинхронным ответом/уведомлением об ошибке.