Корпоративная сервисная шина в банковском сервисе. Внедрение интеграционной шины. корпоративная сервисная шина

Интеграция информационных систем при помощи корпоративной сервисной шины (ESB)

Среди лучших практик интеграции сложных информационных систем — построение логических витрин данных, а также создание централизованных инфраструктур обмена данными при помощи MDM-систем и корпоративных сервисных шин (ESB, Enterprise Service Bus). Наши решения, в том числе система АрхиГраф.MDM, пригодны для использования в составе операционной системы специального назначения Astra Linux Special Edition, а также Alt Linux.

Зачем нужна интеграционная шина?

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

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

Внедрение интеграционной шины

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

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

Проекты по интеграции мы выполняем совместно с партнерами на основе решений IBM WebSphere MQ, Integration Service Bus, WSO2 Message Broker, Apache Synapse, а также шины «Бизнес Семантика».

Часто проект по внедрению интеграционной шины выполняется в рамках общего реинжиниринга информационной архитектуры предприятия.

2005 г.

Корпоративная сервисная шина — «бюджетный» подход к решению задач интеграции

Подготовлено: по материалам зарубежных сайтов
Перевод: Intersoft Lab

Продолжая знакомить читателя с различными подходами к интеграции, мы решили остановиться на относительно новой и весьма привлекательной технологии — корпоративной сервисной шине (Enterprise Service Bus, сокр. ESB).

Что же такое корпоративная сервисная шина и как она соотносится с рассмотренной в предыдущих номерах Журнала Клуба знатоков DWH, OLAP и XML интеграцией корпоративных приложений (EAI)? По сложившейся традиции сначала предоставим слово экспертам в данной области.

Аналитики Gartner определяют ESB как новый тип программного обеспечения промежуточного уровня (middleware), который объединяет функциональные возможности других уже существующих типов промежуточного обеспечения. Корпоративная сервисная шина поддерживает Web-сервисы, реализуя протокол SOAP (Simple Object Access Protocol, Простой протокол доступа к объектам) и используя язык WSDL (Web Services Description Language, Язык описания Web-сервисов) и спецификацию UDDI (Universal Description, Discovery and Integration, Универсальное описание, обнаружение и интеграция). Многие корпоративные сервисные шины также поддерживают другие стили обмена информацией, включая гарантированную доставку и «публикацию и подписку» (publish and subscribe). Сервисы, предоставляемые этими шинами, обладают «добавленной стоимостью», которой не располагают межплатформенное обеспечение, предназначенное для упрощенного обмена сообщениями, — они обеспечивают проверку сообщений, трансформацию, маршрутизацию на основе содержания, безопасность, обнаружение сервисов для сервис-ориентированной архитектуры, балансирование нагрузки и регистрацию. Некоторые сервисы встроены в основание шины, другие — исполняются в модулях расширения (plug-in). Кроме того, шины поддерживают язык XML и другие форматы сообщений.

Чем же так привлекательна корпоративная сервисная шина? Прежде всего, своей относительной дешевизной. Продукты ESB, как правило позиционируются как доступные по цене, или, как говорят, «бюджетные», решения.

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

Говоря о достоинствах корпоративной сервисной шины, стоит привести слова вице-президента и члена исследовательского отдела компании Gartner Ройя Шульте (Roy Schulte): «Обычное программное обеспечение промежуточного уровня уже не может поддерживать новые приложения, которые используют сервис-ориентированную (Service Oriented Architecture, сокр. SOA) и управляемую событиями архитектуры (Event Driven Architecture, сокр. EDA), Web-сервисы и управление бизнес-процессами. Это и является основной причиной, почему архитекторы и менеджеры информационных систем должны усилить свои корпоративные информационные инфраструктуры с помощью ESB».

Ведущий аналитик Gartner выделяет группы поставщиков ESB. К первой группе он относит продукты ESB, которые позиционируются как «бюджетные» интеграционные решения, оптимально подходящие для поддержки композитных приложений и SOA. Вторая группа — это продукты, предназначенные для рынка Web-сервисов, наконец последние — это программные средства, обеспечивающие поддержку EDA. По оценке Ройя Шульте, на протяжении следующих лет произойдет уплотнение рынка ESB, что объясняется усиливающимся спросом на Web-сервисы и многопротокольные и управляемые событиями решения.

Интересно, что в ряде компаний ESB трактуют не как категорию продуктов, а как архитектуру. Например, в IBM корпоративную сервисную шину считают «архитектурной моделью» (architectural pattern).

Таким образом, можно констатировать, что до сих отсутствует четкое определение, что такое же ESB. Фактически, дискуссия разворачивается вокруг двух вопросов:

1. Является ли ESB архитектурой (причем такой, которую не нужно даже стандартизировать), «односторонним подходом» или же самостоятельным продуктом.

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

2. Каковы место и перспективы продуктов ESB, а именно, является ли корпоративная сервисная шина более совершенной системой организации очередей сообщений, обеспечивающей простое преобразование XML, а также маршрутизацию и обмен сообщениями, или же использование адаптеров приложений, автоматизации и моделирования бизнес-процессов позволит ESB успешно заменить EAI.

На данный момент на обозначенные вопросы нет окончательных ответов.

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

Заметим, что слово «сервисная» в термине «корпоративная сервисная шина» является центральным. Так, аналитики Forrester Research рассматривают ESB как «слой промежуточного программного обеспечения, с помощью которого можно получить доступ к набору основных (многократно используемым) бизнес-сервисам». SOA позволяет представить большую часть функциональности как «сервис» в корпоративной сервисной шине, которая переправляет, преобразовывает и проверяет входные и выходные данные в формате XML, получаемые из этих сервисов.

ESB и XML

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

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

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

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

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

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

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

В чем отличие сервисной шины предприятия(ESB) от брокеров сообщений (например RabbitMQ)?

В результате, можно разрешить проблему неудовлетворительной производительности.

Заключение

Судя по публикациям в зарубежных Интернет-изданиях и оценкам аналитиков ведущих исследовательских компаний, корпоративная сервисная шина уже больше не является просто новой технологией с большим потенциалом. Действительно, по прогнозу Gartner, в 2005 году большинство крупных компаний будут использовать ESB. В IDC же полагают, что корпоративная сервисная шина должна «революционизировать» информационные технологии и сделать возможным гибкую и масштабируемую распределенную обработку данных.

Действительно, поддержка открытых стандартов (и особенно XML) позволяет получить недорогое, но эффективное решение и гарантирует быструю окупаемость инвестиций, т.е высокий показатель ROI. Как отмечает вице-президент Консорциума по интеграции Стив Крэггс (Steve Craggs), «ESB является базисом для интеграции, обеспечивает гибкую и настраиваемую среду, которая позволяет плодотворно, успешно и планомерно реализовывать интеграционные проекты».

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

Публикации

1. Бесс Голд-Бернштейн (Beth Gold-Bernstein) «Нужна ли вам корпоративная сервисная шина» (Is an ESB Critical To Your Future?).
2. Найджел Томас (Nigel Thomas) и Уоррен Бакли (Warren Buckley) «Появление корпоративной сервисной шины» (Rise of the ESB).
3. Материалы, опубликованные на сайте Консорциума по интеграции (Integration Consortium).

Что такое ESB и SOA¶

An excellent description of system-of-systems thinking
Nick Coghlan, Core Python Developer

Also available in Català , Deutsch , English , Français , italiano , Nederlands , Português , Türkçe and 中文 .

Аббревиатура ESB и связанная с ней SOA — могут стать причиной путаницы. ESB расшифровывается как Enterprise Service Bus. SOA — Service Oriented Architecture.

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

Вся правда¶

Давайте представим, что происходит, когда Вы входите в фронтенд-приложение Вашего банка:

1. Показывается Ваше имя
2. Отображается баланс Вашего счета
3. Показываются Ваши кредитные и дебетовые карты
4. Там может быть список Ваших паевых инвестиционных фондов
5. Вы также получаете список предварительно рассчитанных ссуд, в которых Вы можете быть заинтересованы

С большой долей вероятности можно сказать, что все эти кусочки информации принадлежат к разным системам и приложениям, каждое из которых предоставляет данные через какой-то интерфейс (HTTP, JSON, AMQP, XML, SOAP, FTP, CSV или любой другой):

1. из CRM, работающей под управлением Linux и Oracle
2. из COBOL системы, работающей на z/OS мейнфрейме
3. говорят, эта информация поступила из системы на мейнфрейме, но эти ребята слишком молчаливы, чтобы сказать что-то кроме того, что они предпочитают CSV всему остальному
4. из смеси PHP и Ruby, работающих на Windows
5. из PostgreSQL, Python и Java, работающих на Linux и Solaris

Вопрос состоит в том, как Вы можете заставить фронтенд-приложение общаться с системами 1-5? Ну, никак.

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

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

Заметьте, мы даже не показали ни одного высокоуровневого процесса (App1 вызывает App2 и либо App3, либо App5, в зависимости от того, был ли предыдущий ответ от App6 успешным, для того, чтобы App4 могло позже взять данные, которые были сгенерированы App2, но только если App1 не запрещает этого и т. д.).

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

Тем не менее, некоторые вопросы становятся очевидными.

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

Если Вы думаете, что можете управлять 6-ю приложениями, как на счет 30?

А сможете справиться с 400? А с 2000? Каждое приложение может быть своей уникальной экосистемой, требующей десятка серверов или других устройств для работы, так что это — 20 000 движущихся частей, распределенных по континентам с всяческими техническими и культурными границами. И все эти части постоянно и без остановки хотят обмениваться сообщениями все время без каких бы то ни было простоев, вообще. (Мы избавим Вас от схемы.)

Есть отличное название для такой ситуации — беспорядок.

Как Вы можете исправить ситуацию?¶

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

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

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

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

Если данная функциональность системы удовлетворяет этим трем требованиям:

• I nteresting (интересная)
• R eusable (многократного использования)
• A tomic (атомарная)

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

Давайте обсудим подход IRA на нескольких примерах.

Переменная	Заметки
Окружение	CRM-система электрокомпании
Функциональность	Возврат списка клиентов, которые были активны на портале самообслуживания в III квартале 2012
Это интересно?	Да, достаточно интересно. Это можно использовать для генерации всех видов полезных отчетов и статистики.
Это можно	Нет, не очень. Не смотря на то, что это позволяет создавать
многократно	высокоуровневые конструкции, такие как статистика за весь год,
использовать?	явно видно, что это нам не понадобится в 2018.
Это атомарно?	Скорее всего, да. Если уже существуют похожие сервисы для других кварталов, то можно будет просмотреть весь год.
Как сделать из этого IRA?	Заставить получать произвольные даты начала и конца периода, вместо указания только квартала. Заставить получать произвольные приложения, не только портал. Дать возможность указывать приложение для получения информации в качестве входного параметра.

Переменная	Заметки
Окружение	сайт электронной коммерции
Функциональность	Возврат каждого кусочка информации, который когда-либо был собран для указанного пользователя
Это интересно?	В общем, да. Если у Вас есть доступ к целому — Вы всегда сможете выбрать, что Вам нужно.
Это можно	Как ни странно, не совсем. Будут всего-лишь несколько
многократно	приложений, если вообще будут, которым будет интересно
использовать?	использовать абсолютно каждый кусочек информации.
Это атомарно?	Однозначно нет. Этот монстр функциональности обречен быть логически составленным из десятков меньших частей.
Как сделать из этого IRA?	Разделить на несколько меньших частей. Подумайте, что описывает покупателя — у них есть адреса, телефоны, любимые продукты, предпочтительные методы связи с ними и так далее. Каждый из этих пунктов должен быть превращен в независимый сервис. Используйте ESB для создания составных сервисов из атомарных.

Переменная	Заметки
Окружение	Любая CRM-система где угодно
Функциональность	Обновление колонки CUST_AR_ZN в таблице C_NAZ_AJ после того, как кто-то создал учетную запись
Это интересно?	Абсолютно неинтересно. Это внутренняя функция CRM-системы. Никто в своем уме не захочет иметь дело с такой низкоуровневой функциональностью.
Это можно	Да, вероятно. Учетная запись может быть создана через
многократно	несколько каналов, так что это кажется чем-то многократно
использовать?	используемым.
Это атомарно?	Кажется, да. Это простое обновление одной колонки в таблице.
Как сделать из
этого IRA?	Даже не пытайтесь сделать из этого сервис. Это неинтересно. Никто не хочет думать о конкретных колонках и таблицах в одной системе. Это сложная деталь CRM-системы и, даже не смотря на то, что это можно многократно использовать и это атомарно, из этого не стоит создавать сервис. Это Ваша и CRM, ответственность думать об этом, не заставляйте других нести ее тоже

Переменная	Заметки
Окружение	Оператор мобильной связи
Функциональность	Пополнение карты предоплаченной связи в биллинге
Это интересно?	Чрезвычайно. Все хотят использовать это, через текстовые сообщения, IVR, IM, порталы, подарочные карты и т. д.
Это можно	Да. Это может принимать участие во многих высокоуровневых
многократно	процессах.
использовать?
Это атомарно?	Да, с точки зрения вызывающего приложения, карта может быть пополнена, либо нет. То, что биллинг реализует это через серию шагов — не важно. С точки зрения бизнеса это атомарно, это — неделимый сервис, предоставляемый биллингом.
Как сделать из	Это уже IRA.
этого IRA?

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

Доступность сервисов в ESB и SOA¶

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

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

Так что, если, как в схеме вверху, у Вас 8 систем - тогда у Вас 16 интерфейсов (по одному в каждое направление) для создания, обслуживания, управления и обеспечения.

Без ESB у Вас было бы 56 интерфейсов для создания и управления (допуская, что каждая система общается с любой другой).

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

Один этот факт должен побудить Вас рассмотреть внедрение ESB.

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

Когда Вы станете “дышать” IRA-сервисами на регулярной основе, Вы сможете начать думать о составных сервисах.

Помните сервис “дайте-мне-все-что-можете-про-этого-клиента”, представленный выше?

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

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

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

Это потребует времени, терпения и скоординированных усилий, но это вполне выполнимо.

Но берегитесь…¶

Самый лучший способ уничтожить всю концепцию SOA — развернуть ESB и ожидать, что проблемы самоустранятся. Будучи великолепной идеей, просто развернуть ESB будет мало, к сожалению.

В лучшем случае попытка спрятать что-то под ковер, как в схеме внизу, не приведет ни к чему:

Ваши IT-ребята будут ненавидеть систему и, хоть поначалу менеджеры будут терпеть ESB в качестве нового решения, впоследствии оно станет посмешищем. “Что, это та самая новая серебряная пуля? Хахаха.”

Такие последствия неизбежны, если ESB не является частью большего плана по развитию.

Так, получается, ESB только для банков и подобных им?¶

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

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

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

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

корпоративная сервисная шина

Само собой, команда Zato может помочь.

Но я слышал, что SOA это XML, SOAP и веб сервисы¶

Да, некоторые люди хотели бы, чтобы вы верили именно в это.

Если люди или вендоры, с которыми Вы работали, отправляли закодированный в BASE64 CSV-файл в защищенном посредством SAML2 SOAP-сообщении, тогда вполне понятно, откуда у Вас сложилось такое впечатление.

XML, SOAP и веб сервисы — имеют свои сценарии использования, но как и все — они могут быть неправильно использованы.

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

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

Так что нет, SOA — это не XML, SOAP и веб сервисы. Они могут быть использованы, но они лишь часть, а не основа.

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

Дальше — больше¶

Эта глава покрывает только самые основы, но тем не менее должна дать четкое понимание как должны выглядеть ESB и SOA и что требуется для достижения успеха.

Другие темы, не затронутые здесь, включают (но не ограничены):

• Как получить поддержку от менеджеров для введения ESB
• Как собрать SOA-архитекторов и аналитические команды
• Представление канонической модели данных (Canonical Data Model — CDM) в организации
• Ключевые показатели эффективности (Key Performance Indicators — KPI) — теперь, когда у Вас есть общий и унифицированный метод предоставления сервисов между системами, Вы должны начать наблюдать и анализировать, что на самом деле Вам предоставляется
• Управление бизнес-процессами (Business Process Management — BPM) — как и когда выбрать BPM-платформу для управления сервисами (ответ — не слишком скоро, сначала познакомьтесь с тем, как строить приятные и полезные сервисы)
• Что делать с системами без API? К примеру, должна ли ESB получить прямой доступ к их базам данных (ответ — по разному, золотого правила нет)

Так что же такое Zato?¶

Zato — ESB и сервер приложений, написанный с использованием Python и может быть использован для построения промежуточных и бэкенд-систем. Это программное обеспечение с открытым исходным кодом с коммерческой поддержкой и поддержкой сообщества. И Python — язык программирования, известный своей простотой и эффективностью.

Использование Python и Zato позволяет увеличить производительность и тратить меньше времени впустую.

Zato был написан прагматиками для прагматиков . Это не еще одна наспех сооруженная вендором система на волне ESB/SOA шумихи.

На самом деле, Zato был построен исходя из практического опыта “тушения пожаров”, вызванных такими системами. В самом деле, авторы Zato провели настолько много времени в борьбе с такими окружениями, что они стали практически невосприимчивыми к любым пожарам.

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

Увидимся в здесь !

(Enterprise Service Bus) предназначена для построения распределённого информационного ландшафта предприятия. Программный продукт обеспечивает взаимодействие всех интегрируемых приложений в одном центре, объединяя существующие источники информации и предоставляя централизованный обмен данными между разными информационными системами.

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

Сервисная шина предприятия

Программный продукт DATAREON ESB официально включен в единый реестр российских программ для электронных вычислительных машин и баз данных, которые могут закупаться государственными и муниципальными учреждениями (https://reestr.minsvyaz.ru/).

Для интеграции 2-3 информационных систем в небольших компаниях DATAREON предлагает программный продукт, созданный на базе DATAREON ESB - DATAREON MQ.

Функциональные возможности DATAREON ESB

Задачи, решаемые с помощью корпоративной сервисной шины данных

• Передача данных между различными информационными системами (с маршрутизацией или «точка-точка»)
• Формирование единого информационного пространства в гетерогенных средах
• Построение распределённой системы на основании событийной модели в следующих вариантах:
  • построение приложений со сквозными бизнес-процессами на основании событийной модели;
  • создание системы с синхронизацией бизнес-приложений в различных информационных системах
• Получение масштабируемой архитектуры управления уровня предприятия/холдинга
• Развертывание системы обмена данными на транспортном уровне и на уровне бизнес-логики
• Делегирование задачи построения информационных потоков аналитическим отделам
• Уменьшение общей сложности интеграционной схемы и снижение требования к пропускной способности каналов
• Увеличение общей стабильности транспортного уровня передачи данных
• Снижение транзакционных издержек при обмене данными между различными подразделениями
• Снижение общих затрат на обслуживание и сопровождение информационной системы.

Преимущества корпоративной сервисной шины данных DATAREON ESB

• Быстрая интеграция
• Высокая надежность
• Возможность многократного использования ресурсов

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

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

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

Интеграция по типу «точка­точка»

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

Интеграция «точка-точка»

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

Интеграционный «фарш»

Единая сервисная шина

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

Основными компонентами, составляющими современную сервисную шину, являются:

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

Преимуществами использования единой сервисной шины можно назвать:

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

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

Enterprise Service Bus

Управление бизнес-процессами

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

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

На данный момент многие производители ПО склонны объединять BPM-среду и интеграционную шину в единую платформу промежуточного ПО, убирая существовавшее несколько лет строгое разделение между BPM-системами и средствами для интеграции приложений. Такой подход очень прогрессивен. Некоторые вендоры идут еще дальше и присоединяют к платформе профессиональные средства для моделирования бизнес-процессов. Пионером в этом является компания Software AG, предлагающая решение, объединяющее в себе известное средство моделирования ARIS Platform и интеграционную/BPM среду webMethods.

Комплексное использование интеграционной платформы

Предложения на рынке

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

Первая группа - предложения от фирм, чьи продукты лидируют в исследованиях аналитических агентств по всем обозначенным в статье категориям (ESB, SOA Governance, BPM, B2B). В эту группу входят:

• IBM с линейкой продуктов WebSphere;
• Software AG c интеграционной платформой webMethods;
• Oracle с целой серией предложений;
• Tibco с линейкой Business Integration.

В принципе, тем, кто не любит компромиссы, можно выбирать любого из этих производителей - все перечисленные компании предлагают полноценные линейки продуктов (правда, в случае с Oracle не всегда понятно, о каком именно продукте идет речь, поскольку после покупки ряда компаний Oracle предлагает сразу несколько продуктов, не всегда в достаточной степени интегрированных между собой). Немного особняком стоит Tibco, так как размер этой компании гораздо меньше размера остальных участников данной четверки, что может вызвать некоторые сомнения в ее стабильности. Software AG - пока не очень известный на российском рынке производитель, но у платформы webMethods, которая является сегодня ключевым предложением этой компании, большой потенциал. IBM и ее продукты знают и используют уже очень многие предприятия, но у некоторых из них возникают претензии по стоимости самого внедрения и обслуживания системы.

Вторая группа предложений - это компании, сконцентрированные в основном на «чис­том» ESB-функционале и достигшие здесь успеха. В эту группу попадают: Sun (Glassfish), Progress (Sonic) и Fujitsu.

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

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

Заключение

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

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

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

Нечто подобное происходит и с магистралями обмена данными, построенными по принципу «общей шины». Сейчас трудно оценить революционность идеи общей шины, а ведь в свое время это был настоящий переворот. Общая шина Unibus, предложенная три десятка лет назад инженерами корпорации Digital Equipment в качестве архитектурной основы для миниЭВМ PDP-11, оказалась чрезвычайно эффективным (а главное, дешевым) средством интеграции разнотипных устройств. В последующем на шинном принципе было построено множество компьютеров, в том числе все современные ПК. Собственно, с общей шины и начал формироваться рынок периферийных устройств. Однако со временем шины, используемые в качестве центрального архитектурного элемента компьютера, стали уступать свое место более быстродействующим коммутаторам, оставаясь при этом одним из основных вариантов подключения периферийных устройств. Сегодня шина, которую называют Enterprise Service Bus (ESB) , может сыграть примерно ту же роль, что и шина Unibus, со всеми достоинствами, но на более высоком уровне.

События и в самом деле развиваются стремительно. Всего лишь год назад один из ведущих аналитиков Gartner Group Ефим Натис высказал следующее предположение: «Один из основных подходов к созданию корпоративной инфраструктуры приложений строится с использованием слабосвязанных асинхронных процессов». А уже в октябре 2002 года в еженедельнике InfoWorld в статье Джона Уделла можно было прочитать: «Теперь, когда мы все согласны с тем, что Web-службы должны взаимодействовать в асинхронной манере, стало ясно, что программное обеспечение промежуточного слоя, ориентированное на обмен сообщениями (message-oriented middleware, MOM), приобретает решающее значение».

Как видим, всего за год предположение превратилось в утверждение. В том, что это произошло, заметную роль сыграла компания Sonic Software, образованная несколькими выходцами из BEA Systems и сегодня признаваемая в качестве одного из лидеров в разработке программного обеспечения промежуточного слоя. Очень интересные работы проделаны еще в нескольких небольших компаниях (например, Collaxa), однако Sonic одной из первых предложила свою реализацию слабосвязанных асинхронных процессов. При всей новизне, в своем программном продукте SonicXQ ESB компания, по сути, реализует старую, заимствованную у миниЭВМ идею общей шины, но при этом воплощает ее в новом обличии.

В данном случае ESB является общей в том смысле, что объединяет все приложения предприятия. ESB, реализованная с использованием архитектуры SOA (Service-Oriented Architecture), предназначена для интеграции корпоративных приложений на основе ориентированных на документы асинхронных Web-служб и J2EE Connector Architecture (JCA). Две этих технологии обеспечивают контентную маршрутизацию сообщений и позволяют так организовать взаимодействие между приложениями, и так интегрировать управление бизнес-процессами, что появляется возможность обойтись без дорогостоящих брокеров.

Оригинальность разработки SonicXQ привлекала к себе значительное внимание. Исторически первыми появились интеграционные брокеры (иногда их называют интеграционными серверами). Решения, построенные на основе интеграционных брокеров, можно представить в виде коммутаторов. С их помощью формируется некоторый гипотетический метакомпьютер, где все управление строится по централизованному принципу. В результате получается что-то вроде гипер-мэйнфрейма. Sonic совершила примерно то же самое, что DEC, предложившая три десятилетия назад шинные миниЭВМ в качестве недорогой альтернативы мэйнфремам; решение Sonic позволяет построить своего рода метакомпьютер для всего предприятия, но более дешевый. В итоге получается аналог мини-метакомпьютера: вместо дорогого коммутатора предлагается информационная магистраль предприятия Enterprise Service Bus.

Технология SonicXQ появилась не вдруг. У нее два достаточно хорошо известных источника. Первый - программное обеспечение промежуточного слоя на основе сообщений. Этот тип программного инструментария переживает настоящую реинкарнацию, особенно в связи с появлением Java Message Service от компании Sun Microsystems. О происходящем на этом фронте можно прочитать в , а более подробно о SonicMQ, непосредственном предшественнике SonicXQ, - в . Обе эти публикации сохраняют актуальность, но за прошедший год пейзаж корпоративного программного обеспечения заметно изменился, особенно под воздействием Web-служб. Еще год назад, когда готовились указанные публикации, представление о том, что такое Web-службы и каково их значение, было достаточно расплывчатым. За прошедшее время ситуация заметно прояснилась, и Web-службы следует назвать в качестве второго источника SonicXQ.

Enterprise Service Bus

Среди событий прошедшего года следует отметить появление в профессиональной терминологии нечто нового и непривычного. Одни, приверженцы лагеря Micrososft/IBM, называют это «оркестровкой» (orchestration) Web-служб, другие, из лагеря Sun/BEA, - «хореографией» (choreography) . Разгорается очередная битва в войне стандартов, за то, как лучше наладить согласованную работу корпоративных приложений с использованием Web-служб. Причина новой активности заключена в том, что всем, наконец, стало ясно: в сложившихся условиях исчерпаны возможности жестко связанных приложений, сложность систем стала слишком велика. Однако исходная схема распространения Web-служб с использованием построенных по стандарту UDDI репозиториев оказалась малоприменимой для корпоративных целей. В то же время, Web-службы и особенно их асинхронные ориентированные на документы версии предлагают реальный выход из «тупика сложности». С технической точки задача создания корпоративной инфраструктуры приложений с использованием слабосвязанных асинхронных процессов имеет несколько альтернативных решений.

Enterprise Service Bus, построенная на основе SonicXQ является одним из них. С помощью формируемой SonicXQ корпоративной магистрали реализуется распределенная архитектура, ориентированная на службы. ESB позволяет создавать контейнеры для размещения служб. Службы легко собрать и согласовать, поскольку упакованная в контейнер и являющаяся частью ESB служба представима другим частям ESB. При этом вся конструкция является виртуальной; реальная физическая сеть, в которой она «живет», может подвергаться изменениям без потери функциональности.

В процессе функционирования ESB одна или несколько связанных служб находятся в специальном контейнере (service container). Контейнеры являются средством для продвижения служб по распределенному процессу в соответствии с маршрутами сообщений (message itinerarу). Процедура прохождения сообщения выглядит следующим образом. Сообщение поступает на вход шины ESB. Здесь к нему добавляется маршрут, который позволяет организовать контентно-управляемое продвижение по распределенному процессу, этот процесс имеет децентрализованное управление. В рамках этого процесса сообщение проходит через ряд служб, достигая конечной точки, где извлекается из контейнера.

Для указания конечных точек могут быть использованы не физические, а логические имена. Установление соответствия между физическими и логическими именами (mapping) осуществляет специальный имеющийся в составе ESB механизм. Таким образом, в архитектуру изначально заложена способность к виртуализации; система может изменяться без модификации кода и разрушения действующих бизнес-процессов. Конфигурация допускает несколько уровней качества обслуживания (Quality of Service, QoS), гарантирующих надежное прохождение сообщений между приложениями. В общем случае, когда сообщение проходит весь свой маршрут, оно выходит за конечную точку получателя, а отправителю посылается подтверждающее получение сообщение. Достоинство распределенного процесса передачи сообщений на основе ESB заключается в том, что по своей логике он очень близок взаимодействию в реальном мире.

Основы: JCA и Web-службы

Предлагаемая в ESB интеграция приложений стала возможной благодаря появлению архитектуры соединений JCA от Sun Microsystems и SOAP, стандартного протокола для Web-служб. JCA, специально разработанная для преодоления сложностей, связанных с интеграцией приложений, предлагает стандартизированные методы для решения этой задачи. Корпоративная информационная система, построенная по принципам JCA, использует для доступа к приложениям интерфейс JDBC. Сегодня этот подход весьма популярен; большинство современных серверов приложений, в том числе, BEA WebLogic и IBM WebSphere поддерживают адаптеры JCA. Кроме того, многие поставщики пакетных решений намерены поддерживать JCA в будущих версиях своих продуктов.

Оригинальность использования Web-служб в SonicXQ заключается в том, как организован процесс «оркестровки» (или «хореографии»). В его основе лежит протокол SOAP, но наложенный на простой и масштабируемый формат сообщений. При этом SonicXQ Enterprise Service Bus обеспечивает совместимость и с асинхронной документальной моделью SOAP (document asynchronous model), так и с синхронной моделью SOAP, построенной по принципу вызова удаленных процедур (RPC). В SonicXQ службы описываются на языке WSDL, но WSDL непосредственно интегрирован Distributed Processing Framework. В результате служба может быть зарегистрирована во внешнем каталоге UDDI, а может и не быть, если в этом нет необходимости.

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

Литература

1. Леонид Черняк. МОМ, второе рождение //

2. Валерий Кор жов. Почтальон для приложений //

3. Stuart J. Johnston, Web Services Wars Take Artistic Turn. Choreography or orchestration? XML Magazine, 2002, № 10/11

Данной статьей хочется открыть цикл, посвященный IBM WebSphere ESB (далее - ESB) в разрезе разработки под этот продукт. И, в первую очередь, придется познакомиться поближе с технологиями такого рода.
Enterprise service bus (сервисная шина предприятия) - связующее программное обеспечение, обеспечивающее централизованный и унифицированный событийно-ориентированный обмен сообщениями между различными информационными системами на принципах сервис-ориентированной архитектуры.
Конечно же, можно и без специального ПО (возможно, что-то общее таки придется разработать) строить корпоративную систему основываясь на таком подходе, и то, что в результате получится, называть сервисной шиной. Но в продукте от IBM есть не только уже готовый аппарат для централизованного обмена сообщениями и контроля этого процесса, но и полный набор возможностей для разработки гибких сервис-ориентированных приложений специально под ESB. В итоге, можно выделить следующие возможности и преимущества IBM WebSphere ESB:

• Порядок и единообразие архитектурных связей
• Централизованное управление
• Конфигурация приложений на стороне сервера
• Реализация технологии Service Component Architecture (SCA) в духе принципов сервис-ориентированной архитектуры
• Протоколо-независимость разрабатываемого программного кода
• Широкие возможности конфигурирования шины и приложений

При этом ESB обеспечивает транзакционный контроль, преобразование данных, сохранность и гарантированную доставку сообщений. Доступ ко всем сервисным службам через единую точку позволяет осуществлять конфигурирование коммуникации сервисов централизованно. Так же централизованно можно управлять сбойными событиями для массовой обработки ошибок.
Классическая топология сборки ESB – кластер, обеспечивающий горизонтальную масштабируемость и отказоустойчивость. По официальным рекомендациям, увеличение количества членов кластера увеличивает производительность более эффективно, чем наращивание мощности сервера при stand-alone топологии. Кроме этого, кластер можно перезагрузить (или его часть может отказать) без остановки обслуживания.
Обычно ESB используется как сервисная прослойка в IBM BPM, но вполне может играть ведущую роль в построении модели взаимодействия корпоративных систем как мощный интеграционный аппарат (имеется в виду ESB как надстройка над IBM WebSphere Application Server).
Это, по сути, требуется от ESB, так как это «точка сбора сервисов» - если вам нужен сервис, который будет работать с другими сервисами (возможно, внешними), то интеграцию между этими сервисами логичнее всего сделать именно на ESB. Для внешних или гетерогенных сервисов можно сделать «обертку» ESB-сервисом. Немного проиллюстрируем удобства использования «единого жилья» для сервисов:

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


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

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


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

Конфигурация на стороне сервера
«Единое жилье» для сервисов, с точки зрения конфигурирования, позволяет достичь нескольких полезных целей. Во-первых, это повторное использование конфигурации (по аналогии с повторным использованием кода и модулей, которое так полезно в SOA), поскольку разные модули и приложения могут использовать одни и те же параметры соединения с БД, ресурсы, параметры аутентификации, переменные среды и прочее.


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

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

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

SCA
Эта архитектура основывается на принципе предоставления компонентой своей функциональности в виде сервиса, доступного другим компонентам. В рамках одного модуля компонентами выступают программные блоки (java код), полностью реализующие некий функционал, описанный соответствующим интерфейсом. Логика выполнения компонент реализуется связыванием их в структуру по интерфейсам и reference’ам (Partner Reference).

Такую структуру модуля очень удобно разрабатывать, проверять, развивать, изменять и поддерживать. Атомарность функционала, реализованного в компонентах, позволяет оперировать компонентами в целом, не опускаясь до уровня кода. С другой стороны, она логично необходима ввиду выполнения имплементаций компонент в транзакционном контексте.
У каждой компоненты есть интерфейс(ы), имплементацию которого она предоставляет. Таким образом, связывая между собой компоненты, нет необходимости знать их внутренние особенности – достаточно того, что они реализуют необходимые интерфейсы.
Посредством данной архитектуры также можно решить все задачи, требующие параллельной работы, без «ручного» управления потоками (например, можно выполнять асинхронные вызовы нескольких компонент с отсроченным ответом).
Не java-компоненты, например, типов Export и Import, позволяют предоставлять сервисы для внешнего использования либо использовать внешние сервисы соответственно; компонента Mediation Flow обеспечивает низкоуровневый доступ к сообщениям, которыми обмениваются другие компоненты и позволяет производить различные преобразования при работе с гетерогенными интерфейсами.
Помимо интерфейсов, очень полезные возможности предоставляет IBM business object framework. Бизнес-объекты (БО), представлены xsd-схемами, используются как объекты для передачи данных в интерфейсах, как между компонентами, так и для коммуникации между модулями. Они же напрямую интегрируются, например, в wsdl-схему для описания веб-сервисов. То есть, например, если модуль «А» предоставляет свой функционал в виде веб-сервиса, модулю «Б» для его использования достаточно подключить интерфейс и готовые БО, и он сможет в полной мере работать с таким сервисом без создания каких-либо дополнительных java-объектов для передачи данных. БО также удобно использовать при обмене данными с БД, если эти данные используются другими компонентами (это, конечно, идет в разрез с паттерном «DAO», но избавляет от лишних java-объектов и операций переписывания данных «туда-сюда»).

Протоколо-независимость программного кода
Как можно было заметить, протоколо-независимость кода достигается путем использования компонент Export и Import. Поскольку связь с этими компонентами идет по интерфейсам и reference’ам, программный код полностью независим от используемого для взаимодействия протокола. Один и тот же функционал можно легким движением сделать доступным по любому количеству поддерживаемых протоколов и по любым нужным интерфейсам. На следующем рисунке показано добавление экспорта с SCA привязкой к компоненте, которая уже предоставляет свой интерфейс как HTTP, JMS и Web-сервис.


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

Конфигурирование
Конфигурирование сервера и приложений осуществляется через IBM console сервера.
В ESB, как и в IBM WebSphere в общем, довольно много специфических возможностей и артефактов. Например, при использовании тех же импортов и экспортов, можно «на лету» конфигурировать end-point’ы соответствующих сервисов. Для вызовов сервисов можно настраивать policy set’ы с разнообразными правилами (например, можно установить поддержку механизма WS-AT, который позволяет вызывать веб-сервис в той же транзакции, в которой работает клиент; но транзакционность – это уже тема для полной статьи), устанавливать параметры аутентификации, подключать сертификаты и прочее.
Через конфигурирование можно настроить некоторые механизмы автоматической реакции на исключительные ситуации (например, автоматическое повторение выполнения компонент при ошибках). Можно «на лету» настроить трассировку компонент или изменить уровни логирования. Также доступен сервис управления сбойными событиями, который можно осознанно использовать для массовой обработки ошибок.
Ну и, конечно же, можно настроить много чего другого согласно спецификации Java2EE, которая, иногда довольно строго, реализована в IBM Application Server.

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

В статье использованы следующие изображения:

Функции Enterprise Service Bus

Современная интеграция информационных систем представляет собой реализацию сервис-ориентированной архитектуры (Service-Oriented Architectures, SOA) с использованием технологий Web-cервисов; существует много превосходных описаний преимуществ и методов такой реализации (см. раздел ). В последнее время ключевым компонентом инфраструктуры SOA считается корпоративная сервисная шина Enterprise Service Bus (ESB) (см. раздел ). Однако важно точно знать, что такое ESB - продукт, технология, стандарт или что-либо еще. В частности, можно ли построить ESB сегодня, и если да, то как именно?

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

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

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

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

Роль ESB в структуре SOA

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

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

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

Рисунок 2. Централизованное управление распределенной инфраструктурой ESB

Кроме того, следует обозначить позицию ESB по отношению к другим компонентам инфраструктуры SOA, в частности, компонентам службы каталогов Service Directory, Business Service Choreography и Business-to-Business (B2B) Gateway. Поскольку перечисленные выше принципы SOA не требуют обязательного наличия этих компонентов, давайте считать их необязательными компонентами. На показана инфраструктура SOA, демонстрирующая отношения этих компонентов к ESB.

Рисунок 3: Роль ESB в структуре SOA

Для осуществления маршрутизации запросов сервиса ESB необходим особый каталог маршрутизации сервиса . Однако в SOA может также присутствовать отдельный каталог бизнес-сервиса , который, в самой простой форме, может представлять собой временный (используемый при разработке проекта) каталог, который используется для обеспечения многократного использования сервисов разработчиками организации. В представлении о Web-cервисах роль каталога бизнес-сервиса и каталога маршрутизации сервиса отводится каталогу UDDI, тем самым обеспечивается динамическое обнаружение и вызов сервисов. Такой каталог может рассматриваться как часть ESB, однако до тех пор, пока такие решения не получат достаточного распространения, лучше, чтобы каталог бизнес-сервиса существовал отдельно от ESB.

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

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

Модель производительности ESB

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

Таблица 1. Функции ESB, описанные в специальной литературе

Связь	Взаимодействие сервисов
Маршрутизация; Адресация; Технологии, протоколы и стандарты связи (например, IBM® WebSphere® MQ, HTTP и HTTPS) Публикация/подписка; Ответ/запрос; Запустил-и-забыл, события; Синхронный и асинхронный обмен сообщениями.	Определение интерфейса сервиса (например, язык WSDL (Web Services Description Language, язык описания Web-сервисов); Поддержка возможности замены реализации сервиса; Модель организации сервиса обмена сообщениями, необходимая для связи и интеграции (например, SOAP или модель связующего ПО корпоративной интеграции приложений (EAI, enterprise application integration); Каталог сервиса и обнаружение сервиса.
Интеграция	Качество сервиса
База данных; Агрегация сервиса; Адаптеры для имеющихся систем и приложений; Обеспечение подключения к связующему ПО EAI; Отображение сервиса; Преобразование протоколов; Среда сервера приложений (например, J2EE и.NET); Интерфейс языка прикладного программирования для вызова сервиса (например, Java и C/C++/C#).	Транзакции (Неделимые транзакции, Компенсация, WS-транзакция); Различные парадигмы гарантированной доставки (например, WS-ReliableMessaging или поддержка связующего ПО EAI).
Безопасность	Уровень сервиса
Аутентификация; Авторизация; Невозможность отказа от авторства; Конфиденциальность; Стандарты обеспечения безопасности (например, Kerberos и WS-Security).	Производительность; Пропускная способность; Доступность; Прочие непрерывные меры, которые могут стать основой контрактов или соглашений.
Обработка сообщений	Управление и автономность
Закодированная логика; Логика, основанная на контенте; Преобразование сообщений и данных; Проверка корректности; Посреднические; Тождественное отображение объектов; Обогащение данных.	Инициализация и регистрация сервиса; Ведение журналов, измерения, мониторинг; Обнаружение; Интеграция с инструментами управления и администрирования системы; Самонаблюдение и самоуправление.
Моделирование	Интеллектуальные функции инфраструктуры
Моделирование объектов; Общие модели бизнес-объектов; Библиотеки форматов данных; Открытые или закрытые модели для интеграции B2B; Инструменты разработки и развертывания.	Бизнес-правила; Управляемое политиками поведение, особенно для функций уровня сервиса, обеспечения безопасности и качества сервиса (например, WS-Policy); Распознавание шаблона.

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

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

Минимальный набор функций ESB для SOA

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

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

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

Таблица 2. Минимальный набор функций ESB

Связь	Интеграция
Маршрутизация и адресация сервисов для обеспечения прозрачности размещения; Функция администрирования для управления адресацией и именованием сервисов; По меньшей мере одна из форм парадигмы обмена сообщениями (например, запрос/ответ, публикация/подписка и т. п.); Поддержка по меньшей мере одного транспортного протокола, который является или может стать общедоступным.	Поддержка нескольких средств интеграции с поставщиками сервиса, например, коннекторов Java 2, Web-сервисов, асинхронного обмена сообщениями, адаптеров и т. п.
Взаимодействие сервисов
Открытая и независимая от реализации модель обмена сообщениями и организации интерфейсов, которая должна изолировать код приложения от специфических условий маршрутизации сервисов и транспортных протоколов, а также обеспечение возможности замены реализации сервиса

Обратите внимание на то, что минимальный набор функций не требует использования каких-либо определенных технологий , например, связующего ПО EAI, Web-сервисов, J2EE или XML. Вполне вероятно, что такие технологии будут использоваться, поскольку они отвечают требованиям, но это не является обязательным. И наоборот, минимальный набор функций почти, если не полностью, обеспечивается простым использованием SOAP/HTTP и WSDL.

• Адресация URL и существующая инфраструктура HTTP и DNS предоставляют инфраструктуру "шины", обеспечивающей маршрутизацию сервисов и прозрачность размещения;
• SOAP/HTTP поддерживает парадигму обмена сообщений запрос-ответ ;
• Транспортный протокол HTTP является широко доступным;
• SOAP и WSDL представляют собой открытую, независимую от реализации модель организации интерфейса и обмена сообщениями сервисов.

Тем не менее, использование SOAP/HTTP и WSDL в простейшей форме в действительности обеспечивает только интеграцию от точки до точки и не предоставляет следующих ключевых функций, необходимых для ESB:

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

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

• Функции обеспечения качества сервиса и уровня сервиса;
• Концепции SOA более высокого уровня - service choreography, каталог, преобразование и т. д.;
• Требования операционной среды по требованию (On Demand), такие как функции автономности и управления, а также интеллектуальные функции инфраструктуры;
• По-настоящему неоднородные операции в нескольких сетях, с несколькими протоколами и несколькими доменами с разными моделями владения.

Проблемы безопасности, связанные с ESB

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

1. Будет ли приемлемым уровень безопасности инфраструктуры связи при использовании взаимной аутентификации по протоколу безопасных соединений Secure Socket Layer EAI между серверами связующего ПО EAI или при использовании протокола HTTPS?
2. Будет ли достаточно индивидуальной, от точки к точке, системы безопасности между системами-участниками, или необходима сквозная модель обеспечения безопасности? Например, есть ли необходимость в распространении идентификационной информации клиента через промежуточные системы, например, брокеры, конечным поставщикам или реализациям сервиса?
3. Будет ли приемлемой безопасность на прикладном уровне, например, может ли клиентский код выполнить базовую аутентификацию HTTP по идентификатору пользователя и паролю, или сможет ли он передать эту информацию сервису как данные приложения?
4. Требуется ли соответствие механизма безопасности стандартам обеспечения безопасности, например, Kerberos или WS-Security?

Хотя возможны все перечисленные подходы к обеспечению безопасности, рекомендуется использование соответствующих стандартам (например, WS-Security) функций обеспечения безопасности при поддержке инфраструктуры и связующего ПО. Однако эти стандарты появились сравнительно недавно, и поддержка их программными продуктами пока находится в фазе развития, особенно в случаях, связанных с обеспечением функциональной совместимости. Таким образом, одним из приоритетов архитектуры ESB должно стать утверждение требований к обеспечению безопасности на ранних фазах разработки, чтобы их можно было учесть при выборе технологии реализации.

Заключение

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

ESB предоставляет распределенную инфраструктуру и функции централизованного управления, для чего необходим каталог маршрутизации сервиса и кроме того, возможно, каталог бизнес-сервиса. Компонент Business Service Choreographer вызывает сервисы из ESB, а затем представляет процессы как новые сервисы через ESB.

Среди множества функций, предоставляемых ESB, имеются функции:

• Связи;
• Взаимодействий сервисов;
• Интеграции;
• Обеспечения качества сервиса;
• Безопасности;
• Обеспечения уровня сервиса;
• Обработки сообщений;
• Управления и автономии сервиса;
• Моделирования;
• Интеллектуальные функции инфраструктуры.

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

Благодарности

Эта статья вряд ли вышла в свет, если бы автор не обсуждал свои идеи со следующими людьми: Бет Хатчисон (Beth Hutchison), Рейчел Рейниц (Rachel Reinitz), Олаф Циммерман (Olaf Zimmerman), Хелен Уайли (Helen Wylie), Кайл Браун (Kyle Brown), Марк Колан (Mark Colan), Джонатан Адамс (Jonathan Adams), Пол Фремантл (Paul Fremantle), Кейт Джонс (Keith Jones), Пол Вершурен (Paul Verschueren), Дэниэл Стэрмен (Daniel Sturman), Скотт Косби (Scott Cosby), Дейв Кларк (Dave Clarke), Бен Манн (Ben Mann), Луиза Гиллис (Louisa Gillies), Эрик Хернесс (Eric Herness), Билл Хасселл (Bill Hassell), Гуру Васудева (Guru Vasudeva), Карим Юсуф (Kareem Yusuf), Кен Уилсон (Ken Wilson), Марк Эндреи (Mark Endrei), Норберт Биберштейн (Norbert Bieberstein), Крис Нотт (Chris Nott), Алан Хопкинс (Alan Hopkins) и Ярослав Данчич (Yaroslav Dunchych).