АРИС Текст 2. Водяхо А. И., Выговский Л. С., Дубенецкий В. А., Цехановский В. В. Архитектурные решения информационных систем
 Скачать 4.65 Mb.
|
|
12.3. Корпоративные сервисные шины Общие принципы построения. Как указывалось выше, основная задача интеграции приложений состоит в объединении функций двух или более приложений с целью получения новой функциональности. Применительно к КИС можно выделить два основных типа задач интеграции приложений: задачи интеграции внутрикорпоративных приложений; задачи интеграции приложений, функционирующих в составе КИС разных организаций. Системы интеграции корпоративных приложений (Enterprise Applications Integration, EAI) – технологии, ориентированные на решение проблем интеграции различных ИС, приложений и данных внутри отдельной организации. Иногда для этих технологий используется аббревиатура A2A (Application-to-Application – приложение-приложение). Системы интеграции между организациями, которые обычно называют Business-to-Business (Business-to-Business Integration), представляют собой – технологии, ориентированные на обеспечение безопасного, надежного информационного обмена между ИС различных организаций. Эти технологии направлены на автоматизацию бизнес-процессов в рамках «расширенных организаций», что создает предпосылки для создания разного рода виртуальных организаций. Провести четкую границу между интеграцией типа А2А и В2В не всегда просто, поскольку в рамках крупной корпорации, даже если приложения работают в рамках одной организации, они могут быть разнесены территориально и находиться в разных автономных системах, быть отделены с помощью firewalls и подчиняться разным политикам безопасности.  Рис. 12.5. Варианты интеграционных решений Технологии и системы управления бизнес процессами управления бизнес-процессами являются результатом естественной эволюции классических систем делопроизводства и документооборота (workflow systems), систем класса EAI и B2B. Ключевое отличие состоит в том, что, если традиционные системы управления документооборотом предназначались преимущественно для обмена информацией между людьми, современные системы управления бизнес процессами класс А2А ориентируются на обмен данными между приложениями, а системы класса B2B - на интеграцию данных в межведомственной среде, технологии BPM интегрируют данные, приложения и людей через единые бизнес-процессы. Данный подход достаточно адекватно отражает современную точку зрения, состоящую в том, что основным предметом интеграции должны быть бизнес-процессы и, в частности бизнес процессы, которые «пересекают» границы различных приложений, подразделений и организаций. Когда говорят об интеграционных решениях, то обычно выделяет 3 альтернативных подхода (рис. 12.5): точка-точка (point-to-point); шлюз (hub-and-spoke); шина (bus). Топология интеграционного решения отражает различные способы взаимодействия приложений, среди которых можно выделить соединения точка-точка, шлюзы и шины, которые показаны на рис. 12.5,а,б,в, соответственно. Соединение типа точка-точка предполагает, что интегрируемые приложения устанавливают прямые связи друг с другом, при этом каждая из связей может быть реализована уникальным способом. Для реализации каждой связи может использоваться собственная технология. Очевидно, что это самый простой и в ряде случаев самый действенный подход к решению задачи интеграции приложений, когда требуется объединить 3-4 приложения. Однако по мере увеличения числа интегрируемых приложений связи между приложениями становятся многочисленными, что резко повышает трудоемкость управления ИС. Кроме того, при модификации одного из приложений приходится разрабатывать несколько новых адаптеров, что означает усложнение поддержки всей системы. Основными недостатками интеграции приложений по принципу точка-точка являются следующие: недостаточная гибкость; сложность поддержки многочисленных соединений типа «точка-точка»; изменения в одном приложении сказывается на других приложениях; логика маршрутизации часто зашивается в код; часто отсутствует общая модель безопасности; используются разные API; используются разномастные протоколы; сложности с созданием фреймворков; сложности с поддержкой асинхронных взаимодействий; сложности реализации бизнес процессов с очень большим временем жизни; проблемы с мониторингом состояния; низкая надежность. Переход от модели взаимодействия точка-точка к моделям взаимодействия на основе централизованного шлюза (рис. 12.5,б) или на основе шины (рис. 12.5,в) обусловлен существенным уменьшением количества интерфейсов. Модели интеграции на основе шлюза и шины относятся к классу программного обеспечения промежуточного уровня (middleware), обеспечивающего трансформацию, транспортировку, маршрутизацию данных. Следует отметить, что с использованием термина EAI имеются некоторые особенности. В частности, выше данный термин употреблялся в смысле EAI технологии – технологии, ориентированные на реализацию интеграции типа А2А, до начала 2000-х годов термином EAI обозначались также продукты, предназначенные для реализации данного типа интеграции. Однако в начале 2000-х годов появились продукты нового поколения, которые чаще всего стали называть Корпоративная Сервисная Шина (Enterprise Service Bus, ESB). [165], поэтому используя термины EAI и ESB, ряд авторов, в частности [165, 166,.167] рассматривают системы EAI как предшественников ESB, при этом указывают на два основных различия между ними. Первое различие состоит в том, что EAI системы построены по принципу шлюза и используют модель «вставь и говори» (hub-and-spoke), которая представляет собой централизованную архитектуру, в которой весь обмен данными осуществляется через центральный хаб или брокер. ESB использует шинную модель, которая имеет распределенную архитектуру и может быть реализована как несколько отдельных распределенных подсистем. Второе различие состоит в том, что в отличие от EAI ESB системы ориентированы на использование открытых стандартов, таких как Java Message Service (JMS), XML, JEE Connector Architecture (JCA), и Web-сервисы. В последние годы появились такие новые ИТ-технологии как Service Oriented Architecture (SOA), Enterprise Application Integration (EAI), Business-to-Business (B2B) и Web services. Все они в значительной мере направлены на поддержку реализации интегрированных бизнес процессов. Наилучшим образом организовать поддержку интегрированных бизнес процессов можно с помощью ESB. ESB – это новый по отношению к EIA интеграции подход к интеграции, который представляет собой интеграционную платформу, которая реализует комплексный подход к интеграции и позволяет использовать различные механизмы интеграции: работу с очередями сообщений; Web-сервисы; преобразование данных; интеллектуальный роутинг. ESB – позволяет интегрировать приложения и бизнес процессы как внутри организации, так и между организациями. Корпоративные ИС в большинстве своем представляют собой системы, управляемые событиями. События могут наступать в произвольный момент времени в произвольном порядке. Отдельные бизнес службы также работают по принципу управлению событиями, поэтому они могут работать независимо. ESB представляет собой шину (backbone), которая работает по принципу слабо связанной системы, управляемой событиями. Каждый источник данных представлен в форме конечных точек (endpoints). ESB обеспечивает собой достаточно общий подход к интеграции, причем интеграцию можно реализовывать постепенно, добавляя отдельные элементы. ESB первого поколения появились в 2002 году и были поддержаны практически всеми ведущими поставщиками корпоративных решений. ESB второго поколения – это инфраструктура, которая поддерживает достаточно широкий спектр технологий, работу с сообщениями, Web-сервисы широкие возможности по преобразованию и маршрутизации сообщений. ESB второго поколения появились и активно используются начиная с середины 2000-х годов. Концепция ESB самым тесным образом связана с концепцией СОА. При этом ESB поддерживает концепции реализации СOA следующим образом: представление службы отделяется от ее реализации; Основные функции ESB включают в себя: обеспечение интерфейсов взаимодействия; отправка сообщений и маршрутизация; преобразование данных; реакция на события; управление политиками; виртуализация. Типовой список требования, предъявляемых к ESB со стороны пользователей выглядит следующим образом: ESB должна иметь достаточную пропускную способность для того, чтобы обеспечивать одновременное функционирование достаточно большое число соединений; ESB должна поддерживать несколько стилей интеграции, в частности, интеграцию, основанную на событиях и интеграцию, ориентированную на сообщения; ESB должна позволять приложениям работать с сервисами как напрямую, так и через адаптеры, при этом должен иметься достаточный набор таких адаптеров, к числу которых могут быть отнесены следующие: адаптеры доступа к ERP системам, адаптеры доступа к компонентам, адаптеры доступа к Java объектам, адаптеры доступа к данным, адаптеры доступа к унаследованным системам. Минимально необходимые возможности ESB: ESB представляет собой логический архитектурный компонент, который приводит интеграционную инфраструктуру в соответствие с принципами СОА и реализуется в виде распределенной гетерогенной инфраструктуры; интегрируемые приложения представляются в виде набора сервисов. ESB реализует две основные функции: преобразование форматов сообщений; маршрутизацию сообщений. Внедрение и адаптация шлюза на основе интеграционного сервера или шины корпоративных сервисов связаны с существенными капитальными вложениями. С другой стороны, необходимость использования интеграционного решения класса middleware продиктована не только трудоемкостью управления моделью точка-точка, но и ее недостаточной надежностью. Модель точка-точка может быть использована для системы с небольшим числом приложений на начальной стадии интеграции. С ростом количества информационных ресурсов необходимо использование интеграционного решения более высокого порядка, к которым относятся интеграционный сервер и шина корпоративных сервисов. В качестве реализации модели интеграционного сервера можно назвать продукты класса EAI, объединяющие корпоративные приложения управления кадрами, управления отношениями с клиентами, бухгалтерии и т.д. Модель шины реализуют продукты класса ESB, объединяющие Web-сервисы, которые разработаны на базе существующих корпоративных приложений. Интеграционное решение EAI построено на централизованных принципах. Это означает, что все функции промежуточной обработки сообщений выполняются единым интеграционным сервером, включая трансформацию и перераспределение сообщений. Среди преимуществ EAI выделяется эффективность администрирования корпоративной системы, среди недостатков — высокая стоимость приобретения, не позволяющая предприятиям малого бизнеса использовать интеграционное решение данного класса. Модель интеграции на базе шины корпоративных сервисов ESB представляет собой информационную инфраструктуру, построенную на принципах СОА. Данные принципы предполагают, что объектами взаимодействия внутри предприятия являются Web-сервисы, представляющие функции приложений в виде автономных программных модулей. Все аспекты разработки и вызова Web-сервисов основываются на Web-стандартах XML и HTTP, что обеспечивает платформенно-технологическую независимость формата взаимодействия корпоративных приложений. Общим между моделями EAI и ESB является то, что они обеспечивают промежуточную обработку сообщений. Однако в модели ESB функции брокера и оркестровки сообщений являются техническими сервисами, которые могут происходить от разных поставщиков, быть физически распределенными, использовать разные технологии коммуникации. Несмотря на технические различия, продукты семейства ESB совместимы между собой, что обеспечивается политикой открытых интерфейсов (open interface policy). Независимость от поставщика позволяет использовать широкий спектр возможностей приобретения и аренды необходимого программного обеспечения. Это обеспечивает высокую степень адаптируемости, сосуществования, совместимости и взаимозаменяемости элементов ESB. Распределенная архитектура ESB характеризуется более сложным управлением и администрированием, но является более гибкой и масштабируемой. Кроме того, внедрение сервис-ориентированного подхода при взаимодействии корпоративных приложений не требует изменений во всех элементах системы и может происходить поэтапно, интегрируя лишь критические для бизнеса приложения.
Рис. 12.6. Архитектурная модель ESB Обобщенная архитектурная модель интеграционной подсистемы. В самом общем виде архитектурная модель ESB приведена на рис. 12.6. ESB можно рассматривать как многоуровневую (многослойную) систему, при этом можно выделить пять уровней: уровень сопряжения (адаптеры и интерфейсы); транспортный уровень; уровень реализации бизнес-логики; уровень управления бизнес-процессами; уровень бизнес управления (бизнес-правила, машины состояний). Уровень сопряжения. На данном уровне работают адаптеры, которые отслеживают события, происходящие в приложениях и в интеграционной подсистеме, и трансформируют объекты, передаваемые из приложения в транспортный слой и обратно, решая проблему разных интерфейсов. Для построения слоя сопряжения можно использовать либо готовые адаптеры, поставляемые производителем интеграционной платформы, или адаптер может быть разработаны интегратором. Возможности адаптеров оперировать сложными бизнес-объектами, уже имеющимися в интегрируемых прикладных системах, настройка интерфейсов, адресной информации и процедур трансформации, применяемые в готовых адаптерах вместо написания кода, позволяют ускорить внедрение интеграционного решения. Обычно разработчики платформ предоставляют документацию и инструментарий для разработки адаптеров. Адаптеры, используемые в составе интеграционных платформ можно разделить на две большие группы: технологические адаптеры и адаптеры для приложений. Технологические адаптеры используются для сопряжения стандартных технологических компонент и используются преимущественно в тех случаях, когда интегрируемое приложение не имеет открытых API и создание прикладных адаптеров невозможно, однако остается возможность интеграции с источником данных, которые используют такое приложение, в частности, с его базой данных. Примерами технологических адаптеров могут служить JDBC- и JMS- адаптеры. Адаптеры приложений разрабатываются специально для интеграции с конкретным приложением, например для сопряжения с ERP системами, такими как SAP и PeopleSoft. Транспортная подсистема. Транспортная подсистема (ТП), работающая в составе ESB, позволяет интегрируемым приложениям общаться друг с другом асинхронным образом, оформляя информацию в виде сообщений и передавая ее, например, через систему очередей. Асинхронность обмена сообщениями, позволяет интегрировать слабосвязанные приложения, ничего не знающие друг о друге, то есть разработанные без учета совместимости форматов и моделей данных и без учета способности отреагировать немедленно на полученную информацию. На данном уровне работают модули, отвечающие за управление и безопасность информации на уровне транспорта, кроме того, может выполняться простая обработка сообщений и их маршрутизация. ТП предоставляет разработчикам простой высокоуровневый интерфейс для подключения прикладных подсистем, что уменьшить объем низкоуровневого программирование. Уровень реализации бизнес-логики. На данном уровне реализуются функции, связанные с трансформацией и интеллектуальной маршрутизацией сообщений, которыми обмениваются интегрируемые прикладные системы. На этом уровне работают, в частности, брокеры сообщений, которые принимают сообщения от интегрируемых систем через ТП и через нее же отправляет их после анализа и обработки системам-адресатам. Обычно брокер выполняет следующие действия: принимает сообщения и направляет их по одному или нескольким адресам; преобразовывает форматы сообщений; выполняет агрегирование сообщений, разбивает поступающее сообщение на несколько сообщений и отправляет их по назначению, затем повторно собирать ответы в одно сообщение и возвращает их источнику. взаимодействует с внешними репозиториями с целью сохранения сообщений и получения данных; реализовывает вызовы Web-сервисов для выборки данных; обрабатывает сообщения о события и ошибках; выполняет маршрутизацию сообщений по явно указанному адресу или по содержимому или по теме сообщения. Брокеры используются преимущественно в интеграционной среде, основанной на передаче сообщений. Уровень управления бизнес-процессами. На данном уровне работают системы управления бизнес-процессами, при этом для управления бизнес-процессами используется bpel. Управление осуществляется посредством вызова Web-сервисов. Уровень бизнес управления. Данный уровень является надстройкой над уровнем управления бизнес-процессами. На данном уровне управление бизнес процессами осуществляется в терминах предметной области. При этом используются два основных механизма: бизнес-правила и машины состояний, которые используются для реализации событийного управления.  Рис. 12.7. Обобщенная структура интеграционной системы на базе ESB Типовая структура интеграционной системы на базе ESB. На рис. 12.7 показана обобщенная структура интеграционной системы на базе ESB второго поколения. Ядром системы является корпоративная интеграционная шина ESB, которая позволяет интегрировать бизнес-приложения, имеющие JMS- интерфейсы и поддерживающие работу с Web-сервисами. Кроме того, ESB позволяет пользователям работать с порталом, и поддерживает взаимодействие со службами каталогом. Обычно разработчики предлагают набор как платформенных, так и технологических адаптеров. В состав платформенных адаптеров обычно входят для взаимодействия с ERP системами, такими как SAP R/3, Siebel, Oracle Applications, PeopleSoft и др., а также средства для поддержки B2B взаимодействий. В состав технологических адаптеров обычно входят адаптеры для работы с компонентами (.Net, CORBA), адаптеры для работы с данными и Java-объектами. Кроме того, интегратор может сам разрабатывать необходимые адаптеры, например, для взаимодействия с унаследованными системами. В состав практически всех ESB входят bpel-процессоры (движки) и процессоры (движки) для работы с бизнес правилами. Для нормального функционирования ESB должна иметься определенная информационная инфраструктура. Часто эта инфраструктура определяется как набор сервисов, в состав которых обычно входят следующие группы сервисов: инфраструктурные сервисы; сервисы управления и мониторинга; сервисы оптимизации; сервисы разработки. Назначение и состав данных сервисов будет рассмотрен ниже на примерах конкретных систем. Следует заметить, что структура ESB носит обобщенный характер и реальные системы могут использовать существенно отличные архитектурно-структурные решения. Существующие решения ESB. Как указывалось выше, начиная приблизительно с 2005 года на рынке ИТ-продуктов предлагается очень много разнообразных интеграционных продуктов, кроме того, имеется достаточно много бесплатных ESB. Практически все крупные компании, работающие в области КИС предлагают собственные интеграционные решения. Ниже описан ряд альтернативных подходов к использованию интеграционных технологий. Достаточно подробно описаны подходы, развиваемые фирмами Microsoft и IBM. Подобный выбор обусловлен тем, что система BizTalk от Microsoft является наиболее распространенной, а система WebShpere от IBM является наиболее мощной, при этом BizTalk ориентирована средний и малый бизнес, а WebShpere – прежде всего на крупный бизнес. Microsoft BizTalk Server. BizTalk Server представляет собой семейство программных продуктов компании Microsoft, предназначенных для реализации интеграционных решений как типа А2А, так и типа и В2В. BizTalk также реализует функций сервера приложений. BizTalk позволяет реализовывать управление бизнес-процессами на внутрикорпоративном и межкорпоративном уровне. Используя BizTalk, организации могут создавать распределенные бизнес-процессы, интегрирующие различные приложения внутри предприятия, а также реализующие надежное и безопасное взаимодействие с партнерами организации как через локальную сеть и Интернет. BizTalk является одним из старейших приложений на рынке интеграционных решений, первая версия которого появилась еще в 2000 году. На момент написания книги были созданы следующие версии BizTalk: BizTalk Server 2000, BizTalk Server 2002, BizTalk Server 2004 (переписана с использованием .NET), BizTalk Server 2006, BizTalk Server 2006 R2, BizTalk Server 2009, BizTalk Server 2010. На протяжении своего существования архитектура BizTalk претерпела существенные изменения. Первая версия появилась еще до широкого распространения СОА и была ориентирована преимущественно на работу с очередями сообщений и В2В интеграцию. Последняя версия - BizTalk Server 2010 позиционируется как ESB с развитыми функциональными возможностями. BizTalk Server 2010, по существу, является версией BizTalk Server 2009 R2, так и не увидевшей свет в качестве коммерческого продукта. Предлагаемое решение выполняет функцию ESB и реализует поддержку СОА в гетерогенных вычислительных средах. Отличительной особенностью развиваемого фирмой Microsoft подхода к созданию линейки продуктов BizTalk состоит в том, что разработчики делают особый акцент на интеграции BizTalk с собственными серверными продуктами. В частности, BizTalk Server 2010 ориентировано на использование с такими широко используемыми продуктами как SharePoint Server 2010, Windows Server 2008 R2, SQL Server 2008 R2, .NET Framework 4 и Visual Studio 2010. System Center и Windows Server AppFabric. Взаимодействие с приложениями BizTalk осуществляет через адаптеры. В дистрибутиве с BizTalk поставляются большое число как технологических адаптеров, так и адаптеров приложения, в частности, технологические адаптеры для HTTP, SOAP, FTP, POP3, SMTP, SQL, MSMQ, MQSeries, Microsoft SharePoint. Кроме того, поставляются адаптеры к различными существующим корпоративным системам, таким как: SAP, Microsoft Dynamics CRM, Oracle eBusiness Suite и адаптеры поддержки таких корпоративных стандартов как EDI и RosettaNet и другие. Разработчики систем поставляют многие другие адаптеры.  Рис. 12.8. Обобщенная структура BizTalk Server Обобщенная структура BizTalk Server показана на рис. 12.8. Основу BizTalk составляет процессор (движок), в состав которого входят две подсистемы: - подсистема работы с сообщениями (Messaging); - подсистема управления бизнес-процессами (Orchestration). Подсистема работы с сообщениями обеспечивает поддержку работы с различными приложениями посредством адаптеров. Данная подсистема позволяет работать с большим числом различных протоколов и форматов данных, включая Web-сервисы и очереди сообщений. Подсистема управления бизнес-процессами представляет собой bpel-движок, реализующий управление бизнес-процессами в форме оркестровки. Данный движок работает «поверх» подсистемы работы с сообщениями. Кроме перечисленных выше, в состав BizTalk входят еще четыре компонента: - процессор бизнес-правил (Business Rule Engine); - подсистема контроля и управления (Group Hub); - подсистема единого входа (Enterprise Single Sign-On facility); - подсистема мониторинга бизнес-активностей (Business Activity Monitoring). Процессор бизнес-правил обеспечивает поддержку работы с бизнес-правилами. Подсистема контроля и управления обеспечивает для разработчиков и администраторов возможность мониторинга и управления движками в процессе работы. Подсистема единого входа позволяет реализовывать обмен аутентификационной информацией между Windows и не-Windows системами. Подсистема мониторинга бизнес-активностей позволяет отслеживать ход выполнения бизнес-процессов в бизнес терминах, при этом пользователи могут определять состав отображаемой информации. BizTalk Server хорошо поддержан инструментальными средствами разработки и сопровождения, в состав которых входят: - BizTalk Server Orchestration Designer; - BizTalk Editor; - BizTalk Mapper; - BizTalk Messaging Manger; - BizTalk Framework; - BizTalk Administration Tool; - Pipeline Editor. BizTalk Server Orchestration Designer представляет собой инструментальное средство для разработки бизнес-процессов. BizTalk Editor представляет собой редактор XML документов. BizTalk Mapper – это среда, в которой можно в графическом виде определить процесс преобразования XML документов. BizTalk Messaging Manger позволяет определить процесс обмена информацией. BizTalk Framework позволяет описывать маршрутизацию и анализировать принимаемые и передаваемые данные. BizTalk Administration Tool позволяет реализовывать процесс аналитической обработки о работе BizTalk. Pipeline Editor позволяет от начала до конца отслеживать процесс обработки документа [168]. Интеграционные решения фирмы IBM. Фирма IBM предлагает интеграционные решения в рамках семейства программных продуктов WebSphere. WebSphere относится к категории промежуточного программного обеспечения, которое позволяет приложениям электронного бизнеса (e-business) работать на разных платформах. WebSphere базируется на использовании открытых стандартов, таких как XML и Web-сервисы, которые реализуются средствами JEE. WebSphere разрабатывается в лабораториях IBM в течение многих лет. Эталонная СОА показана на рис. 12.9.  Рис. 12.9. Эталонная СОА Идея подхода, развиваемого в рамках WebSphere, состоит в том, что предлагается универсальная модель вызова компонентов и универсальное представление данных. Универсальной модели вызова реализована в виде архитектуры сервисных компонентов (Service Component Architecture, SCA), а основой универсального представления данных служат бизнес-объекты (Business Object). При использовании SCA все артефакты (процессы, бизнес-правила, задачи персонала (Human Tasks) и т. д.) описываются как компоненты сервисов с детально проработанными интерфейсами. Концепция SCA позволяет инкапсулировать бизнес-логику интеграционного решения внутри соответствующих модулей. При таком подходе изменение компонента сервиса внутри модуля не повлияет на остальные модули, входящие в состав интеграционного решения, поскольку интерфейс измененного модуля остается прежним. Все интеграционные артефакты представляются как компоненты SCA-сервисов, которые могут запускаться как в асинхронном, так и в синхронном режиме. Еще одним ключевым понятием данного подхода является понятие бизнес-объекта. Бизнес-объект - это расширение объекта типа Service Data Object (SDO). В отличие от объектов SDO, бизнес-объекты включают несколько расширений, используемых для более детального представления данных, которыми обмениваются сервисы архитектуры SCA. Принципиальным является то, что реализация как SCA, так и бизнес-объектов основана на существующих стандартах. Интерфейсы любого компонента сервиса SCA описываются в терминах WSDL, а бизнес-объекты описываются с использованием XML. Пакет продуктов IBM, входящий в состав WebSphere, для решения задач интеграции называется IBM WebSphere Business Integration и реализует такие функциональные возможности как: моделирование бизнес-процессов; А2А интеграцию приложений; В2В и В2С интеграцию; мониторинг бизнес-процессов; оптимизацию бизнес-процессов. В состав данного пакета входят следующие продукты: IBM WebSphere Process Server– сервер бизнес-процессов; IBM WebSphere ESB – интеграционная шина; IBM WebSphere Message Broker – вариант интеграционной шины, основанный на WebSphere MQ; Partner Gateway – шлюз для поддержки партнерских связей; IBM WebSphere Business Monitor – средство мониторинга бизнес-процессов (Business Activity Monitoring); IBM WebSphere Business Modeler – средство анализа и моделирования бизнес-процессов; IBM WebSphere Integration Developer – среда разработки интеграционных сервисов и составных сервис-ориентированных приложений.
Рис. 12.10. Архитектура Process Server WebSphere Process Server WebSphere Process Server реализован на базе WebSphere Application Server, имеет широкие функциональные возможности и позволяет решать практически любые интеграционные задачи и полностью соответствует принятой в IBM эталонной архитектуре интеграции (WebSphere Integration Reference Architecture). В Process Server все ключевые сервисы реализованы на основе собственного провайдера JMS, обеспечивающего полную совместимость с существующими решениями на базе WebSphere MQ, поддержку Web-сервисов и архитектуры Java 2 Connector Architecture. Архитектура Process Server приведена на рис. 12.10. Process Server работает поверх сервера приложений, в качестве которого выступает WebSphere Application Server и имеет три уровня: уровень ядра СОА, уровень обеспечивающих сервисов и уровень сервисных компонентов. Общая инфраструктура событий (Common Event Infrastructure, CEI) обеспечивает фиксацию событий, которые можно использовать для мониторинга приложений средствами Business Monitor или других продуктов IBM. К обеспечивающим сервисам относятся компоненты, необходимые для любого интеграционного решения. К этой группе сервисов относятся: сервисы отображения интерфейсов; сервисы отображения бизнес-объектов; сервис реализации отношений; селекторы. Сервисы отображения интерфейсов. Во многих случаях интерфейсы существующих компонентов имеют различный синтаксис, но семантически идентичны. Рассматриваемые сервисы позволяют вызывать такие компоненты путем трансляции соответствующих обращений. Сервисы отображения бизнес-объектов используются для преобразования бизнес-объекта из одного типа в другой. Сервис реализации отношений отношения. Сценарии бизнес-интеграции часто предполагают обращение к одним и тем же данным, используемым несколькими серверными системами, например, ERP и CRM. Типовая проблема при синхронизации бизнес-объектов состоит в том, что разные серверные системы используют разные ключи для представления одного и того же объекта. Сервис отношений служит для установления соответствия между идентичными объектами в разных серверных системах. Селекторы – это компоненты, поддерживающие механизм динамического выбора и вызов различных сервисов, использующих один и тот же интерфейс. На уровне сервисных компонентов Process Server поддерживает работу со следующими типами компонентов: бизнес-процессы; бизнес-правила; машины состояний; задачи персонала. Бизнес-процессы. Управление бизнес-процессами реализуется в соответствии со стандартом WS-BPEL, которые, можно создавать с помощью инструмента WebSphere Integration Developer или импортировать из бизнес-модели, созданной с помощью инструмента WebSphere Business Modeler. Бизнес-правила - это средство внедрения и отслеживания бизнес-политики посредством вывода бизнес-функции. Данный механизм обеспечивает динамическое внесение изменений в бизнес-процесс для повышения оперативности бизнес-среды. Для разработки бизнес-правил существует инструмент на базе платформы Eclipse. В состав WebSphere Process Server входит также работающий в реальном времени Web-инструмент бизнес-аналитики, по мере необходимости обновляющий бизнес-правила без нарушения работы других сервисов. Машины бизнес-состояний (Business State Machine) - один из способов моделирования бизнес-процесса. Этот способ позволяет организации описать свои бизнес-процессы с помощью состояний и событий, что в некоторых случаях оказывается проще, чем моделировать бизнес-процессы с помощью графов. Задачи персонала (HumanTasks) в решении WebSphere Process Server - это автономные компоненты, с помощью которых сотрудникам поручается определенная работа или вызываются какие-либо другие сервисы. Кроме того, инструмент Human Task Manager позволяет описывать специальные задания и отслеживать их выполнение. Для получения информации о персонале предназначены существующие каталоги LDAP. В состав WebSphere Process Server входит расширяемый Web-клиент, который может служить для работы с заданиями и процессами. Все функции WebSphere Process Server настраиваются и администрируются с помощью специальных расширений консоли администратора WebSphere Application Server и различных конфигурационных средств. WebSphere Process Server использует все возможности сервера приложений при управлении транзакциями, безопасностью, кластеризацией и рабочей нагрузкой, формируя среду бизнес-интеграции с высокой степенью масштабируемости и надежности. Он также обеспечивает полную поддержку транзакций ACID при реализации бизнес-процессов, как коротких (одна транзакция от начала до конца), так и длительных (множество транзакций). В состав продукта также входят инструменты восстановления - Recovery Manager и Recovery Console. Если в процессе выполнения какого-либо приложения происходит ошибка, Process Server позволяет администратору через консоль Recovery Console применить соответствующие процедуры к отказавшему приложению. Решение WebSphere Process Server дает множество возможностей для интеграции. Помимо импорта/экспорта собственных объектов (SCA-компонентов, Web-сервисов, JMS и Enterprise Java Session Beans), это решение обеспечивает первоклассную совместимость с существующими приложениями на базе WebSphere MQ. В состав Process Server входит также инструмент WebSphere Integration Developer. В состав WebSphere Integration Developer входит инструмент Assembly Editor, с помощью которого разработчик объединяет различные компоненты в модуль и указывает, при помощи каких сервисных интерфейсов этот модуль будет взаимодействовать с внешними потребителями. В качестве сервисов могут выступать импортируемые компоненты, например, Java Beans и Web-сервисы, а также компоненты сервисов, предоставляемые WebSphere Process Server. |
