Бизнес процессы работают поверх уровня сервисов

1. ИНТЕГРАЦИЯ ПРИЛОЖЕНИЙ

Общие принципы организации
взаимодействий в информационных
системах

2.

• Системы обмена данными подразделяют на системы,
использующие асинхронную и синхронную связь, а также на
системы, работающие по принципу сохранной и несохранной
связи.
• При использовании асинхронной связи (asynchronous
communication) отправитель после отправки сообщения
немедленно продолжает работу, а сообщение сохраняется в
локальном буфере передающего хоста или на ближайшем
коммуникационном сервере.
• При использовании синхронной связи (synchronous
communication) работа отправителя блокируется до того момента,
когда сообщение будет доставлено получателю, либо сохранено в
локальном буфере принимающего хоста.

3. При использовании синхронной связи (synchronous communication) можно выделить три степени «жесткости»:

• отправитель может продолжать работу после того, как
сообщение помещено во входной буфер получателя;
• работа отправителя блокируется до момента получения
сообщения непосредственно пользователем, в этом
случае от пользователя часто требуется подтвердить
прием сообщения;
• работа отправителя блокируется до момента получения
ответа.

4.

• При сохранной связи (persistent communication) сообщение,
предназначенное для отсылки, хранится в коммуникационной
системе до тех пор, пока его не удастся передать получателю.
Сообщение сохраняется на коммуникационном сервере до тех
пор, пока его не удастся передать на следующий
коммуникационный сервер. Поэтому у приложения,
отправляющего сообщение, нет необходимости после отправки
сообщения продолжать работу. Приложение, принимающее
сообщение, не обязательно должно находиться в рабочем
состоянии во время отправки сообщения.
• При использовании сохранной связи сообщения никогда не
теряются и не пропадают.

5.

• Альтернативой использования механизмов сохранной связи
является использование несохранные связи (transient
communication. При применении нерезидентной связи
сообщение хранится в системе только в течение времени работы
приложений, которые отправляют и принимают это сообщение.
• Если коммуникационный сервер не имеет физической
возможности передать сообщение следующему серверу или
получателю, то сообщение уничтожается. Следует отметить, что
все коммуникационные сервисы транспортного уровня
поддерживают только нерезидентную связь.
• На практике применяются различные комбинации этих типов
взаимодействия.

6. Типовыми проблемами, возникающими при создании распределенных ИС и, в частности КИС, являются следующие:

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

7.

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

8. Обычно выделяют четыре базовых механизма интеграции приложений, входящих в состав распределенной ИС

• разделяемые файлы;
• разделяемая база данных;
• удаленный вызов процедуры и методов;
• обмен сообщениями.

9. Разделяемые файлы

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

10.

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

11.

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

12. Разделяемая база данных

• Основная идея данного подхода состоит в том, что данные хранятся в
центральной базе данных, доступной для всех интегрируемых
приложений. Общая база данных обеспечивает согласованность
хранящейся в ней информации. Синхронизация доступа к данным
реализуется посредством использования, например механизма
транзакций.
• Самый простой способ реализации общей базы данных состоит в
использовании реляционной СУБД с поддержкой SQL. Язык запросов
SQL поддерживается практически всеми платформами для разработки
приложений, что позволяет не беспокоиться о различии в форматах
файлов и избавляет от необходимости изучения новых языков
программирования и новых технологий. Все вопросы, связанные с
интерпретацией данных, могут быть решены на этапе проектирования
и реализации интеграционного решения.

13.

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

14. Удаленный вызов процедуры и методов

• С точки зрения интеграции приложений, удаленный вызов процедуры
представляет собой применение принципов инкапсуляции данных.
Если приложение хочет получить доступ к данным, которые
поддерживаются другим приложением, то оно обращается к
требуемым данным посредством вызова функции, т. е. каждое
приложение самостоятельно обеспечивает целостность своих данных
и может изменять их формат, не затрагивая при этом другие
приложения.
• Удаленный вызов процедуры и работа с удаленными объектами
поддерживается множеством технологий, таких как RPC, Java RMI,
CORBA, DCOM, .NET Remoting. Несмотря на внешнюю схожесть,
удаленный вызов процедуры и вызов локальной функции имеют
принципиальные различия, способные оказать существенное влияние
на интеграционное решение . Следует отметить, что удаленный вызов
процедуры характеризуется самой сильной степенью связывания
приложений.

15. Обмен сообщениями

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

16. Интеграция приложений

17. типы интеграционных задач

• В широком смысле под термином «интеграция»
можно понимать объединение ИТ-систем и
отдельных приложений, входящих в их состав,
интеграцию компаний (бизнеса) или людей. В
более узком смысле под интеграцией можно
понимать объединение отдельных приложений в
ИТ-систе- му, объединение отдельных ИТ-систем в
более крупную систему и организацию
взаимодействия между отдельными ИТсистемами по принципу В2В.

18.

• Интеграция приложений может принимать
различные формы, прежде всего можно
выделить внутреннюю и внешнюю интеграцию.
Внутреннюю интеграцию обычно называют
интеграцией корпоративных приложений
(Enterprise Application Integration, EAI), а внешнюю
— интеграцией бизнес-бизнес (Business-toBusiness Application Integration, B2B).

19. четыре типовых подхода к решению задачи интеграции

•интеграция на уровне данных;
•бизнес-функции и бизнес-объекты;
•бизнес-процессы;
•порталы.

20. Интеграция на уровне данных

• Данный подход называют также интеграцией,
ориентированной на информацию (Information-Oriented
Integration) .
• Этот подход ориентирован, в первую очередь, на
интеграцию данных, которые хранятся в базах данных и
обычно имеет целью создание API, позволяющего
программисту унифицированным образом работать с
множеством БД, которые могут быть территориально
разнесены и принадлежать разным производителям.

21. В рамках данного подхода можно выделить, по крайней мере, три группы технологий

• системы репликации баз данных;
• федеративные базы данных;
• использование API для доступа к
cтандартным ERP-системам.

22. Федеративные базы данных (Federated Database System)

• это системы, которые позволяют прозрачным для пользователя
образом интегрировать множество автономных баз данных,
которые могут располагаться на разных хостах сети.
Федеративные базы данных называют также виртуальными БД.
• Федеративная (виртуальная) БД предоставляет пользователю
единый хорошо определенный интерфейс для доступа к
распределенным данным, при этом сами данные не
перемещаются и не изменяются, т.е. нет препятствий для того,
чтобы одна и та же автономная БД входила в состав более чем
одной виртуальной БД.

23. Использование API для доступа к стандартным ERP-системам

• предполагает использование хорошо определенных
интерфейсов для организации взаимодействия создаваемых
пользовательских приложений с такими пакетными
приложениями, как Enterprise Resource Planning (ERP) системы,
SAP, Oracle, PeopleSoft. Обычно это делается посредством
использования адаптеров (коннекторов).

24. Бизнес-функции и бизнес-объекты

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

25.

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

26. Бизнес-процессы

• Данный подход имеет много общего с описанным выше
подходом, основанным на использовании бизнесфункций. Основное различие заключается в том, что
появляется новый уровень интеграции — уровень
бизнес-процессов.
• Бизнес-процессы работают поверх уровня сервисов и
используют собственный язык для описания
последовательности вызова сервисов. Этот язык
представляет собой интерпретируемый язык, во многом
схожий с такими языками, как Basic или shell.

27. Порталы

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

28. Системы, ориентированные на работу с сообщениями

• Системы, ориентированные на работу с сообщениями, реализуют
асинхронные механизмы связи и могут поддерживать сохранные
механизмы связи.

29. наиболее известными системами, ориентированными на работу с сообщениями, являются следующие:

• MPI;
• системы электронной почты;
• очереди сообщений

30. MPI

• На работе с сообщениями основана распространенная
технология программирования для параллельных
вычислительных систем, состоящих из большого числа
процессоров, не имеющих общей памяти. В качестве
основного способа взаимодействия параллельных
процессов, работающих на разных процессорах,
используется обмен сообщениями, что и дало название
самой технологии — интерфейс передачи сообщений
(Message Passing Interface, MPI)

31. Системы электронной почты

• Одним из типовых применений систем работы с сообщениями
является система электронной почты. В системе электронной
почты хосты работают как пользовательские агенты, которые
могут создавать, посылать, принимать и читать сообщения.
Каждый хост соединяется с почтовым сервером, который
выполняет функции коммуникационного сервера.
• Когда пользовательский агент представляет сообщение для
передачи на хост, то последний пересылает сообщение на
локальный почтовый сервер. Почтовый сервер удаляет
сообщение из своего выходного буфера и с помощью сервера
имен (DNS) определяет, куда нужно доставить сообщение.

32.

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

33. Очереди сообщений

• Использование очередей сообщений позволяет решить многие
из проблем, связанных с надежностью и доступностью ИС, в
частности, построение систем, работающих по принципу 24/7, т.е.
систем, доступных 24 ч в сутки и 7 дней в неделю. Подобный
эффект достигается за счет того, что приложения в составе ИС
обмениваются сообщениями, которые обрабатываются и
сохраняются на отдельных работающих круглосуточно серверах.
• Такие системы называют системами очередей сообщений
(Message-queuing systems, MQ).
• Если один компонент ИС хочет послать сообщение другому
компоненту, то он посылает данное сообщение MQ, а уж MQ
пересылает его адресату.

34.

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

35. Существует две основных модели обмена сообщениями: точка- точка (point-to-point) и публикация-подписка (publish-subscribe).

• Модель точка-точка применяется тогда, когда отправителю
требуется отправить сообщения одному получателю. При
использовании данной модели адрес получателя определяется
отправителем. Эта модель использует push-модель для работы с
сообщениями, т. е. модель «проталкивания» сообщений.

36.

• Модель публикация-подписка предполагает, что в системе кроме
отправителей и получателей имеется несколько очередей,
которые называются темами (topics). Отправитель может
помещать сообщения в любую тему. Каждый получатель может
выражать заинтересованность в получении сообщений из
произвольных очередей посредством подписки (subscription).

37. Язык описания бизнес-процессов ВРЕL

• Web-сервисы представляют собой интерфейсы для доступа к
автономным, модульным приложения. Для того чтобы обратиться
к Web-сервису, необходимо послать SOAP-послание по
определенному адресу (XML-документ). При этом не имеет
значения, каким именно образом формируются эти послания.
• BPEL — это язык, который позволяет описывать бизнес-процесс в
терминах некоторой последовательности обращения к Web-cepвисам. BPEL, по существу, является скриптовым языком
программирования, поддерживающим синхронные и
асинхронные взаимодействия, параллельное выполнение и
обработку исключений. Программа (приложение), написанное на
языке BPEL, является XML-документом.

38.

• Язык ВРЕL позволяет задавать бизнес-процессы, при этом
приложение, написанное на языке ВРЕL, можно рассматривать
как Web- сервис, и к нему можно обращаться посредством
посылки SOAP-посланий.
• BPEL является интерпретируемым языком и для его
использования необходимо наличие процессора (движка).

39.

•Основу BPEL составляют три ключевых
свойства: асинхронность,
координация потоков и управление
исключительными ситуациями.

40. Асинхронность

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

41. Координация потоков

• включает в себя параллельные потоки выполнения, образцы
соединений и динамические потоки. В реальных приложениях
бизнес-потоки могут включать образцы сложных
взаимодействий как с синхронными, так и с асинхронными
сервисами. Координация потока включает интерфейс с WSDL,
действия потока, переменные XML и отвечает за координацию.
BPEL использует WSDL для обращения к сообщениям,
вызванным операциям и типам портов. Действия с потоком
используют общие переменные XML, так что компенсационные
обработчики (compensation handlers) должны сохранять снимки
данных, которые могут быть использованы обработчиком.
Компенсационные обработчики могут отменить шаги, которые
были уже завершены.

42. Управление исключительными ситуациями

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

43. Подходы к объединению Web-сервисов в бизнес-процессы.

Подходы к объединению Web-сервисов в бизнеспроцессы.
• Принято выделять два основных подхода к объединению Web-cepвисов в бизнес-процессы: оркестровка (Orchestration) и хореография
(Choreography).
• Идея оркестровки состоит в том, что в системе имеется
единственный BPEL-процессор (движок), который выполняет
функции интерпретатора BPEL-файлов. Для внешнего мира BPELпроцессор доступен как Web-сервис. Получив запрос, движок уже от
своего имени рассылает SOAP-послания Web-сервисам, участие
которых необходимо для реализации бизнес-процесса.
Задействованные вебсервисы не знают, что они вовлечены в бизнеспроцесс более высокого уровня. Только движок обладает полной
информацией о выполняемой задаче, и поэтому оркестровка
является централизованным механизмом с явным определением
операций и порядком инициирования работы Web-сервисов

44. Схема оркестровки

45.

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

46. Схема хореографии

47.

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

48.

• исполняемые процессы (Executable processes) позволяют
определять точную детализацию бизнес-процессов.
Исполняемый процесс моделирует поведение участников
определенного бизнес-взаимодействия, в сущности, моделируя
частный поток работ. Исполняемые процессы находятся в
парадигме оркестровки и могут быть выполнены механизмом
оркестровки;
• абстрактные бизнес-протоколы (Abstract business protocols)
определяют обмен публичными сообщениями между
участниками. Они не включают внутренние детали потока
процессов, не являются выполнимыми и находятся в парадигме
хореографии.

49.

• Алгоритмически полный язык BPEL, система типов которого
соответствует языку XML, обладает выразительными
управляющими конструкциями, поддержкой параллельного
исполнения, обработкой исключений, поддержкой транзакций,
взаимодействия процессов между собой и другими
возможностями.
• BPEL предоставляет такие механизмы управления
вычислительным процессом, как присваивание значений
переменным, условные операторы, возможность организации
циклов, работа с событиями и др.

50. Бизнес-правила

• Любая организация использует в процессе функционирования
определенный набор законов, постановлений правительства,
промышленных стандартов и корпоративных политик, которые в
совокупности и называются называются бизнес-правилами
(business rules). Наблюдение за их выполнением и соблюдением
может осуществляться как непосредственно людьми, так и ИТсистемами.
• Под бизнес-логикой обычно понимают совокупность правил,
принципов, зависимостей, поведения объектов предметной
области системы. Иначе можно сказать, что бизнес-логика
применительно к ИТ-системам — это реализация правил и
ограничений автоматизируемых операций. Термин «бизнеслогика» часто используют как синоним термина «логика
предметной области» (Domain Logic).

51.

• К бизнес-логике относятся, например, формулы расчета
ежемесячных выплат по ссудам (в финансовой сфере),
автоматизированная отсылка электронного письма
руководителю проекта по окончанию выполнения частей
задания всеми подчиненными (в системах управления
проектами) и т. п.
• Согласно определению Business Rules Group (1993)
«бизнес-правило — это положение, определяющее или
ограничивающее какие- либо стороны бизнеса; его
назначение состоит в том, чтобы защитить структуру
бизнеса, контролировать или влиять на его операции».

52.

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

53. Типы бизнес-правил

54. Факты (facts)

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

55. Ограничения (constraints)

• определяют состав операций, которые может
выполнять как отдельные пользователи, так и ИТсистема. При описании ограничивающего бизнесправила обычно используются следующие глаголы
«должен», «не должен», «может», «не может»,
которые могут встречаться в разных комбинациях;

56. Активаторы операций (action enabler)

• можно определить как правило, при определенных условиях
приводящее к выполнению каких-либо действий (action enabler).
Правило может управлять программными функциями либо
действия могут выполняться вручную. Условия, определяющие
начало выполнения операции, обычно формулируются в
терминах булевой алгебры. Для этого бывает полезно
использовать таблицы.
• В самом общем виде активатор можно описать выражением вида
«Если < наступило определенное событие или выполняется
некоторое условие >, то <что-то происходит>.

57. Вычисления (computations)

• это бизнес-правила, выполняемые с
использованием математических формул и
алгоритмов. При этом вычисления могут
выполняться по внешним для организации
правилам, например по формулам исчисления
налогов. Бизнес-правила данного типа могут
описываться разными способами: в форме
текстового описания, в виде формул или в виде
таблиц.

58. Вывод (inference)

• это правило, которое позволяет создавать новый
факт на основе других фактов или вычислений.
Часто вывод записывается в формате «если —
то». Следует отметить, что данный формат
применяется также в активаторах операций.
Разница состоит в том, что в случае вывода
раздел «то» описывает не действие, а заключает
в себе факт.

59. Документирование бизнес-правил

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

60.

•В настоящее время отсутствует единый
стандарт на формат бизнес-правил,
однако разработан целый ряд
сопутствующих стандартов, наиболее
известными из которых являются
следующие:

61.

• OMG Business Motivation Model (ВММ) определяет
применение стратегии, процессов и правил в бизнесмоделировании;
• OMG Semantics of Business Vocabulary and Rules (SBVR)
ориентирован на бизнес-ограничения;
• OMG Production Rule Representation (PRR) предназначен
для описания правил для продукционных систем;
• W3C Rule Interchange Format (RIF) — семейство языков
бизнес- правил для межсистемного взаимодействия.

62. Порталы и портлеты. Порталы

• Порталом (от лат. porta — ворота) принято называть Web-приложение, которое предоставляет пользователю Интернета или
Интранета доступ к различным сервисам. Часто термин «портал»
определяет единую точку доступа пользователя в
информационное пространство, при этом предполагается, что
пользователь, зайдя на портал, может получить доступ ко всем
необходимым для него источникам информации и приложениям,
поэтому порталы иногда определяют как рабочий стол (десктоп)
нового поколения

63.

• С точки зрения пользовательского интерфейса портал
представляет собой многооконное интегрированное
приложение. Каждое окно — это «зона», изображение в которой
формируется отдельным приложением. За каждую зону отвечает
отдельное приложение, однако приложения могут связываться
между собой как автоматически, так и по требованию
пользователя, при этом информация может синхронизироваться.

64.

• Корпоративные порталы первого
поколения ориентированы на
предоставление пользователю
преимущественно статического Web-контента
и Web-документов.

65.

• В корпоративных порталах второго
поколения появляются такие черты, как
наличие персонализации контента,
присутствие поисковика.

66.

• Корпоративные порталы третьего поколения ориентированы
• преимущественно на предоставление сервисов в отличие от
порталов первого и второго поколений, которые ориентированы
на предоставление контента. Отличительной чертой порталов
третьего поколения является то, что в них реализуется идея
сотрудничества (collaboration). Порталы третьего поколения
предоставляют возможность сотрудникам работать в
виртуальном офисе и предоставляют такие возможности как
чаты, e-mail, возможность групповой работы над проектами.
Порталы третьего поколения — это преимущественно
корпоративные порталы.

67.

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

68. Состав типовой КИС, ориентированной на использование порталов

69. Портлеты

• Портлет — это приложение, предоставляющее пользователю
некоторую информацию или сервис. Он может быть включен в
качестве составной части в портальную страницу. Портлет
работает под управлением контейнера, который обрабатывает
запросы и генерирует динамический контент, и представляет
собой plugin, ответственный за представление информации
пользователю.
• Динамически сгенерированный контент портлета называют
фрагментом. Контент нескольких портлетов можно объединять в
рамках одной портальной страницы.

70. Типовая структура портальной страницы

71.

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

72. Работа с портальной страницей

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

73.

• Портлет генерирует фрагмент в форме гипертекста.
Портал формирует окно портлета посредством
добавления к сгенерированному фрагменту
обрамления, включающее рамку и кнопки. Затем
окна портлетов агрегируются в портальную
страницу

74. Формирование портальной страницы

75.

• Портлеты могут функционировать в нескольких режимах.
Пользователь может работать с информационным наполнением,
может настраивать внешний вид портлета в соответствии со
своими предпочтениями, а администраторы могут
конфигурировать портал для предоставления. Режим, который
пользователи выбирают, определяет, какой интерфейс портлета
они видят. Представление может находиться в одном из
следующих состояний: нормальное (normal), максимизированное
(maximized), минимизированное (minimized), закрытое (closed).
• Свойства, существенные для размещения портлетов, хранятся в
дескрипторе.

76.

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

77.

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

78. Возможны два альтернативных подхода к решению данной задачи

• Первый подход предполагает, что в каждом случае создается
портлет, обеспечивающий пользовательский интерфейс для
выполняемой сервисом функции: ввод параметров запроса и
представление результатов. На основании полученных данных
портлет получает требуемые данные, например из БД, либо
формирует SOAP-запрос к сервису и превращает отклик сервиса в
графическое экранное представление. Все портлеты работают на
одном портальном сервере. Подобный подход требует написания
кода портлета, обеспечивающего пользовательский интерфейс,
извлечение данных и развертывания портлета. Альтернативный
подход заключается в том, что удаленный Web-cepвис сам будет
генерировать фрагмент разметки страницы, который
непосредственно будет включаться в страницу нашего портала

79.

• Второй подход предполагает использование
специальных посредников, использование
которых позволяет провайдерам поставлять
контент без ручных настроек

80.

• Идея состоит в том, что вместо добавления самого портлета в
портальный сервер туда помещают его заместителя, который
взаимодействует с удаленным портлетом.
• Сам удаленный портлет поддерживается другим сервером
порталов или модулем исполнения портлетов. Последний
представляет собой упрощенный сервер порталов (среда
исполнения портлетов), который дает возможность удаленному
портлету реагировать на вызовы посредника.

81. Процесс создания портлета

82.

• Использование портлетов безусловно
целесообразно в случае, если цель проекта состоит
в том, чтобы объединить Web-приложения и
информацию в одном удобном месте, если
требуется использовать сервисы внешних
поставщиков и (или) выступать в качестве
поставщика сервиса. Если пользователи активно
перемещаются и пользуются мобильными
устройствами, то портлеты — очевидный выбор.

83. Корпоративные сервисные шины. Общие принципы построения

• Основная задача интеграции приложений состоит в объединении
функций двух или более приложений для получения новой
функциональности.
• Можно выделить два основных типа задач интеграции
приложений:
• задачи интеграции корпоративных приложений;
• задачи интеграции приложений, функционирующих в составе
КИС разных организаций.

84.

• Системы интеграции корпоративных приложений
(Enterprise Applications Integration, EAI) —
технологии, ориентированные на решение
проблем интеграции различных систем,
приложений и данных внутри отдельной
организации. Иногда для этих технологий
используется аббревиатура A2A (Application-toApplication — приложение- приложение)

85.

• Системы интеграции между организациями,
которые обычно называют В2В (Business-toBusiness Integration), представляют собой
технологии, ориентированные на обеспечение
безопасного, надежного информационного
обмена между ИС различных организаций. Эти
технологии направлены на автоматизацию бизнеспроцессов в рамках «расширенных организаций»,
что создает предпосылки для создания разного
рода виртуальных организаций

86.

• Провести четкую границу между интеграцией
типа A2A и В2В не всегда просто, поскольку в
рамках крупной корпорации, даже если
приложения работают в рамках одной
организации, они могут быть разнесены
территориально и находиться в разных
автономных системах, быть отделены с
помощью firewalls и подчиняться разным
политикам безопасности

87.

• Когда говорят об интеграционных решениях, то обычно выделяют
три альтернативных подхода:
• точка-точка (point-to-point);
• шлюз (hub-and-spoke);
• шина (bus).
• Топология интеграционного решения отражает различные
способы взаимодействия приложений, среди которых можно
выделить соединения точка-точка, шлюзы и шины, которые
показаны на рис. а, б, в соответственно

88. Варианты интеграционных решений

89. Обобщенная архитектурная модель интеграционной подсистемы

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

90.

• ESB можно рассматривать как многоуровневую (многослойную)
систему, при этом можно выделить пять уровней:
• уровень сопряжения (адаптеры и интерфейсы);
• транспортная подсистема;
• уровень реализации бизнес-логики;
• уровень управления бизнес-процессами;
• уровень бизнес-управления (бизнес-правила, машины
состояний).

91. Обобщенная структура интеграционной схемы на базе ESB второго поколения

92. Сервисно-ориентированная архитектура и сервисно-ориентированная организация

• Когда говорят об уровнях зрелости применительно к ИТ-сфере, то чаще
всего имеют в виду Capability Maturity Model Integration (CMMI) —
набор моделей (методологий) совершенствования процессов в
организациях разных размеров и видов деятельности, которая
содержит набор рекомендаций в виде практик, реализация которых
позволяет достичь целей, необходимых для успешных определенных
видов деятельности.
• Набор моделей CMMI включает три модели: CMMI for Development
(CMMI-DEV), CMMI for Services (CMMI-SVC) и CMMI for Acquisition
(CMMI-ACQ). Наиболее известной является модель CMMI for
Development, ориентированная на организации, занимающиеся
разработкой программного и аппаратного обеспечения, а также
комплексных систем.

93.

• CMMI определяет 22 процессные области (process areas). Для
каждой из процессных областей существует ряд целей (goals),
которые должны быть достигнуты при внедрении CMMI в данной
процессной области. Некоторые цели являются уникальными, они
называются специфическими (specific). Общие (generic) цели
применяются к нескольким процессным областям. Цели
достигаются при помощи реализации практик, которые делятся
на специфические и общие.

94.

• Для оценки уровня институционализации процессной
области используется шкала уровней способности
(capability level) от 0 до 5 (шесть уровней). Ступенчатое
представление определяет пять (1 — 5) уровней зрелости
(maturity level) организации. Для достижения каждого
уровня зрелости (кроме 1-го) необходимо выполнить
требования по внедрению практик определенного
набора процессных областей для достижения
соответствующих целей. Уровень 1 зрелости в модели не
определен.

95. Уровни зрелости организации

96.

• Модель CMMI была хорошо принята разработчиками ПО и
достаточно успешно применялась на практике, поэтому
появилась идея распространить идеи модели, основанные на
понятии зрелости на смежные области. В частности, были
предложены ряд моделей зрелости СОА и модель зрелости
Maturity Model for Service Oriented Enterprises. В отличие от CMMI,
которые являются фактически отраслевыми стандартами, модели
зрелости СОА и SOE — это предложения отдельных компаний.
Хотя эти модели не столь подробно проработаны как CMMI, они
достаточно полезны как для системных архитекторов, так и
интеграторов

97. модель зрелости СОА

98.

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

99. КИС коммерческой организации, соответствующая уровню 1

100.

• Корпоративная сервисная шина (An Enteiprise Service Bus — ESB)
обеспечивает стандартное взаимодействие между компонентами СОА,
включая Web-сервисы, реляционные базы данных, очереди
сообщений и унаследованные системы. С помощью ESB легко можно
интегрировать платформы, например, .NET, JEE, пакетные системы
класса С RM или ERP.
• Служба управления сервисами (A Service Level Management Service)
представляет собой сервис, который обеспечивает управление
сервисами, снятие метрик и мониторинг служб.
• Реестр сервисов (A Services Registry), поддерживающий стандарт UDDI,
обеспечивает централизованное хранение описаний доступных
сервисов.
• В состав системы данного уровня могут быть включены системы
(подсистемы) ERP, анализа и предсказания уровня заработных плат.
• Теперь КИС можно рассматривать как имеющую СОА архитектуру.
Однако она продолжает соответствовать уровню 1, поскольку
отсутствует документированная архитектура

101.

•Переход от уровня 1 к уровню 2 означает
прежде всего переход от решения
отдельных задач интеграции приложений
по мере их появления к видению текущей
архитектуры ИС организации и желаемой
архитектуры.

102.

103.

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

104.

105.

• Уровень 4 — измеряемые бизнес-сервисы
(Measured Business Services). Специфика этого
уровня — это снятие метрик бизнес-процессов,
обработка и представление результатов в
терминах предметной области таким образом,
чтобы обеспечить постоянную обратную связь для
настройки производительности и повышения
эффективности бизнес-процессов.

106.

• Уровень 5 — оптимизация бизнес-процессов
(Optimized Business Services). Отличительной
особенностью КИС, соответствующей уровню 5,
является наличие автоматической реакции на
события. Бизнес-процессы могут
трансформироваться (настраиваться). Возможно
использования бизнес-интеллекта в РМВ.
Деятельность организации оптимизируется в
терминах бизнес-правил и бизнес-целей.

ГЛАВА 12. ИНТЕГРАЦИЯ ДАННЫХ И ПРИЛОЖЕНИЙ
12.1. Общие принципы организации взаимодействий в ИС

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

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

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

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

Обычно выделяют четыре базовых механизма интеграции приложений, входящих в состав распределенной ИС [158]:

• разделяемые файлы;
• разделяемая база данных;
• удаленный вызов процедуры и методов;
• обмен сообщениями.

Разделяемые файлы. Несколько приложений имеют доступ к одному и тому же файлу. Одно приложение создает файл, а другое приложение считывает его. Приложения должны согласовать имя файла, его расположение, формат, время записи/считывания, а также процедуру удаления. Это один и самых старых подходов к интеграции приложений. Основная идея данного подхода состоит в том, что файл рассматривается как универсальный механизм обмена данными. Можно выделить два альтернативных подхода: распределенные файловые системы и системы, основанные на пересылке файлов.

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

Альтернативой рассмотренного выше варианта взаимодействия приложений состоит в том, что файлы, в которых содержится информация, определяющая взаимодействие пересылаются между хостами. По этому принципу построена, например, описанная выше система Unix—Unix Copy и ряд других систем.

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

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

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

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

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

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

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

Удаленный вызов процедуры и работа с удаленными объектами поддерживается множеством технологий, таких как RPC, Java RMI, CORBA, DCOM, .NET Remoting. Несмотря на внешнюю схожесть, удаленный вызов процедуры и вызов локальной функции имеют принципиальные отличия, способные оказать существенное влияние на интеграционное решение [159]. Следует отметить, что удаленный вызов процедуры характеризуется самой сильной степенью связывания приложений.

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

В табл. 12.1 приведены сведения о достоинствах, недостатках и условиях, при которых целесообразно применение 4-х перечисленных выше подходов к интеграции приложений.

Таблица 12.1. Сравнительный аназиз подходов к интеграции приложжений

Рассмотрим типы интеграционных задач. В широком смысле под термином интеграция можно понимать объединение ИС и отдельных приложений, входящих в их состав, интеграцию компаний (бизнеса) компаний или людей. В более узком смысле под интеграций можно понимать объединение отдельных приложений в ИТ-систему, объединение отдельных ИС в более крупную систему и организацию взаимодействия между отдельными ИС по принципу B2B.

Интеграция приложений может принимать различные формы, прежде всего можно выделить внутреннюю и внешнюю интеграцию. Внутреннюю интеграцию обычно называют интеграцией корпоративных приложений (Enterprise Application Integration, EAI), а во втором — бизнес-бизнес интеграцией (Business-to-Business Application Integration, B2B).

Исходя из последнего определения выделим четыре типовых подхода к решению задачи интеграции [160]:

• интеграция на уровне данных;
• бизнес-функций и бизнес-объектs;
• реализация бизнес-процессов;
• порталы.

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

Интеграция на уровне данных. Данный подход называют также интеграцией, ориентированной на информацию (Information-Oriented Integration) [160].

Этот подход ориентирован, в первую очередь, на интеграцию данных, которые хранятся в базах данных и обычно имеет целью создание API, позволяющего программисту унифицированным образом работать с множеством БД, которые могут быть территориально разнесены и принадлежать разным производителям. В рамках данного подхода можно выделить, по крайней мере, три группы технологий:

• системы репликации баз данных;
• федеративные базы данных;
• использование API для доступа к стандартным ERP системам.

В процессе функционирования многих ИС различным приложениям часто требуется получать доступ к одним и тем же данным.

Например, такая информация, как адрес проживания клиента, может использоваться как системой гарантийного обслуживания клиентов, так и подразделениями, занимающимися рекламой. Некоторые из этих систем могут иметь собственные хранилища данных. При изменении адреса клиента каждая из подсистем должна получить копию обновленной информации. Этого можно добиться с помощью такого типа интеграции, как репликация данных. Существует множество различных способов реализации репликации данных. Функция поддержки репликаций может быть встроена в СУБД; нужные сведения можно экспортировать в файл для последующего импорта в другой системе, а также переслать внутри сообщений с помощью соответствующего промежуточного ПО. Более подробную информацию об общих принципах реализации механизмов реализации механизмов репликации можно найти, например, в [23]

Федеративные БД (Federated Database System) – это системы, которые позволяют прозрачным для пользователя образом интегрировать множество автономных БД, которые могут располагаться на разных хостах сети. Федеративные БД называют также виртуальными БД. Федеративная (виртуальная) БД предоставляет пользователю единый хорошо определенный интерфейс для доступа к распределенным данным, при этом сами данные не перемещаются и не изменяются, т. е. нет препятствий для того, чтобы одна и та же автономная БД входила в состав более чем одной виртуальной БД.

Использование API для доступа к стандартным ERP системам предполагает использование хорошо определенных интерфейсов для организации взаимодействия создаваемых пользовательских приложений с такими пакетными приложениями как Enterprise Resource Planning (ERP) системы, такими как SAP, Oracle, PeopleSoft. Обычно это делается посредством использования адаптеров (коннекторов).

Бизнес-функции и бизнес-объекты. Во многих ИС можно выделить функциональность, которая является общими для нескольких приложениях, входящих в состав ИС. Каждую из таких функций можно вынести за пределы приложений и реализовать в виде функций совместного использования, доступных всем системам в виде сервисов (служб). Например, если организация занимается созданием ИС для систем розничной торговли, то можно создать, например, сервис GetCustomerAddress. Если организация разрабатывает несколько проектов, в которых используется данная бизнес-функция, то будет разумно сделать ее общей для нескольких проектов. Отдельные бизнес функции можно объединить с целью создания более сложной бизнес-функции, например, такую как поставить изделие на гарантийное обслуживание. Если используется СОА, то данный подход используется для создания бизнес сервисов. Если используется компонентный подход, то создаются бизнес-объекты (бизнес-компоненты).

Совместно используемая бизнес-функция и репликация данных могут преследовать схожие цели. К примеру, копирование адреса проживания клиента во все требуемые системы можно заменить созданием совместно используемой бизнес-функции GetCustomerAddress. Выбор между двумя различными типами интеграции основывается на многочисленных критериях, таких как степень контроля над интегрируемыми системами (в отличие от помещения информации в БД, вызов совместно используемой функции предполагает более глубокое вмешательство в систему) и частота изменения данных (доступ к адресу проживания клиента осуществляется часто, а вот вероятность изменения последнего невысока).

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

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

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

12.2. Порталы и портлеты

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

поэтому порталы иногда определяют как рабочий стол (десктоп) нового поколения.

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

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

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

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

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

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

• сервис однократной регистрации, обеспечивающий аутентификацию пользователя при работе с порталом;
• сервис настройки и персонализации, позволяющий настраивать внешний вид, функциональность и информационное наполнение портала для нужд конкретного пользователя с учетом его роли;
• сервисы доступа к приложениям (сервисы обработки);
• сервисы доступа к бизнес-процессам, позволяющие пользовать быть участником бизнес-процесса в соответствии с определенной ему ролью;
• сервисы доступа к данным, обеспечивающие подключение пользователя к источниками консолидированной информации, такими как СУБД или хранилища данных;
• сервис поиска информации в Интернете и интранете;
• сервис совместной работы, позволяющий пользователям работать в команде с целью решения общей задачи (разделяемые библиотеки документов, доски объявлений, онлайновые конференции, новостные группы);
• сервис публикации, позволяющие пользователю сохранять документы в хранилище контента портала;
• сервис подписки, который позволяет пользователя оформлять подписку, что позволяет пользователю получать уведомления об изменении или появлении новой информации, при этом правила доставки/извещения и фильтрации могут настраиваться пользователем;
• сервис администрирования, позволяющий управлять правами доступа пользователей, создавать и удалять пользователей.

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

С точки зрения назначения, принято выделять три основных типа порталов:

• горизонтальные порталы;
• вертикальные порталы;
• корпоративные порталы.

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

Горизонтальные порталы имеют много общего со средствами массовой информации и могут рассматриваться как порталы общего назначения. В качестве примеров горизонтальных порталов могут выступать такие известные порталы как Rambler, Lycos, Excite,. Yahoo!.

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

В качестве примеров горизонтальных порталов могут служить B2C (Business-to-consumer) порталы, B2B (business-to-business) порталы, а также порталы типа B2E (Business-to-employees) порталы, которые обычно называют корпоративными порталами.

Примерами B2C порталов могут служить порталы турфирм, предоставляющие такие услуги как заказ билетов, бронирование мест в гостиницах и т.п.

B2B порталы позволяют пользователям клиентам реализовывать совместные бизнес-операции, такие как выбор поставщиков, закупку товаров, проведение и участие в аукционах и т.д. Число B2B порталов растет быстрыми темпами. B2E порталы, которые обычно называют корпоративными порталами, предназначены для сотрудников, клиентов и партнеров одного предприятия.

Пользователи корпоративных порталов обычно получают доступ к сервисам и приложениям в зависимости от роли, назначенной конкретному пользователю. Основным назначением корпоративного портала является предоставление внешним и внутренним пользователям возможности персонифицированного доступа к сервисам, приложениям и корпоративным данным, объединение изолированных моделей бизнеса, интеграция различных корпоративных приложений, включая приложения бизнес-партнеров, обеспечение доступа как стационарных, так и мобильных пользователей к корпоративным ресурсам независимо от места нахождения пользователя. Следует отметить, что корпоративные порталы развиваются быстрыми темпами. Обычно принято выделять четыре поколения корпоративных порталов [161].

Корпоративные порталы первого поколения ориентированы на предоставление пользователю преимущественно статического Web-контента и Web-документов.

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

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

В корпоративных порталах второго поколения появляются такие черты, как наличие персонализации контента, присутствие поисковика. Эти порталы ориентированы на использование в качестве составной части КИС, и для них характерны:

• надежная среда реализации приложений;
• мощные инструменты разработки и интеграции приложений;
• соответствие требованиям, предъявляемым к ИС системам масштаба предприятия;
• поддержка интеграции с ИС партнеров;
• наличие поддержки мобильного доступа к ресурсам.

Рис. 12.1. Составе типовой КИС, ориентированной на использование порталов

Корпоративные порталы третьего поколения ориентированы преимущественно на предоставление сервисов в отличие от порталов первого и второго поколений, которые ориентированы на предоставление контента. Отличительной чертой порталов третьего поколения является то, что в них реализуется идея сотрудничества (сollaboration). Порталы третьего поколения предоставляют возможность сотрудникам работать в виртуальном офисе и предоставляют такие возможности как чаты, e-mail, возможность групповой работы над проектами. Порталы третьего поколения – это преимущественно корпоративные порталы.

Для четвёртого поколения корпоративных порталов характерны:

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

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

В составе типовой КИС, ориентированной на использование порталов можно выделить три основных функциональных слоя (рис. 12.1):

• слой базовой инфраструктуры;
• слой интеграции приложений;
• слой интерфейсов (адаптеров).

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

Слой интеграции приложений обеспечивает взаимодействие портала с приложениями, такими как ERP- и CRM- системы, унаследованные приложения, СУБД и др.

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

Рис. 12.2. Типовая структура портальной страницы

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

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

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

Портлеты могут реализовываться на разных платформах. При реализации на Java платформе портлет рассматривается как Web компонент.

На данный момент рабочей является версия 2.0. Ниже изложение ведется применительно к данной спецификации.

Клиент, обычно это Web клиент, взаимодействует с портлетом в режиме запрос-ответ. Для разных пользователей портлет может иметь разный внешний вид в зависимости от настроек.

Портлеты могут реализовываться на разных платформах. При реализации на Java платформе портлет рассматривается как Web компонент.

На момент написания книги рабочей является версия 2.0. Ниже изложение ведется применительно к данной спецификации.

Контейнер портлетов представляет собой среду, в которой «живут» портлеты. Контейнер управляет жизненным циклом портлетов, однако не отвечает за агрегацию портлетов.

Обычно портал или точнее портальный движок и контейнер могут реализовываться как один монолитный компонент или как два независимых компонента.

В самом общем виде работа с портальной страницей происходит следующим образом.

1. Web клиент посылает HTTP запрос к порталу.

2. Портал получает запрос и определяет к какому из портлетов, относящихся к данной портальной странице, относится запрос.

3. Портал запускает портлет через контейнер и получает требуемый контент.

4. Портал агрегирует полученный контент в портальную страницу и отправляет ее клиенту.

Рис. 12.3. Формирование портальной страницы

Следует заметить, что портлеты имеют много общего с сервлетами, в частности:

• как сервлеты, так и портлеты являются Web компонентами;
• подобно сервлетам, портлеты работают под управлением контейнера;
• портлеты подобно сервлетам генерируют динамический контент;
• клиент работает через Web интерфейс.

Отличие портлетов от сервлетов состоит в следующем:

• портлет представляет собой только часть изображения, портальная страница формируется из фрагментов средствами портального сервера;
• Web клиент взаимодействуют с портлетом не напрямую, а через портальную систему;
• форматом отображения портлета можно управлять;
• на одной портальной странице один и тот же портлет может появляться несколько раз.

Кроме того, портлеты по сравнению с сервлетами, обладают следующей дополнительной функциональностью:

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

Контейнер портлетов можно рассматривать как расширение Web контейнеров.

Портлет генерирует фрагмент в форме гипертекста. Портал формирует окно портлета посредством добавления к сгенерированному фрагменту обрамления, включающее рамку и кнопки. Затем окна портлетов агрегируются в портальную страницу (рис. 12.3).

Для формирования портлетов могут использоваться либо JSP, либо такие фреймворки как Java Server Faces (JSF), Struts, Spring [162] и др.

Портлеты могут функционировать в нескольких режимах. Пользователь может работать с информационным наполнением, может настраивать внешний вид портлета в соответствии со своими предпочттениями, а администраторы могут конфигурировать портал для предоставления. Режим, который пользователи выбирают, определяет, какой интерфейс портлета они видят. Представление может находиться в одном из следующих состояний: «нормальное» (normal), «максимизированное» (maximized),. «минимизированное» (minimized), «закрытое» (closed). Свойства, существенные для размещения портлетов хранятся в дескрипторе.

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

Концепция порталов создавалась постепенно в течение достаточно длительного промежутка времени. Еще за много лет до появления самого терминов «портал» и «портлет» разработчики сайтов широко использовали такие приемы как введение динамического контента, фреймы, элементы персонализации страницы, однако различные Web-серверы и серверы приложений обеспечивали эти возможности разными способами. С появлением концепции портала появилась необходимость стандартизации средств построения портальных приложений. В рамках технологии JEE в 2003 году появилась спецификации JSR-168, которая была разработана совместно фирмами IBM и Sun Microsystems, которая определяла портлеты, написанные на языке Java. В 2007 году появилась вторая версия данной спецификации под номером JSR-286 [163], которая является расширением версии 1. Обе версии совместимы на двоичном уровне и это означает, что все портлеты, созданные в соответствии со спецификацией JSR-168 могут работать в контейнере, созданном в соответствии со спецификацией JSR-286.

На практике портлеты, созданные в соответствии со специцификацией JSR-168 продолжают активно использоваться.

Функции для работы с портлетами определены в пакете javax.portlet. API портлетов определены таким образом, чтобы можно было провести четкую границу между портлетом и портальной инфраструктурой.

Хотя API портлетов во многом похожи на API сервлетов, но имеются и отличия, в частности, для контейнер портлетов различает и позволяет поддерживать как состояние портлета, так и состояние окна. Состояние окна определяет, какую часть экранной страницы занимает данный портлет. Окно может находиться в одном из 3-х состояний: нормальном, минимизированном или максимизированном.

В соответствии со спецификацией JSR-168 определяются следующие методы интерфейса Portlet: init(), processAction(), render(), destroy().

Метод init() используется для инициализации портлета.

Метд processAction() вызывается для обработки действий пользователя в портлете.

Метод render() вызывается при необходимости перерисовки изображения портлета.

Метод destroy() вызывается перед удалением портлета из памяти.

Портлет может находиться в одном из трех состояний:

• View (Представление);
• Edit (Редактирование);
• Help (Помощь).

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

Наряду с интерфейсом Portlet, в пакете определется класс GenericPortlet, где метод render() определен таким образом, что управление в зависимости от текущего состояния портлета.передается одному из методов: doView(), doEdit() или doHelp(). Большинство реальных портлетов наследуют от класса GenericPortlet.

Ключевым при работе с портлетом безусловно является метод processAction(), который работает с объектами типа запрос и ответ — объекты ActionRequest и ActionResponse соответственно. Для метода render() и вызываемых им методов doXxx() в качестве аргументов и результатов выступают объекты RenderRequest и RenderResponse. Используя эти объекты, портлет может управлять состоянием и взаимодействовать с другими портлетами, сервлетами, принимать данные, вводимые пользователем в экранные формы портлета, создавать изображение для отображения в портале и посылать его клиенту и определять состояние портлета.

Запрос клиента инициируется при помощи ссылок URL, создаваемых портлетом. URL портлета могут быть двух типов: URL действия и URL перерисовки. Портлет создает свои URL, вызывая методы createActionURL и createRenderURL интерфейса RenderResponse. Эти методы возвращают интерфейс PortletURL. URL перерисовки может быть уточнен указанием состояния портлета, для которого этот URL применяется. Обычно запрос клиента, инициируемый URL действия, превращается в один запрос действия и много запросов перерисовки — по одному на каждый портлет на странице портала. Если портлет может кешироваться (это определяется в дескрипторе портлета), метод render может не вызываться.

Портлет являются настраиваемыми элементами. Настройки портлета сохраняются в виде наборов пар «имя — значение». За сохранение конфигурации портлета отвечает контейнер. Программист работает с настройками посредством объекта типа PortletPreferences, который имеет методы setValue() и getValue() установки (изменения) значений настроек и чтения их значений соответственно.

Портлеты упаковываются как стандартные в JEE Web-архивы (файлы WAR), которые кроме дескриптора развертывания web.xml, дополнительно содержат дескриптор портлета — portlet.xml, в котором определены элементы конфигурации портлета.

Основными средствами обеспечения безопасности портлетов в рамках спецификации JSR-168 являются возможность установки в дескрипторе портлета флажка, требующего, чтобы портлет работал только через защищенный протокол HTTPS и возможности аутентификации пользователей и ролей, при этом не определяет, каким образом реализованы пользователи и их роли. Кроме того, определяется библиотека тегов JSP, которая помогает отображать портлет при помощи технологии Java Server Pages. При реализации портлетов довольно часто в методе, например, doView() выполняется логика, связанная с анализом состояния, возможно, некоторая бизнес-логика, а для отображения портлет вызывает страницу JSP, формирующую код фрагмента HTML-страницы.

При вызове страницы JSP ей передаются запрос и отклик портлета. Перед вызовом страницы портлет может сохранить какие-то объекты как атрибуты запроса. Страница может направлять запрос в портлет, определяя адрес портлета через теги специальной библиотеки.

За агрегацию фрагментов, поставляемых разными портлетами, в полную страницу портала отвечает контейнер портлетов. Стандартизация портлетов (как и само осознание концепции порталов) несколько задержалась. На момент создания спецификации уже существовало большое число реализаций серверов порталов, в которых использовались фирменные средства и собственные API. Спецификация JSR-168, однако, была принята производителями серверов порталов, и в настоящее время большинство продуктов этого класса проходят или уже прошли процесс адаптации к стандарту. Вместе с тем, эти продукты вынуждены поддерживать и свои старые API, так что различия в диалектах API быстро исчезнуть не могут.

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

В 2007 году в рамках Java Community Process была опубликована окончательная версия второй версии спецификации портлетов (JSR-286), которая, дополняет предудущую спецификацию, обеспечивая стандартизацию некоторых возможностей, не охваченных в JSR-168. В качестве новых элементов, появившихся в рамках спецификации JSR-268 можно выделить следующие:

• обеспечение механизмов обмена событиями между портлетами: портлет может объявлять события, которые он хочет генерировать, и события, которые он хочет получать; контейнер работает как диспетчер событий;
• поддержка работы с фильтрами, которая выражается в возможности преообазовывать «на лету» как входную, так и выходную информацию; работы с фильтрами,
• обеспечение возможности для портлетов совместно использовать общий сеанс (сеанс пользователя) и данные, относящиеся к общему сеансу;
• обеспечение поддержки работы фреймворками Java AJAX, Server Faces, Struts и др.

Рис. 12.4. Процесс создания портлета
Обычно портал получает информационное наполнение для своих портлетов из многих как внутренних, так и внешних источников. Чтобы интегрировать новый источник, администратор портал должен адаптировать информационное наполнение к формату, который воспринимается порталом, что может оказаться весьма длительным и трудоемким процессом.

Возможна два альтернативных подхода к решению данной задачи.

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

Подобный подход требует написания кода портлета, обеспечивающего пользовательский интерфейс, извлечение данных и развертывания портлета. Альтернативный подход заключается в том, что удаленный Web-сервис сам будет генерировать фрагмент разметки страницы, который непосредственно будет включаться в страницу нашего портала. Второй подход предполагает использование специальных посредников, использование которых, позволяет позволяют провайдерам поставлять контент без использования ручных настроек (рис. 12.4).

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

Подобный стандарт создан в рамках организация Organization for the Advancement of Structured Information Standards (OASIS) это Web-службы для удаленных порталов (Web services for remote portals, WSRP).

Спецификация WSRP является продуктом международной организации Organization for the Advancement of Structured Information Standards (OASIS, Организация по развитию стандартизации структурированной информации), являющейся консорциумом, содействующим принятию технических стандартов. Версия 1.0 спецификации WSRP была закончена в 2003, а версия 2.0 появилась в 2008 году [164].

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

WSRP работает следующим образом. Поставщики информационного контента реализуют свой сервис как Web-сервис удаленного портала и публикуют ее, например, в UDDI. Следует заметить, что удаленные и локальные портлеты могут работать на одном портале и для конечного пользователя они неразличимы.

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

Потребитель WSRP – представляет собой клиент Web-сервиса, который вызывает предлагаемый поставщиком WSRP сервис и обеспечивает среду взаимодействия пользователя с портлетами, предлагаемыми одним или несколькими поставщиками; обычно роль потребителя WSRP играет портал.

Реально Web-сервисом является не WSRP-портлет, а поставщик WSRP, именно он имеет стандартное описание на языке WSDL и набор конечных точек. Обращение к WSRP-портлету возможно только через поставщика. Поставщик принимает SOAP-запрос, выделяет из него обращение к портлету и упаковывает фрагмент разметки, генерируемый портлетом, в ответное SOAP-сообщение. В функции же потребителя WSRP входит упаковка в SOAP-запрос параметров формы, поступившей от пользователя, и выделение из SOAP-отклика фрагмента разметки, присланного поставщиком и WSRP-портлетом. В рамках спецификации WSRP определены два обязательных и два не обязательных интерфейса, которые должны реализовывать поставщики WSRP и которые должны использовать потребители WSRP для взаимодействия с удаленными портлетами. Стандартизация этих интерфейсов дает возможность потребителю WSRP обращаться к любому поставщику. Обязательными для реализации интерфейсами WSRP являются интерфейс описания сервиса (Service Description Interface) и интерфейс разметки (Markup Interface). Через Интерфейс описания сервиса потребители могут запрашивать, какие портлеты предлагает поставщик и получать информацию о самом поставщике. Интерфейс разметки (MarkupInterface) предназначен для поддержки взаимодействия поставщика с удалёнными портлетами; он позволяет , посылать им формы, полученные от пользователя портальной страницы, и получать от них информацию о текущем состоянии портлета. Не обязательным интерфейсом WSRP является интерфейс регистрации (Registration Interface), предназначен для поддержки процесса регистрации потребителя перед как тот сможет обратиться к сервису, что позволяет поставщику сервиса адаптировать свое поведение применительно к определенному типу потребителя; через этот интерфейс поставщик и потребитель могут обмениваясь сведениями о себе. Интерфейс управления портлетом (Portlet Management Interface) позволяет пользователю управлять жизненным циклом удаленного портлета и настроить его поведение.

Все перечисленные выше интерфейсы WSRP представляют собой XML-протоколы и, соответственно, платформенно независимы.

Следует особо отметить, что WSRP не заменяет стандарты Web-сервисов, а дополняет их и предствляет собой надстройку над ними.

Все взаимодействия между потребителем и поставщиком WSRP осуществляются по протоколу SOAP, а операции интерфейсов WSRP определяются в WSDL-описании WSRP. Использование подобного подхода позволяет осуществлять публикацию WSDL-описаний WSRP-портлетов в реестрах UDDI.

Типовой типичный сценарий использования WSRP на основе технологии UDDI, выглядит следующим образом.

1. Провайдер разрабатывает набор портлетов, назначая WSRP-поставщика и отображая их как WSRP-портлеты. Если провайдер хочет сделать эти портлеты использовались как удаленные, то он публикует описания в реестре.
2. Пользователь, заинтересованный в работе с удаленными портлетами ищет портлет нужный ему портлет, используемые предоставляемые порталом средства, либо независимое приложение.
3. После обнаружения желаемого портлета пользователь добавляет новое приложение к одной из своих портальных страниц.
4. Если пользователю не разрешено добавление портлетов к своей странице, то администратор портала находит их в UDDI-реестре и сделать их доступными для пользователей, добавив во внутренний реестр портала.
5. После того как удаленный портлет помещен на портальную страницу пользователя, он увидит на своей портальной странице выполняющийся удаленно портлет, при обращении к которому портальный сервер выполняет запрос к соответствующему Web-сервису посредством отправки SOAP послания, а в ответ получает SOAP послание, содержащее фрагмент на языке разметки страниц, который портал интегрирует в отображаемую страницу. При этом конечный пользователь полностью избавлен от необходимости знать детали работы WSRP.

Как у всякой технологии у технологии портлетов имеются свои достоинства, свои недостатки и области применения.

Достоинства портлетов.

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

2. Внешний вид и функциональность портлетов можно настраивать для различных групп пользователей, а сами пользователи могут настраивать внешний вид портлетов в соответствии со своими предпочтениями.

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

4. Портлеты позволяют сложные приложения на отдельные задачи по принципу — одна группа тесно связанных задач представлена одним портлетом.

5. Портлеты позволяют относительно легко добавлять новую функциональность к уже существующим приложениям.

6. Портлеты подобно другим Web-приложения хорошо совместимы с брандмауэрами (firewalls).

Недостатки

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

1. Сложные пользовательские интерфейсы плохо переводятся в портлеты, использующие языки разметки.

2. Если требуется реализовать пользовательские интерфейсы с часто обновляемыми данными, то использование портлетов может привести к замедлению работы системы, поскольку, когда обновляете один портлет, то перерисовывается вся портальная страница.

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

4. Имеются проблемы при работе с формами (Внутренние фреймы разрешены, но только пользователи Microsoft Internet Explorer могут их видеть).

5. Портлеты полностью не стандартизированы, и они еще не поддерживаются на стольких платформах как другие Java-технологии.

Области применения

Использование портлетов безусловно целесообразно в случае, если цель проекта состоит в том, чтобы объединить Web-приложения и информацию в одном удобном месте, если требуется использовать сервисы внешних поставщиков и (или) выступать в качестве поставщика сервиса. Если пользователи активно перемещаются и пользуются мобильными устройствами, то портлеты — очевидный выбор.

Если цели проекта отличаются указанных выше, то следует рассмотреть другие альтернативы.

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

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

Процесс и функция

Двумя важными понятиями являются бизнес-процесс и функция. Обычно на вопрос «Чем функция отличается от бизнес-процесса?» многие дают правильный ответ: «Функция является частью бизнес-процесса, а бизнес-процесс состоит из функций». Тем не менее, стоит посмотреть на эти понятия внимательнее.

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

Давайте рассмотрим понятие бизнес-процесс и функция на примере деятельности по подготовке ценового предложения клиенту (рис. 10). Компания получает от клиента запрос на подготовку ценового предложения по производству и поставке продукции. Первую функцию в этой деятельности, которая называется «Получение и уточнение запроса от клиента», выполняет отдел продаж. Далее уточненный запрос от клиента отдел продаж передает в два других подразделения: производственный отдел и транспортный отдел. Эти два подразделения выполняю следующие две функции: «Расчет производственной себестоимости» и «Расчет транспортной составляющей». Далее рассчитанные данные производственной себестоимости и транспортных расходов передаются в отдел продаж, который на их основе выполнят четвертую функцию — оформляет и отправляет ценовое предложение клиенту.

Рис. 10. Бизнес-процесс «Подготовка ценового предложения клиенту»

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

Вопрос, который часто задают на практике: «Можно ли функцию назвать бизнес-процессом»? Ответ: «Конечно можно». Рассмотрим этого на примере функции по расчету производственной себестоимости. По отношению к процессу в целом, эта деятельность, как составляющая процесса, является функцией. Но при дальнейшем разбиении этой функции на шаги ее можно назвать бизнес-процессом по отношению к своим составным частям.

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

Интересно рассмотреть, как к решению задачи именования процессов подходят на практике различные российские и западные компании. На рис. 11 приведен фрагмент дерева бизнес-процесса «Управление персоналом», на примере которого рассматриваются подходы к именованию различных уровней бизнес-процессов в различных компаниях.

Рис. 11. Декомпозиция бизнес-процесса и названия уровней

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

Интересно также рассмотреть подходы, используемые западными компаниями. Например, организация APQC, которая занимается стандартизацией и разработкой типовых моделей бизнес-процессов, в том числе и отраслевых на первом уровне использовала понятие «процессная категория», на втором уровне «процессная область», на третьем — «процесс», на четвертом «действие», а на пятом «задача» (рис 11).

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

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

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

Способы описания бизнес-процессов

Существуют два разных способа описания бизнес-процесса: упрощенный способ — вертикальное описание и детальное горизонтальное описание процесса (рис. 12).

Рис. 12. Вертикальное и горизонтальное описание бизнес-процессов

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

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

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

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

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

Совмещение подходов к описанию процессов

Практика эффективного описания бизнес-процессов показала целесообразность совмещения на разных уровнях двух видов описания — вертикального и горизонтального.

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

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

* * *

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

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

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

Несмотря на то что до сих пор нет четкого определения микросервисов, известен набор характеристик, помогающих идентифицировать этот архитектурный стиль. По сути, микросервисная архитектура — это метод создания распределенных приложений в виде набора независимо разрабатываемых и развертываемых небольших сервисов, запускаемых как один или несколько изолированных процессов. Все это очень похоже на давно известную сервисную архитектуру (Service-Oriented Architecture, SOA), которая решает ту же задачу — снижение сложности ИТ-ландшафта. Иногда утверждается, что микросервисы — это и есть правильно реализованная SOA, однако следует обратить внимание на ряд ключевых различий между этими подходами.

Во-первых, в качестве программных интерфейсов для взаимодействия с микросервисами, как правило, используют RESTful API и асинхронный обмен сообщениями через очереди (рис. 1), а для реализации сервисной архитектуры использовался протокол SOAP. Строго говоря, SOA не определяла способ взаимодействия между сервисами, но на момент ее появления какой-либо реальной альтернативы использованию SOAP не было. Из-за этого сервисы и микросервисы различаются по логической организации. Микросервисы реализуют возможность управления структурированным информационным ресурсом посредством ограниченного набора операций: чтения и обновления его отдельных частей. А все взаимодействия строятся без сохранения на сервере состояния клиента. Cервисы в SOA не используют концепцию ресурса, а представляют собой набор операций над некоторыми объектами, которые четко нигде не определены. По сути, SOA-сервис — это набор из множества методов, выражаемых глаголами инициации операций по созданию или модификации таких объектов.

Рис. 1. Программные интерфейсы микросервиса

Во-вторых, множество SOA-сервисов зачастую развертывались в одном процессе: сервере приложений, веб-сервере или сервисе интеграционной среды, — тогда как микросервисы принято развертывать в изолированном окружении (рис. 2). Например, при работе с открытым ПО пакет установки часто включает в себя не только само приложение, но и дистрибутивы системы управления базой данных, веб-сервера, другого необходимого ПО, а также уже настроенные файлы конфигурации. Установка и запуск всех необходимых компонентов полнофункционального решения производятся буквально одной командой. Неважно, запускается система в облаке или на локальном компьютере, — такой подход меняет жизненный цикл разработки и эксплуатации программных компонентов, обеспечивая независимость командам разработки в выборе инструмента и способа организации данных, с одной стороны, и стирая различия между средой разработки и средой эксплуатации, с другой.

Рис. 2. Разнообразие программных средств при использовании микросервисной архитектуры

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

Появление микросервисов в архитектуре информационных систем можно сравнить с переходом от функционального к объектно-ориентированному программированию. До середины 1990-х годов разработка представляла собой написание пакетов функций, которые потом вызывались из основного приложения. Было крайне важно выделить из разных частей программы схожие фрагменты бизнес-логики и реализовать их в единой библиотеке. С появлением объектно-ориентированного подхода все изменилось. Общий функционал реализуется в базовом классе в виде расширяемого набора данных и методов, которые можно в дальнейшем переопределить. Прикладной программист наследует свое приложение от готового класса, разрабатывая лишь небольшой объем нового кода для расширения некоторых методов. Точно так же и микросервис «переопределяет» небольшую часть функционала вызвавшего его приложения. В микросервисе реализуется то, что не реализовано в исходном приложении или реализовано не совсем так, как надо. Этот принцип формулируется как «начните с монолитного приложения» (Monolith First) и является одним из главных ключей к пониманию микросервисной архитектуры.

Микросервисы: смена архитектурной парадигмы?

Ряд характеристик микросервисов, таких как децентрализованный выбор стека технологий или независимая организация данных, дают основание считать, что микросервисы нарушают привычные правила «хорошей» корпоративной архитектуры. Архитекторы предприятий на протяжении многих лет методично прививали организации набор определенных принципов. Часть из них нашла свое отражение в политиках и руководствах. Другая существует в виде неформальных договоренностей и соглашений. Третья реализуется архитекторами в форме архитектурного надзора за проектами. Эти правила хорошо известны и воспринимаются как само собой разумеющееся: необходимо стремиться к унификации серверов приложений, СУБД и инструментов разработки, избавляться от нескольких версий одного и того же программного средства, консолидировать информацию и приводить структуры данных к единому формату.

Принципы микросервисной архитектуры выглядят отрицанием всех этих идей. Каждый микросервис включает в себя свой стек технологий, выбор которого осуществляется непосредственным разработчиком. Вместо единой базы данных в каждом микросервисе используется собственный инструмент хранения информации, причем выбор реляционной или нереляционной СУБД, способа организации данных, атрибутивного состава и программных интерфейсов для предоставления данных ни с кем не согласуется. Более того, сходные по своему характеру данные могут быть распределены по нескольким экземплярам микросервиса. Зачастую микросервис проще переписать заново, чем доработать, а добавление нового функционала в приложение предпочтительней реализовывать в виде нового микросервиса, а не посредством переработки уже существующего отлаженного кода.

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

Микросервисы с точки зрения ИТ эксплуатации

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

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

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

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

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

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

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

Архитектуру, отвечающую этим требованиям, помогает построить так называемое сине-зеленое развертывание (рис. 3). Не нужно устанавливать новый релиз микросервиса поверх существующего (синий), а следует создать еще одну виртуальную машину, в которой запустить новый экземпляр сервиса (зеленый). Затем перенаправить на него небольшую часть запросов — например, только от пользователей, которые участвуют в приемочном тестировании этого релиза. Если что-то пойдет не так, то в любой момент можно перевести запросы этой группы пользователей на предыдущую версию микросервиса. При этом речь не обязательно идет об ошибках в коде. Причинами отказа от дальнейшей эксплуатации релиза могут быть логические ошибки проектирования, неверно сформулированные требования или просто негативная обратная связь от пользователей.

Рис. 3. Один из вариантов архитектуры развертывания микросервисов

Но как не потерять данные, которые успели накопиться в неудачном релизе? Общего ответа на этот вопрос нет, но есть несколько частных случаев, для которых эта задача легко решается. Один из распространенных шаблонов проектирования распределенных систем предписывает разделять запросы на чтение данных и команды на их модификацию (command-query responsibility segregation). Если микросервис был спроектирован в соответствии с этим принципом и обрабатывал только запросы на чтение, то новых данных от пользователей он еще не накопил, и после возврата маршрутизации запросов на предыдущую версию сервиса новую неудачную версию можно просто выключить. С обработкой команд задача немного сложнее. Тем не менее команды на изменение данных обычно не обрабатываются синхронно, а помещаются в очереди сообщений, что обеспечивает большую гибкость в организации логики обработки. Можно продублировать поток сообщений и сравнить результаты их обработки разными версиями сервиса, сохранить часть сообщений для последующей обработки проверенной версией, написать обработчики для отмены изменений и сделать многое другое.

Построение таких архитектур требует дополнительных усилий, но себя окупает. Задача архитектора всегда заключалась в  правильном разделении системы на компоненты — так, чтобы их можно было создавать, развивать и заменять независимо друг от друга, силами небольших специализированных команд, использующих наиболее подходящий для конкретной задачи набор технологии. Эта деятельность никогда не была простой. Невозможно предвидеть требования, которые будут сформулированы через год или два, строить прогнозы относительно успешности в будущем тех или иных технологий, разрабатывать структуры для пока еще не собранных данных. Однако еще одно свойство микросервисов — эволюционирующая архитектура — позволяет сделать и это. Речь идет об изначальном построении системы таким образом, чтобы в дальнейшем ее развитие заключалось не в переработке существующих модулей, а в присоединении к приложению новых компонентов и источников данных. Это чем-то напоминает архитектуру микроядра, используемую при разработке ОС. Микроядро реализует самое необходимое, а все прикладные функции в такой архитектуре выносятся во внешние модули. Только в случае операционных систем речь идет о драйверах устройств, функциях работы с файловыми системами и сетями. В микросервисной архитектуре во внешние подключаемые модули выносится прикладной функционал. Это свойство микросервисов часто называют «организацией сервисов вокруг бизнес-возможностей».

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

Варианты использования

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

Проекты создания «единого окна», интегрирующего в общий пользовательский интерфейс функционал десятка разрозненных приложений, никогда не были простыми. В рамках таких проектов сложно обойтись без [I]обновления унаследованных приложений[$]. Существующие системы не были предназначены для интеграции — предполагалось, что с ними будут работать люди, поэтому о хороших программных интерфейсах со стороны таких приложений остается только мечтать. Если программные интерфейсы и существуют, то они плохо абстрагированы, несут на себе печать конкретной реализации, а ограничения унаследованных систем по уровню доступности, количеству одновременных обращений или актуальности данных делают невозможным их практическое использование. Рядом с такой системой приходится создавать онлайн-хранилище данных и конвейер обработки событий. Впрочем, подобные затраты не напрасны — они позволяют не только интегрировать такие системы в композитные ИТ-решения, предназначенные для клиентов или сотрудников, но и реализовывать новый функционал без внесения изменений в унаследованное приложение. Можно пользоваться уже имеющимися в системе функциями и данными, но реализовывать новые бизнес-процессы в отдельных изолированных от приложения микросервисах. Это более быстрая и экономически обоснованная альтернатива замене или полному переписыванию устаревших систем.

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

***

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

Максим Смирнов (mxsmirnov@gmail.com; mxsmirnov.com) — главный архитектор компании «Бинбанк Диджитал» (Москва).