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

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

WebSphere Business Integration предлагает способ создания решений бизнес-интеграции, который предполагает использование средств моделирования, позволяющих определить требования, предъявляемые к решению, а также инструментария для создания и связывания ориентированных на сервисы программных компонентов, эти требования удовлетворяющих.

Задачи и возможности бизнес-интеграции

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

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

Интеграция информации. Объединение операционных и аналитических данных с целью создания единого представления о бизнес-операциях и формирования основы для принятия решений.

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

Интеграция бизнес-партнеров. Выбор бизнес-партнеров с целью совместной работы и реализации бизнес-процессов.

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

В число возможностей бизнес-интеграции входят возможности объединять транзакционные системы, корпоративные информационные активы, бизнес-партнеров, а также управлять ими и поддерживать среду сотрудничества для лиц, принимающих решения, позволяющую решать конкретные бизнес-задачи. WebSphere Business Integration реализует эти возможности в интегрированной среде, которая состоит из инструментов, платформы и контента (рис. 2), позволяя максимально оперативно создавать интегрированные решения для электронного бизнеса в сервисно-ориентированной архитектуре (service-oriented architecture, SOA).

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

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

Платформа WebSphere Business Integration

Архитектура

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

На рис. 3 показан архитектурный шаблон WebSphere Business Integration, связывающий основные архитектурные элементы платформы при реализации решений бизнес-интеграции.

Модель программирования

Модель программирования WebSphere Business Integration служит для объединения инструментов, контента и элементов среды исполнения. При этом инструменты и среда исполнения соответствуют модели программирования, а контент выражен в терминах элементов модели программирования.

Модель программирования WebSphere Business Integration поддерживает формирование решений бизнес-интеграции из набора компонентов интеграции. Концепция компонента интеграции представляет собой общую абстракцию множества реализаций бизнес-функций. Реализовать компонент можно с помощью адаптера приложений или сценария организации процесса, написанного на языке Business Process Execution Language (BPEL). Разработчики формируют новое решение бизнес-интеграции из набора компонентов, а не за счет создания собственного кода. Модель программирования определяет набор видов компонентов, которые реализуют конкретные аспекты типичного решения бизнес-интеграции (например, посредник или адаптер) и предоставляют шаблоны — строительные блоки для создания таких решений. Эти виды компонентов, в свою очередь, реализуют один или несколько бизнес-сервисов или прикладных сервисов.

Компоненты и их сборка. Component Declaration Language [1] предлагает модель для представления и сборки прикладных компонентов, которые составляют приложение бизнес-интеграции. Компонент WebSphere Business Integration описывается с помощью декларации <компонент>, которая определяет <тип> компонента и содержит детали конкретной <реализации> этого типа, качества обслуживания и применимых к компоненту <правил>, а также указывает на другие компоненты, отвечающие за администрирование и мониторинг. <Тип> определяет сервисы, предоставляемые компонентом, а также сервисы, требуемые от других компонентов.

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

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

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

Виды компонентов и шаблоны интеграции. Модель программирования WebSphere Business Integration определяет набор видов компонентов, которые поддерживают общие шаблоны реализации для приложений бизнес-интеграции. Разработчики решений бизнес-интеграции выполняют декомпозицию общего решения в набор компонентов.

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

Один или несколько компонентов типа «адаптер» поддерживают взаимодействие с некоторым внешним прикладным компонентом. Таким компонентом может быть унаследованное приложение, доступ к которому осуществляется с помощью адаптера приложения, или предоставляемый партнером сервис, доступ к которому происходит через шлюз Web-сервис или через некий унаследованный B2B-протокол наподобие EDI или RosettaNet. Компоненты «адаптеры» могут передавать события, порожденные нижележащим приложением, в контекст бизнес-процесса или пересылать запросы, сгенерированные в бизнес-процессе, соответствующим внешним компонентам.

Компоненты Enterprise JavaBeans (EJB) могут реализовывать любую новую бизнес-логику в рамках модели программирования J2EE. «Адаптер» реализует взаимодействия с любым унаследованным активом, не поддерживающим J2EE (например, приложения PL/1 или CICS).

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

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

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

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

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

Среда исполнения

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

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

Интеграция партнеров. Поддерживает взаимодействие компании с ее партнерами — заказчиками и поставщиками. Работает с самыми разными видами транспорта (например, HTTP, MQSeries), протоколами обмена сообщения (SOAP, EDI и т.д.) и бизнес-протоколами (скажем, SWIFT, RosettaNet). Интеграция партнеров в решении бизнес-интеграции играет роль бизнес-шлюза и использует профиль бизнес-партнеров для определения наиболее подходящих каналов работы с учетом таких показателей, как бизнес-протокол, качество обслуживания, защита и т.д. Этот элемент реализуется с помощью WebSphere Business Integration Connect.

Организация процессов. Отвечает за выполнение бизнес-транзакций, определяемых процессами, и предоставляет возможности управления транзакциями, в том числе получение платы за взаимодействие с внешними ресурсами. Организация процессов, по существу, связывает вместе процессы, выполняющиеся в распределенной инфраструктуре (такие, как механизмы потоков работ и приложения, которые инкапсулируют процессы), для того, чтобы сформировать общее представление о бизнес-процессе. Элемент организации процессов реализуется с помощью WebSphere Business Integration Foundation.

Интеграция приложений. Создает потоки сообщений, необходимые для взаимодействия приложений и формирования «посреднической» среды для интеграции бизнес-процессов. Предусмотрен широкий набор различных моделей передачи сообщений («публикация-подписка», «запрос-ответ» и т.д.) и топологий («точка-точка», «звезда»). Интеграцию приложений реализуют совместно WebSphere Business Integration Foundation, Message Broker и адаптеры.

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

Управление показателями деятельности предприятия. Охватывает все уровни решения. Все компоненты генерируют события для всех компонентов решения (например, генерация события при получении от поставщика уведомления о выпуске комплектующих раньше срока: генерируется соответствующее событие, а затем эта информация используется для оценки гибкости поставщика). Данный элемент может динамически выражать необходимость поддержки конкретных типов событий, инициируемых компонентами в решении. Кроме того, он предоставляет механизм для хранения событий, корреляции событий с целью обнаружения бизнес-ситуаций, формирования инструментальных панелей с учетом ролей пользователей и инициации соответствующих событиям действий человека или автоматизированных операций. Элемент управления показателями деятельности предприятия реализуется компонентами моделирования и мониторинга WebSphere Business Integration.

Также среда исполнения включает несколько общих сервисов, таких, как сервисы каталогов и защиты. WebSphere Business Integration Foundation опирается на стандарты J2EE и Web-сервисов и средства поддержки качества обслуживания, предоставляемые WebSphere Application Server.

Создание решения

Подход WebSphere Business Integration к созданию решений для задач бизнес-интеграции строится на моделях. Существует три типа моделей, которые соответствуют этапам бизнес-интеграции: бизнес, ИТ и развертывание.

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

Ориентированная на сервисы модель программирования на этапе ИТ — это совокупность бизнес-компонентов и сервисов, сгенерированных в результате преобразования бизнес-модели. Программные элементы, которые реализуют эти компоненты и сервисы, объединяются в пакеты.

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

На всех трех этапах жизненного цикла решения с этими моделями пользуются несколькими инструментами, позволяющими вести групповую разработку с учетом специализации всех ее участников. «Студией решения» называют интегрированный набор таких инструментов, объединенный с помощью свободно распространяемой инструментальной оболочки Eclipse (www.eclipse.org). Данная оболочка включает в себя Eclipse Modeling Framework, реализацию стандартов Meta Object Facility, которые поддерживают интеграцию метамоделей на всех трех этапах. В свою очередь, интеграция метамоделей позволяет инструментальным средствам обмениваться элементами решения.

Этап бизнеса

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

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

Модель информации содержит все бизнес-элементы (например, письмо с запросом о ценах) и бизнес-события (подтверждение получения запроса), используемые в бизнес-операции. Эта модель поддерживает иерархию бизнес-информации произвольной вложенности. Бизнес-элементы могут быть сгруппированы по категориям (например, документы планирования), где одна категория может содержать другие категории (скажем, планирование производства) и множество типов информации (например, основной план производства). Кроме того, данная модель включает в себя бизнес-события, каждое из которых содержит спецификацию, составленную на тех же принципах, что и другие бизнес-элементы модели.

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

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

Модель сервисов описывает используемый бизнес-сервис (например, услуга предоставления цифровой абонентской линии, предлагаемая оператором, которая необходима для бизнес-операции «работа телефонной компании»), а также те сервисы, которые возникают при бизнес-операции (например, самообслуживание при размещении заказа). Модель сервисов также описывает провайдера и предоставляемую услугу.

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

Модель правил. Правила — элемент руководства по бизнес-операции [3]. Они состоят из четырех компонентов: когда применимо правило (предусловие); где оно применимо (границы); каков требуемый результат (измеримая цель); каковы последствия выполнения или нарушения правила (значимость для бизнеса). Правила широко применяются в различных аспектах бизнес-операций, в частности, для представления решения или условной логики в модели процесса (например, в заказах привилегированного клиента может быть пропущена операция проверки кредитоспособности) и ограничения на ресурсы в модели ресурсов (скажем, покупатель тех или иных продуктов должен иметь определенный минимальный опыт).

Модель наблюдений описывает мониторинг и управление бизнес-операциями. Она указывает корреляцию бизнес-событий, которые определяют бизнес-ситуации (например, появился заказ от привилегированного клиента, а на складе нет необходимого запаса товаров — эти два события, коррелируя, определяют бизнес-ситуацию «выполнение требований заказчика»). Более того, модель наблюдений позволяет установить необходимые действия, связанные с бизнес-ситуациями (уведомить менеджера по обслуживанию заказчиков) и используемые для мониторинга бизнес-операций основные показатели производительности (сроки выполнения заказов привилегированных клиентов).

Этап ИТ

Этап ИТ представляет решение бизнес-интеграции как совокупность компонентов и сервисов.

Архитекторы ИТ и разработчики решения получают модели этапа ИТ из моделей этапа бизнеса с помощью архитектурного анализа и конкретных архитектурных стилей. Преобразование моделей этапа бизнеса в модели этапа ИТ выполняется с помощью шаблонов электронного бизнеса, наилучших практических решений и практического опыта архитекторов ИТ и разработчиков решения. Модели этапа бизнеса отображаются на виды компонентов и шаблоны интеграции, описанные ранее. Эти виды компонентов реализуются с помощью BPEL, J2EE, и Web-сервисов.

Этап развертывания

Программные элементы из моделей этапа ИТ объединяются в пакеты, которые устанавливаются и распространяются на этапе развертывания. На рис. 5 показаны основные компоненты моделей развертывания [4].

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

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

Логическая цель шаблона развертывания может соответствовать одной или нескольким физическим целям инфраструктуры (скажем, организация процесса может быть реализована в серверах приложений A и E). Распределение модулей решения по физическим целям базируется на соответствии между логической и физической топологиями. Это соответствие является частью реестра решения.

Студия решения

Студия решения бизнес-интеграции — это набор инструментов, которые используются для определения моделей, описанных выше, а также для преобразования элементов модели между уровнями моделирования — от бизнес-моделей типа BPM (business process management — «управление бизнес-процессами») в модели ИТ в стиле UML, и далее — в модели элементов среды исполнения, которые функционируют на платформе J2EE.

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

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

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

Чтобы детализировать модель бизнес-операций, архитекторы ИТ могут преобразовать ее элементы из модуля моделирования WebSphere Business Integration в UML-модели Rational Rose. Модель UML включает в себя шаблоны для диаграммы задач (Use Case Diagram), описывающей высокоуровневое представление бизнес-целей и основных задач, выполняемых бизнес-процессом; диаграммы операций (Activity Diagram), представляющей процессы потоков работ; диаграммы классов (Class Diagram), представляющих информацию, которой манипулирует UML-инструментарий, с диаграммой состояния (State Diagram), описывающей состояние жизненного цикла этих информационных объектов и т.д. Архитекторы ИТ могут улучшать эти шаблоны, добавляя подробности относительно поведения процессов и совершенствуя информационную модель за счет детализации первоначальной, концептуальной модели, предложенной аналитиком.

Преобразование модели бизнес-операций в модель среды исполнения может выполняться либо непосредственно в модуле моделирования WebSphere Business Integration, либо с помощью модуля моделирования UML. В большинстве случаев эта модель будет отправной точкой для дальнейших улучшений с помощью работающих с программным обеспечением промежуточного уровня инструментов WebSphere Studio. Среди этих инструментов — набор редакторов, с помощью которых пользователи могут манипулировать элементами модели программирования, в том числе, графический редактор для моделей организации процессов BPEL. Кроме того, WebSphere Studio поддерживает отладку элементов решения в среде «песочниц» WebSphere [5]. Завершая процесс создания решения, инструменты разработки оформляют элементы решения в модуль решения.

Сценарий решения

Сценарий решения — это задача цепочки поставки, возникающая в системе электронной поставки [6]. Рассмотрим контекст решения и соответствующие модели бизнес-интеграции.

Контекст решения. Предположим, клиент обращается к поставщику электроники для того, чтобы изменить существующий заказ (скажем, увеличить количество товаров). Поставщик анализирует текущий план производства и выясняет, что он не может выполнить запрос клиента. После этого, он инициирует процедуру JIT-планирования (just-in-time — «точно в срок»), которая включает в себя оценку производственной мощности и обращение к поставщикам с просьбой о поставке материалов, необходимых для выполнения обновленного заказа. Если основной поставщик не может выполнить запрос, то, согласно установленным правилам, производитель будет приобретать материалы на рынке наличного товара.

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

Моделирование этапа бизнеса. Модуль моделирования WebSphere Business Integration моделирует бизнес-операции JIT-планирования (рис. 7). Это иллюстрация, а не реальное изображение из инструментария моделирования. Модель бизнес-операций указывает виды бизнес-действий (прямоугольник на рисунке), организационную роль участников этих действий (символ человека) и бизнес-документы (символ документов), которые передаются через систему. В частности, указывается, где документы создаются и асинхронно используются (круги).

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

Язык Component Declaration Language описывает бизнес-компоненты, составляющие шаблон решения. Решение JIT включает в себя три вида компонентов процесса: оценка производственных мощностей, запрос на комплектующие и завершение выполнения. На уровне этапа ИТ язык BPEL [7] описывает каждый из трех компонентов процессов. Кроме компонентов процессов этот шаблон решения также содержит бизнес-элементы, такие как отдел оформления запросов. Диаграмма состояний UML описывает работу отдела оформления запросов.

Моделирование этапа развертывания. Компоненты и программные элементы, которые составляют решение JIT объединяются в модули решения и затем связываются с логической топологией решения. Шаблон развертывания для сценария JIT создается на основе логической топологии, которая состоит из логической электронной площадки взаимодействия, B2B-шлюза, интегратора процессов, интегратора приложений предприятия и двух сред приложений (приложения планирования и осуществления планов).

С этими логическими целями связываются модули решения. Шаблон внедрения, показанный на рис. 8, состоит из пяти модулей решения. Один из них содержит все компоненты пользовательского взаимодействия; второй состоит из процесса, адаптивных объектов, посредников и бизнес-объектов; остальные модули включают в себя индивидуальное приложение и B2B-адаптеры.

Итоги

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

Совместное использование инструментами информации моделей на разных этапах возможно за счет интеграции метаданных в Eclipse. Среда исполнения WebSphere Business Integration опирается на стандарты J2EE и Web-сервисов. Шаблоны решения бизнес-интеграции предоставляют механизм, позволяющий быстро создавать и настраивать экземпляры решения из предварительно созданных компонентов и сервисов. Опираясь на интегрированную оболочку инструментальных средств, контента и среды исполнения, платформа WebSphere Business Integration обеспечивает предприятиям и системным интеграторам быстрый рост эффективности их работы.

Литература
  1. M.-T. Schmidt, WebSphere Business Integration Programming Model. IBM Software Group Technical Report, March 2003.
  2. E. Herness, R. High, J. McGee, «WebSphere Application Server: A Foundation for On Demand Computing». IBM Systems Journal, Vol. 43, No. 2, 2004.
  3. Organizing Business Plans: The Standard Model for Business Rule Motivation, Version 1.0. The Business Rules Group, November 2000.
  4. C. Draper et al., Solution Module Business Object Definition. IBM Autonomic Group Technical Report, May 2003.
  5. F. Budinsky, G. DeCandio, R. Earle, T. Francis, J. Jones, J. Li, M. Nally, C. Nelin, V. Popescu, S. Rich, A. Ryman, T. Wilson, «WebSphere Studio Overview». IBM Systems Journal, Vol. 43, No. 2, 2004.
  6. F. Wu et al., A Business Process Management Solution Storyboard. White Paper, IBM Research, 2003.
  7. M. Kloppmann, D. Konig, F. Leymann, G. Pfau, D. Roller, «Business Process Choreography in WebSphere — Combining the Power of BPEL and J2EE». IBM Systems Journal, Vol. 43, No. 2, 2004.

Кумар Бхаскаран — главный архитектор решений бизнес-интеграции IBM Software Group. Марк-Томас Шмидт — главный архитектор проекта IBM WebSphere Business Integrator.

K. Bhaskaran, M.-T. Schmidt, WebSphere Business Integration: An architectural overview. IBM Systems Journal, Vol. 43, No. 2, 2004. Copyright 2004, International Business Machines Corporation. All rights reserved. Reprinted with permission.