Сценарии и решения использования шины Enterprise Service Bus в сервис-ориентированной архитектуре. Часть 3

Решения для сценариев использования ESB

В части 3 данной серии статей, посвященной сценариям использования и решениям, реализующим сервисную шину предприятия (Enterprise Service Bus), автор рассматривает возможные решения для различных сценариев, перечисленных в части 2. В основу приведенных сценариев легли принципы применения шины ESB, изложенные в части 1.

Рик Робинсон, архитектор информационных систем, IBM

Рик Робинсон (Rick Robinson) начал работу в IBM в марте 1997 года в должности разработчика; в настоящее время он является архитектором информационных систем. Он работает в группе Architecture Services подразделения WebSphere Lab Services для региона EMEA (Европа, Ближний Восток, Африка) и с момента выхода платформы ПО WebSphere, в 1999 году, занимается, по большей части, продуктами этой платформы. Рик больше интересуется технологиями, чем производством, тем не менее, более трех лет он работал с компаниями в финансовом секторе. Рик является признанным членом коллектива архитекторов информационных систем IBM. До работы в IBM Рик Робинсон закончил обучение со степенью доктора философии в области физики.



18.01.2008

В продолжение нашей серии о разработке архитектуры Enterprise Service Bus (ESB) для сервис-ориентированной архитектуры (Service-Oriented Architecture, SOA) мы рассмотрим различные очевидные шаблоны решений для сценариев, описанных в части 2 (см. раздел Ресурсы).

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

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

В этом разделе описываются следующие шаблоны решений:

  • Базовый адаптер;
  • Абонентский шлюз;
  • Совместимый с Web-сервисами брокер сообщений;
  • Инфраструктура интеграции прикладных систем предприятия (Enterprise Application Integration, EAI) для сервис-ориентированной архитектуры (Service-Oriented Architecture, SOA) (Инфраструктура EAI для SOA);
  • Компонент хореографии сервисов (Service Choreographer);
  • Полнофункциональная инфраструктура сервис-ориентированной архитектуры (Полнофункциональная инфраструктура SOA).

Шаблон решения "Базовый адаптер"

Этот вариант решения представляет собой простую интеграцию сервиса типа "от точки к точке" с использованием технологии оболочки (wrapper) или адаптера, а не ESB в полном смысле этого понятия. При помощи данной технологии можно осуществить интеграцию через определенный на языке WSDL доступ по протоколу SOAP или через другие функционально совместимые технологии, например IBM WebSphere® MQ (MQ). Если технологии не предоставляют собственной модели для определения интерфейса сервиса, например WSDL, то для того, чтобы выполнялись принципы SOA, необходимо создать пользовательскую модель.

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

При помощи инструментов разработки или технологии рабочего цикла можно использовать или создать широкий диапазон адаптеров. Можно также обеспечить поддержку стандартов Web-сервисов и связующего ПО интеграции прикладных систем предприятия ( Enterprise Application Integration, EAI). Такая поддержка, кроме того, может быть предоставлена для различных систем, в том числе, для современных распределенных серверов приложений (серверов Java 2 Enterprise Edition (J2EE), таких как WebSphere или .NET), унаследованных приложений (таких как CICS®) и готовых коммерческих программных пакетов (таких как SAP или Siebel).

Рисунок 1 иллюстрирует общее решение "Базовый адаптер", включая использование существующей инфраструктуры HTTP и связующего ПО EAI для поддержки новых интеграций. Хотя на рисунке изображена схема сценария для внутренней интеграции, этот же сценарий может быть использован и для сценариев внешней интеграции, при условии, что в качестве протокола связи используется HTTP, или доступна некоторая форма интернет-совместимой EAI-технологии, например MQ internet pass-thru

Рисунок 1. Схема шаблона решения "Базовый адаптер", показывающая, как существующие инфраструктуры HTTP и немодифицированной EAI осуществляют поддержку некоторых аспектов функции сервисной шины
Шаблон решения "Базовый адаптер"

Варианты технологии реализации для шаблона "Базовый адаптер"

Ниже перечислены доступные варианты реализации шаблона "Базовый адаптер":

  • Использование функций SOAP или EAI, предоставляемых непосредственно унаследованными системами или приложениями. Например, программный пакет IBM CICS теперь предлагает непосредственную поддержку SOAP, а многие системы и пакеты приложений способны поддерживать интерфейсы MQ или SOAP;
  • Если приложения, к которым необходимо обеспечить доступ, являются пользовательскими приложениями, которые выполняются в среде сервера приложений, то для добавления к приложению оболочки можно использовать инструментарий для разработки приложений либо инструментарий для разработки рабочей среды. Например, чтобы добавить поддержку XML, SOAP или MQ к приложениям J2EE, размещенным на платформе сервера приложений WebSphere Application Server, можно воспользоваться пакетом WebSphere Studio Application Developer;
  • В случае, если такая поддержка недоступна или не подходит для конкретного сценария (например, если XML-преобразование не обеспечивает корректного использования ресурсов процессора на имеющейся платформе), может потребоваться создание дополнительного архитектурного уровня, показанного на рисунке 2. Это может быть уровень сервера приложений, на котором размещены адаптеры, интегрированные с приложениями или унаследованными системами. Например, программный пакет Application Developer Integration Edition предоставляет инструментарий архитектуры коннектора Java 2 Connector Architecture (JCA) для доступа к унаследованным системам, таким как CICS, а также интерфейсы J2EE и Web-сервисы для них через среду исполнения WebSphere;
    Рисунок 2. Дополнительный архитектурный уровень для выполнения обработки преобразования XML
    Дополнительный архитектурный уровень для обработки XML-преобразования к шаблону решения "Базовый адаптер"
  • Если для создания оболочки использовался инструментарий разработки, то можно расширить предоставляемый им набор функций: посредством создания инфраструктуры или набора вспомогательных классов для выполнения общих задач, таких как обеспечение безопасности, ведение журналов и т. п. Однако этот подход может привести к деформации области применения, в результате чего может быть создана инфраструктура, на самом деле представляющая собой абонентский шлюз или овместимый с Web-сервисами брокер сообщений. При определении функций разрабатываемой инфраструктуры необходимо убедиться в том, что получаемые преимущества соответствуют затратам на разработку и обслуживание, а выбранный шаблон представляет собой наиболее адекватное решение и нет необходимости в использовании более сложного шаблона.

Дополнительную информацию и подробные рекомендации по реализации этого шаблона можно найти в разделе Ресурсы.

Результаты реализации шаблона "Базовый адаптер"

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

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

Альтернативные шаблоны

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


Шаблон решения "Абонентский шлюз"

Этот шаблон представляет собой базовую реализацию ESB, близкую к "Реализации ESB с минимальным набором функций", описанной в части 1. Абонентский шлюз часто поддерживает подключение к клиенту через SOAP/HTTP, MQ, Java Message Service (JMS) и т. п., но может также поддерживать расширенную интеграцию с поставщиком сервиса, например через JCA или WebSphere Business Integration Adaptors. Компонент-шлюз функционирует как центральная точка управления маршрутизацией сервисов, преобразованием протоколов и функциями обеспечения безопасности.

Шлюз может использоваться для того, чтобы предоставить клиентам постоянное пространство имен сервиса (например, в форме URL для сервисов SOAP.РЕЕЗ) и модель авторизации для сервисов, которые фактически предоставляются разнородными системами через несколько разных протоколов. Обычно такие требования предъявляются в том случае, если необходимо предоставить сервис внешним партнерам, например клиентам или поставщикам, но он может также оказаться полезным внутри одного предприятия, если желательно упростить доступ из приложений к функциям, реализованным в различных системах и технологиях.

Ключевой функцией шлюза является возможность преобразования протоколов сервисов, поддерживаемых клиентами, в протоколы сервисов, поддерживаемые поставщиками. Это могут быть такие протоколы, как SOAP/HTTP, MQ или SOAP/JMS, JCA, RMI/IIOP и т. д. Необходимо провести оценку функций предполагаемых технологий реализации с точки зрения необходимых клиентам и поставщикам протоколов.

На рисунке 3 изображена схема шаблона решения "Абонентский шлюз"

Рисунок 3. Реализация ESB при помощи шаблона "Абонентский шлюз"
Шаблон решения "Абонентский шлюз"

Варианты технологии реализации для шаблона "Абонентский шлюз"

Шаблон решения "Абонентский шлюз" может быть реализован следующими способами:

  • Использование технологии пакета шлюза, например Web Services Gateway, который поставляется с программами Application Server Network Deployment или WebSphere Business Integration Connection. Многие технологии шлюзов поддерживают определенный тип связующего фильтра или модели программирования обработчиков, чтобы предоставить пользователям возможность улучшения функций. Пакет Web Services Gateway предоставляет некоторые настраиваемые связующие функции. Он также поддерживает использование обработчиков запросов и ответов Web-сервисов согласно определению спецификации Java API для удаленного вызова процедур (Remote Procedure Call) на базе XML (JAX-RPC);
  • Использование функций разработки и исполнения приложений современной технологии серверов приложений для реализации пользовательских шлюзов. Для этого может оказаться необходимым использовать тот же вид адаптеров, который описан для шаблона решения базовый адаптер.
  • Если нужны более сложные функции, стоит подумать об использовании более сложного связующего ПО EAI, например WebSphere Business Integration Message Broker;
  • Существует ряд реализаций описанных технологий, обычно без использования технологий Web-сервисов. Например, многие реализации разработали транзакции маршрутизации, предлагающие простой интерфейс, который использует модель данных в виде текста для нескольких унаследованных транзакций. Такие системы эффективно реализуют шаблон шлюза при помощи пользовательского формата данных и некоторых преимуществ в отношении переносимости, которые обеспечиваются XML.

Результаты реализации шаблона "Абонентский шлюз"

Положительные: для данного решения требуется минимум инфраструктуры, хотя некоторые технологии шлюзов должны быть развернуты с соответствующей эластичностью. Акцент на функционально совместимых протоколах и открытых стандартах также упрощает учет различных аспектов инфраструктуры. Способность большинства шлюзовых технологий взаимодействовать с рядом других типов интерфейсов, таких как RMI/IIOP и JCA, должна минимизировать затраты на развертывание дополнительной технологии организации подключений.

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

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

Альтернативные шаблоны для сценария "Абонентский шлюз"

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


Шаблон решения "Совместимый с Web-сервисами брокер сообщений"

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

Рисунок 4. Реализация полнофункциональной шины ESB при помощи совместимого с Web-сервисами брокера сообщений
Шаблон решения "Совместимый с Web-сервисами брокер сообщений"

Варианты технологии реализации для шаблона "Совместимый с Web-сервисами брокер сообщений"

Для шаблона "Совместимый с Web-сервисами брокер сообщений" доступны следующие варианты реализации:

  • Чаще всего технологией реализации для этого решения является связующее ПО EAI, например WebSphere Business Integration Server, обеспечивающее соответствующую поддержку Web-сервисов;
  • По желанию, в случаях, когда поддержка Web-сервисов необходима, главным образом, для интеграции с внешними системами, фирменные функции связующего ПО EAI могут быть использованы во внутреннем сегменте в сочетании с компонентом Абонентский шлюз, добавляющим поддержку Web-сервисов.

Дополнительную информацию и подробные рекомендации по реализации этого шаблона можно найти в разделе Ресурсы.

Результаты применения шаблона "Совместимый с Web-сервисами брокер сообщений"

Преимуществами этой реализации является обеспечение полноценной функциональности в рамках модели открытых стандартов. Однако, хотя связующее ПО EAI представляет собой зрелую технологию, поддержка им открытых стандартов, особенно более современных и передовых стандартов Web-сервисов, таких как WS-Policy и WS-Transaction, может все еще не достигать нужного уровня зрелости. Следовательно, главный недостаток этого сценария заключается в том, что оно просто может оказаться нежизнеспособным в некоторых ситуациях.

Альтернативные шаблоны для сценария "Совместимый с Web-сервисами брокер сообщений"

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


Инфраструктура EAI для SOA

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

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

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

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

  • Многие EAI-технологии настолько распространены, особенно в отдельных организациях, что обеспечивают тот же уровень функциональной совместимости, что и открытые стандарты;
  • Там, где это подходит, можно использовать XML-данные и форматы сообщений, которые способствуют обеспечению функциональной совместимости и независимости от платформы - так же, как XML способствует использованию этих преимуществ в стандартах Web-сервисов;
  • Вполне вероятно, что технология EAI будет поддерживать какие-либо формы Web-сервисов, поэтому в подходящих случаях могут быть предоставлены интерфейсы, построенные на открытых стандартах, особенно использующие документ/литеральную модель SOAP для представления всех используемых XML-форматов. Альтернативно, аналогичный доступ может быть предоставлен путем добавления к решению абонентского шлюза;
  • В некоторых случаях можно использовать Java в качестве платформенно-независимого языка программирования для создания пакета клиентского API, к которому можно обращаться не только из сред J2EE, но также из автономных сред Java, сред баз данных с поддержкой Java и многих других;
  • Связующее ПО EAI может поддерживать другие открытые стандарты, такие как Java Messaging Service (сервис обмена сообщениями Java). Хотя, может быть, этот стандарт не так широко применяется, как Web-сервисы, тем не менее, он поддерживается несколькими технологиями.

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

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

На рисунке 5 изображены компоненты, используемые в шаблоне решения

Рисунок 5. Реализация полнофункциональной сервисной шины при помощи связующего ПО EAI
Шаблон решения связующего ПО EAI

Варианты технологии реализации для шаблона "Связующее ПО EAI"

Выбор шаблона "Связующее ПО EAI" будет определяться путем сопоставления функций ESB, необходимых в конкретной ситуации, с функциями различных продуктов EAI, например, продуктов семейства WebSphere Business Integration.

Ключевой областью проектной деятельности является модель определения интерфейса сервиса. Для того чтобы сервисы соответствовали принципам SOA, они должны быть определены с использованием некоторого явно заданного интерфейса. Хотя некоторые технологии EAI могут предложить такую модель, в остальных случаях требуется пользовательское решение. На практике оно часто реализуется при помощи XML-схемы, объединяющей идентификацию, адресацию сервиса и бизнес-данные. Однако возможны и решения без использования XML, например текстовые решения, используемые некоторыми унаследованными реализациями шаблона "Абонентский шлюз".

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

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

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

Результаты применения шаблона "Связующее ПО EAI"

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

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

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

Альтернативные шаблоны для связующего ПО EAI

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


Шаблон решения "Хореография сервисов"

Этот шаблон состоит из реализации специального компонента хореографии сервисов. Такой компонент на самом деле не является ESB, но поддерживает возможность подключения к сервисам через различные протоколы, такие как SOAP/HTTP или MQ, которые либо требуют, либо подразумевают наличие ESB. В некоторых сценариях такая поддержка может быть достаточной для того, чтобы обеспечить прямое подключение к поставщикам сервисов и запросчикам серверов. Если это не так, то ESB может быть предоставлена через любой из других шаблонов решений, описанных в этой статье. Это будет соответствовать шаблону решения "Полнофункциональная инфраструктура SOA".

На рисунке 6 изображена схема реализации компонента хореографии сервисов Service Choreographer.

Рисунок 6. Реализация компонента Service Choreographer
Шаблон решения "Хореография сервисов"

Варианты технологии реализации для шаблона "Хореография сервисов"

Для этого шаблона решения важнее всего понять, в какой степени вам необходима поддержка открытых стандартов. Возможны три сценария:

  • Полное утверждение стандартов Web-сервисов для интерфейсов сервисов и моделирования процессов;
  • Утверждение стандартов Web-сервисов для интерфейсов сервисов в сочетании с использованием фирменной технологии моделирования процессов;
  • Применение фирменных интерфейсов и фирменной технологии моделирования процессов.

Эти вопросы особенно значимы для данного шаблона решения, поскольку стандарты Web-сервисов, имеющие отношение к моделированию процессов (в основном, язык исполнения бизнес-процессов для Web-сервисов, Business Process Execution Language for Web Services) относятся к самым новым, и, следовательно, поддержка их программными продуктами отличается меньшей зрелостью. Большинство производителей технологии хореографии сервисов Service Choreographer предлагают комбинированные решения, состоящие из фирменных технологий и технологий на основе открытых стандартов. Ниже перечислены примеры технологий:

  • Технология WebSphere Enterprise Process Choreographer, предоставляющая поддержку интерфейсов Web-сервисов и определений процессов;
  • MQ Workflow предоставляет поддержку для более зрелой, но и в большей степени фирменной технологии хореографии сервисов, имеющей интерфейсы либо фирменные, либо на основе Web-сервисов.

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

Результаты реализации шаблона "Хореография сервисов"

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


Шаблон решения "Полнофункциональная инфраструктура SOA"

Этот шаблон представляет собой комбинацию компонента Хореография сервисов и реализации сервисной шины ESB. Поскольку оба аспекта подробно описаны в других разделах этой статьи, мы больше не будем говорить о них, скажем только, что очевидно возможен целый спектр реализаций. На одном конце спектра находятся полностью фирменные решения, использующие шаблон Инфраструктура EAI для SOA для ESB и фирменная технология хореографии сервисов. На противоположном конце спектра - решения, полностью построенные на открытых стандартах и использующие шаблон ESB "Совместимый с Web-сервисами брокер сообщений" и технологию хореографии сервисов, совместимую с открытыми стандартами.


План внедрения SOA и ESB

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

Идентификация непосредственного поля деятельности

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

В первую очередь следует решить, что выбрать - технологию ESB или принципы SOA для функциональной архитектуры. Этот вопрос обуславливает два подхода:

  • Полнофункциональная инфраструктура, пилотная функциональность -- в данном случае основной задачей будет проверка функциональности технологии. Эта инфраструктура, скорее всего, включает сложные функции ESB (фирменные или построенные на основе открытых стандартов) и, возможно, использует шаблон решения "Полнофункциональная инфраструктура SOA". Однако столь техническое решение подразумевает высокую степень риска и может включать относительно незрелые технологии. Таким образом, реализация этого решения не будет привязана к критически важным для бизнеса проектам или функциям. Функции, предоставляемые в виде сервисов, могут обладать низкой критичностью или доставляться, в основном через альтернативные каналы. По мере испытания и развития функциональности инфраструктуры сервисы с течением времени подлежат миграции;
  • Базовая инфраструктура, Полная функциональность -- здесь главной задачей является предоставление бизнес-функций в виде сервисов, чтобы к ним можно было обращаться или сочетать их по-новому для создания бизнес-ценности. В этом случае предполагаемая выгода для бизнеса или другие факторы, обуславливающие изменения, обычно являются достаточно существенными, чтобы требовать более низкого уровня технических рисков. Следовательно, данная инфраструктура реализуется либо с применением только самых основных и зрелых стандартов Web-сервисов, либо с использованием более установившихся технологий EAI. После того, как инфраструктура будет создана, а поддержка взаимодействий сервисов налажена, ее функции могут быть модернизированы или подвергнуты миграции с течением времени и развитием технологий ESB.

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

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

В подходе к реализации SOA существует еще два аспекта, которые следует определить на ранних стадиях: предоставление внутреннего или внешнего доступа к сервисам и подход к гранулярности сервисов.

Решение о поддержке внутреннего или внешнего доступа ставит ряд вопросов, а именно: какой уровень сервиса требуется (см. раздел Проблемы обеспечения безопасности, оказывающие влияние на ESB) и нужно ли для управления внешним доступом реализовать компонент абонентский шлюз. Кроме того, внешний доступ может также потребовать использования стандартов Web-сервисов, тогда как внутренний доступ допускает большую гибкость, например можно выбрать MQ, RMI/IIOP или фирменную реализацию XML, о которых рассказывалось в разделе о шаблоне решения "Инфраструктура EAI для SOA".

Проблема детализации сервисов широко обсуждалась в отрасли (см. раздел Ресурсы). Сложная архитектура SOA, скорее всего, содержит различные уровни детализации сервиса, от технических операционных функций, таких как ведение журнала, биллинг и т. п., до бизнес-функций, например запрос остатка на счете и бизнес-процессов, например process stock order.

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

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

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

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

Вехи SOA

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

  • Модель обеспечения безопасности, построенная на основе стандартов -- хотя для кратковременных сроков может оказаться достаточно упрощенных или фирменных моделей, для сложной архитектуры SOA необходима полнофункциональная и построенная на открытых стандартах модель обеспечения безопасности. Выявление момента, в который поддержка стандартов обеспечения безопасности Web-сервисов программным продуктом будет соответствовать требованиям организации, должно стать главным компонентом всего плана реализации;
  • Активизация унаследованных систем и приложений сервиса -- так же, как развитие современных серверов приложений (например, серверов J2EE, скажем, Application Server) приводит организации к использованию SQL и созданию JDBC или ODBC-интерфейсов для своих баз данных, развитие SOA вынуждает организации организовать доступ к унаследованным транзакциям и функциям приложений через сервисы. Поэтому организации должны планировать определение и реализацию использования сервисов в наиболее подходящей форме для каждой системы. Доступные возможности - использование встроенной поддержки XML или Web-сервисов, применение адаптеров, например JCA, или использование технологий EAI или шлюза для обеспечения возможности подключений к унаследованным системам;
  • Реализация инфраструктуры с высоким уровнем сервиса -- до сих пор большая часть зрелой поддержки Web-сервисов существует для ненадежных протоколов связи, SOAP/HTTP; стандарты, предлагающие более высокое качество сервисов, например WS-ReliableMessaging или WS-Transaction, до сих пор не получили широкой поддержки. Чтобы обеспечить более высокое качество сервисов для SOA, в настоящее время необходимо использовать технологию EAI. В плане долговременного планирования организации должны сохранять на должном уровне поддержку развивающихся стандартов и конвергенцию технологий EAI со стандартами Web-сервисов;
  • Идентифицированные уровни детализации сервисов -- как уже упоминалось в разделе "Идентификация непосредственного поля деятельности", критически важно идентифицировать уровни детализации в отношении SOA, и требования к агрегации и хореографии между ними. Реализация каждого уровня детализации (технические функции, бизнес-функции, бизнес-процессы и т. д.) и ассоциированная хореография должны также формировать ключевую веху.

Шаги к реализации SOA

Изучив два предыдущих раздела, вы готовы составить генеральный план реализации SOA и ESB:

  1. Решите, какие элементы технологии SOA или функции SOA являются приоритетными для реализации (см. раздел Идентификация непосредственного поля деятельности);
  2. Идентифицируйте или определите подходящий проект для реализации первого решения - технический пробный проект, пробный бизнес-проект или, может быть, реальный бизнес-проект с приемлемым профилем рисков;
  3. Определите, какой из сценариев ESB в SOA можно применить к вашему проекту. Выполните дополнительный анализ требований, относящихся к разделам Аспекты, обуславливающие принятие проектных и архитектурных решений ESB и Модель производительности ESB. Исходя из результатов этого анализа, выберите один из шаблонов решения. Исходя из результатов дальнейшего анализа и требований обеспечения безопасности, а также нефункциональных требований (см. раздел Проблемы безопасности, влияющие на ESB), выберите подходящую технологию реализации;
  4. Параллельно с этой работой начните составлять план развития этой первой реализации в полнофункциональную сложную архитектуру SOA. В зависимости от основной направленности первоначального пробного проекта, этот план может включать различные аспекты развития технической функциональности инфраструктуры или создания дополнительных функциональных сервисов для того, чтобы использовать их преимущества. В любом случае план должен включать определенные выше вехи SOA.

Помимо этого первоначального проекта, запланируйте развитие по нескольким направлениям:

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

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

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=SOA и web-сервисы
ArticleID=282292
ArticleTitle=Сценарии и решения использования шины Enterprise Service Bus в сервис-ориентированной архитектуре. Часть 3
publish-date=01182008