Подходы к интеграции приложений Enterprise Service Bus. Функциональные возможности 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 в данной статье бессмысленно, вы можете получить такой список в любом поисковике. Если ваш бюджет на интеграцию ограничен, а сами вы склонны к экспериментам - вы вполне можете попытать счастья с любым из них. Однако риски, касающиеся как недостаточно проработанной функциональности, так и возможных проблем с надежностью, технической поддержки и перспектив развития продуктов, вы принимаете на себя.

Заключение

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

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

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

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

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

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

Вызов служб

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

Для начала, я должен объяснить терминологию. Web-служба во многом похожа на функцию в процедурном программировании: она имеет имя, параметры и результат. Именем является Uniform Resource Identifier (URI – унифицированный идентификатор ресурса), который провайдер Web-службы использует для того, чтобы Web-служба стала доступна как оконечная точка . Провайдер Web-службы использует URI оконечной точки в качестве адреса для нахождения и вызова Web-службы. В запросе присутствуют конкретное действие и параметры, которые потребитель передает Web-службе при вызове оконечной точки. После выполнения службы оконечная точка передает ответ обратно потребителю, в котором сообщается об успешном выполнении (или об ошибке) и содержится результат работы службы. То есть, потребитель вызывает оконечную точку провайдера, передает запрос и получает назад ответ.

Текущее определение способа реализации Web-службы – это WS-I Basic Profile 1.1, который состоит из протокола "SOAP 1.1 over HTTP 1.1", описанного на языке Web Services Description Language (WSDL) 1.1 (ссылка на саму спецификацию приведена в разделе " "). В "SOAP over HTTP" потребитель вызывает службу, используя передаваемый по HTTP в HTTP-запросе SOAP-запрос. Потребитель синхронно блокирует работу по HTTP-сокету, ожидая HTTP-ответ, содержащий SOAP-ответ. API оконечной точки описан ее WSDL – контрактом между потребителем и провайдером службы.

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

Сравнение синхронного и асинхронного вызовов

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

• Синхронный . Потребитель использует один поток для вызова службы; поток передает запрос, блокируется на время выполнения службы и ждет ответ;
• Асинхронный . Потребитель использует два потока для вызова службы; один - для передачи запроса, второй – для приема ответа.

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

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

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

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

1. Синхронный прямой вызов;
2. Синхронный вызов через посредника (брокера);
3. Асинхронный вызов через посредника (брокера).

Каждый вариант я рассмотрю отдельно

Синхронный прямой вызов

Метод вызова Web-службы "SOAP over HTTP" является прямым: аналогично вызову функции потребитель знает адрес оконечной точки и вызывает ее напрямую. Для успешного вызова Web-служба должна функционировать при вызове оконечной точки потребителем и должна дать ответ до истечения времени ожидания потребителем. Если Web-служба разворачивается в новом месте (например, другой интернет-домен), потребитель должен быть уведомлен о новом URI оконечной точки. При развертывании нескольких провайдеров службы одного типа оконечная точка каждого провайдера должна иметь различный URI. Для выбора конкретного провайдера службы потребитель должен знать каждый такой URI.

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

Для решения этой проблемы существует спецификация Universal Description Discovery and Integration (UDDI), описывающая Web-службу, которая является каталогом (аналогичным телефонной книге) для поиска других Web-служб. Идея заключается в развертывании UDDI-службы по хорошо известному потребителю адресу; потребитель может использовать UDDI для поиска других Web-служб.

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

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

1. Потребитель запрашивает у UDDI список провайдеров службы;
2. Потребитель выбирает оконечную точку провайдера из списка, полученного из UDDI;
3. Потребитель вызывает эту оконечную точку.

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

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

Синхронный вызов через посредника

Недостатком прямого вызова является необходимость знания URI оконечной точки провайдера потребителем для вызова службы. Он использует UDDI как каталог для поиска этого URI. Если имеется несколько провайдеров, UDDI содержит несколько URI, и потребитель должен выбрать один из них. Если провайдер меняет URI оконечной точки, он должен повторно зарегистрироваться на сервере UDDI, для того чтобы UDDI хранил новый URI. Потребитель должен повторно запросить UDDI для получения нового URI. В сущности это означает, что каждый раз, когда потребитель хочет вызвать службу, он должен запросить в UDDI URI оконечных точек и выбрать один из них. Это ведет к затратам потребителем значительных усилий при периодических операциях запроса в UDDI и выбора провайдера. Этот подход также вынуждает потребителя выбирать провайдера каким-либо способом, по всей видимости, из эквивалентного списка.

Одним из способов упрощения проблемы является введение брокера, работающего как промежуточное звено при вызове Web-службы. Потребитель больше не вызывает службу провайдера напрямую, а вызывает прокси-службу брокера, который, в свою очередь, вызывает службу провайдера. Потребитель должен знать URI оконечной точки прокси-службы и поэтому использует UDDI для поиска адреса, но, в данном случае, UDDI возвращает только один URI, и потребитель не должен делать выбор. Потребитель может даже и не знать, что оконечная точка является прокси-службой; он знает только о том, что может использовать этот URI для вызова Web-службы. Брокер связывает потребителя с провайдерами служб (см. рисунок 3).

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

На рисунке 4 показана схема использования брокера потребителем при вызове службы. Алгоритм работы следующий:

1. Потребитель запрашивает в UDDI список провайдеров службы. Возвращенный из UDDI URI фактически является прокси-службой. UDDI вернет только один URI, а не несколько, поскольку брокер имеет только одну прокси-службу для каждой конкретной службы;
2. Потребитель вызывает службу, используя URI прокси;
3. Прокси-служба выбирает провайдера службы из списка доступных провайдеров;
4. Прокси-служба вызывает оконечную точку выбранного провайдера.

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

Обратите внимание также на то, что поскольку адрес прокси является стабильным, потребитель не должен постоянно запрашивать UDDI при каждом вызове службы. То есть, потребитель должен только один раз запросить UDDI, затем сохранить в кеше адрес прокси-службы и использовать его при повторных вызовах службы. Это значительно снижает накладные расходы при вызове службы.

Асинхронный вызов через посредника

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

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

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

Этот подход использует шаблон Request-Reply для вызова Web-службы. Вместо указанного в WS-I BP 1.1 протокола HTTP транспортные функции могут теперь выполнять очереди сообщений. SOAP-запрос и ответ является таким же, как и с WS-I BP, но они заключены в сообщения системы обмена сообщениями.

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

1. Потребитель передает SOAP-запрос в виде сообщения в очередь запросов. Потребитель заканчивает работу и может использовать данный поток для выполнения других задач;
2. Каждый провайдер является потребителем очереди запросов, что делает их конкурирующими потребителями. Система обмена сообщениями определяет, какой провайдер может получить сообщение, и гарантирует его получение только одним провайдером. Как это работает на самом деле, зависит от реализации системы обмена сообщениями;
3. Победивший провайдер получает сообщение из очереди запросов;
4. Провайдер выполняет службу;
5. Провайдер передает SOAP-ответ в виде сообщения в очередь ответов. Теперь провайдер заканчивает свою работу и может использовать свой поток для других задач (например, для ожидания следующего запроса);
6. Прослушивающий поток потребитель получает сообщение, содержащее SOAP-ответ.

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

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

Теперь вы знаете варианты типов соединения для вызова служб. Рассмотрим дополнительные интеграционные возможности, которые тоже могут быть полезными, а затем, как разработать ESB, предоставляющую нам эти возможности.

Другие интеграционные возможности

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

Передача данных

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

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

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

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

Уведомление о событиях

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

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

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

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

Дополнительную информацию по технологии передачи данных можно найти в шаблоне Event Message (опять же, обратитесь к книге "Шаблоны корпоративной интеграции", ссылка на которую приведена в разделе " ").

Разработка Enterprise Service Bus

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

Брокером часто начинают называть ESB. Так как же ESB вписывается в уже принятые проекты и шаблоны?

Самоописание и обнаруживаемость

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

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

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

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

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

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

Шлюз служб

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

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

1. Типы портов – Набор операций, выполняемых Web-службой. Типом порта может быть stockBrokerServices с портами/операциями, например, getQuote .
2. Сообщения – Формат запросов и ответов, например, getQuoteRequest (который содержит символ акции) и getQuoteResponse (который содержит цену).
3. Типы – Типы данных, используемых Web-службой, например, symbol и price (или просто xs:string и xs:decimal).
4. Связи – Адрес для вызова операции, например, http://stockbroker.example.com/getQuote.

Такие Web-службы шлюза (или более конкретно их прокси-службы) являются также обнаруживаемыми. Шлюз предоставляет эту возможность в виде UDDI-службы, как было рассмотрено ранее. Для нахождения адреса вызова службы потребитель запрашивает в UDDI-службе шлюза список провайдеров нужной WSDL-операции и получает назад адрес прокси-службы шлюза для этой операции.

Шина сообщений

В основе асинхронной ESB лежит известный шаблон Message Bus (Шина сообщений), описанный в книге "Шаблоны корпоративной интеграции ", ссылка на которую приведена в разделе " ". Шина сообщений представляет собой набор каналов сообщений (известных также как очереди или темы), обычно настроенных как пары каналов запрос-ответ. Каждая пара представляет службу, которая может быть вызвана потребителем, использующим шину. Этот потребитель передает сообщение в очередь запросов службы и затем (в асинхронном режиме) слушает очередь ответов для получения результата. Он знает, какой результат соответствует его конкретному запросу, поскольку результат имеет правильный корреляционный идентификатор.

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

Такая шина сообщений является сущностью ESB, и здесь нет ничего нового. Интеграторы приложений использовали эту технологию более десятилетия, применяя такие продукты обработки очередей сообщений как WebSphere® MQ и TIBCO Enterprise Message Service. И на самом деле часто говорят, что если вы используете продукты корпоративного обмена сообщениями, то у вас есть ESB. Клиенты IBM уже некоторое время пользуются этими возможностями с WebSphere Business Integration Message Broker и WebSphere MQ.

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

Лучшая шина сообщений

Итак, если шина сообщений не является полной ESB, тогда что еще делает ESB?

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

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

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

ESB нуждается в аналогичной службе каталогов с UDDI-подобным API, используя который потребитель мог бы запросить адрес службы, реализующей желаемую WSDL-операцию. ESB возвращает адрес соответствующей пары каналов запросов и ответов. То есть, ESB-клиент, аналогично UDDI-клиенту, не должен знать ничего кроме следующего:

1. WSDL, описывающий службу, которую хочет вызвать.
2. Адрес службы каталогов ESB (который может быть производным от корневого адреса ESB).

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

Синхронный или асинхронный?

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

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

Заключение

Как вы увидели, служба может быть вызвана любым из следующих способов:

1. Напрямую и синхронно;
2. Синхронно через брокера;
3. Асинхронно через брокера.

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

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

Если в этот момент провести аудит IT-инфраструктуры, типичный диагноз будет выглядеть примерно так:

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

2) Отсутствует единое контролирующее звено, ответственное за актуализацию и предоставление данных из различных информационных систем.

3) Отсутствует контроль процессов обмена: нет единой среды обмена данными между информационными системами.

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

Решение комплекса подобных проблем – в переходе к построению IT-инфраструктуры на основе концепции сервис-ориентированной архитектуры (Service Oriented Architecture, SOA), ключевым элементом которой является Интеграционная сервисная шина. Шина – это программное обеспечение, позволяющее объединять большое число платформ и приложений, а также организовать взаимодействие между ними на основе сервисов. При этом технологии, на которых реализованы системы и их сервисы не имеют значения, это может быть JAVA, .NET или другая платформа.

Интеграционная шина, как правило, предоставляет следующие функции:

Преобразование сообщений, а также их передача, алгоритмическое перенаправление, постановка в очередь и отслеживание;

Работа с сообщениями в режимах: синхронном, асинхронном, «точка-точка», «публикация-подписка»;

Поддержка XML и SOAP сообщений;

Возможность подключения множества систем через готовые адаптеры и API для написания новых адаптеров;

Оркестровка (автоматическое размещение, координация и управление) служб.

Концептуально архитектура с использованием Интеграционной сервисной шины выглядит так:

Рисунок 1 Архитектура с использованием интеграционной шины

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

• Внести данные клиента
• Проверить, существует ли запись о данном клиенте
• Получить список счетов клиента
• Получить список сервисов, которыми пользовался клиент
• Получить агрегированные данные по истории выплат по кредитам
• Получить данные для отчета
• Получить баланс счета
• Рассчитать кредитный рейтинг
• Сформировать отчет для рассмотрения менеджером
• Обновить данные по счету
• Сформировать уведомление для клиента

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

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

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

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

Рисунок 2 ИТ-архитектура банка до и после внедрения шины

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

Рассмотрим внедрение интеграционных шин в нескольких крупных международных банках.

Chinatrust Commercial Bank (Коммерческий банк Чайнатраст) использует интеграционную шину для поддержки своих продуктов и сервисов. Сервис-ориентированная архитектура на основе интеграционной шины объединяет более семидесяти систем на множестве платформ, таких как: автоматизированная банковская система, сетевой банкинг, ипотечная система, лотерейная система, система автоматизации рабочих процессов, интерактивное голосовое меню и т.д. В режиме реального времени стали доступны такие сервисы, как: агрегация данных, сводка по счету, входящие и исходящие переводы, трансферы, уведомления (задействован функционал событийно ориентированных коммуникаций) и другие. Расходы на интеграцию новых систем снизились в среднем на 30..40%.

В настоящее время интеграционная шина банка поддерживает 100 000 ежедневных транзакций в корпоративном секторе и 50 000 в ритейле. Количество транзакций онлайн банкинга возросло с 150 000 до 1 200 000 в сутки.

Сингапуро-малазийский банк OCBC недавно поставил себе цель в пятилетний срок повысить эффективность работы на 25% и снизить затраты на разработку новых программных интерфейсов на 30%. Первый сервис на основе SOA был запущен в 2006 году. Через шесть месяцев работало 116 единичных сервисов, каждый из которых пригоден к использованию в составных сервисах. 50 единичных сервисов являлись частью нескольких составных. Для поддержки интеграционных процессов банк создал Центр Интеграционных Компетенций. В OCBC полагают, что для достижения заявленных целей SOA играет ключевую роль.

В Японии конкуренция в области интернет-банкинга чрезвычайно высока. Банк Sumishin Net Bank, Ltd. поставил целью предложить на рынок широкий набор продуктов за более короткий промежуток времени, чем прочие финансовые институты. Для достижения этой цели банку необходимо было соответствовать строгим техническим стандартам, накладываемым на японский банковский сектор и одновременно с этим развивать конкурентные преимущества. Была разработана сервис-ориентированная архитектура с использованием десяти программных продуктов, в том числе интеграционной шины. Всего лишь в течение 18 месяцев после запуска новой линейки услуг в банк было вложено ориентировочно 600 млрд. йен (около $6 млрд.), открыто 400 000 счетов. Была достигнута невероятная гибкость в добавлении новых сервисов. Существенно снизилась стоимость их разработки.

В России интеграционные шины применяются на многих крупных предприятиях, в том числе операторах связи, банковской сфере, а также в комплексе систем электронного правительства Российской Федерации. Внедрение интеграционных шин, как правило, ведется системными интеграторами. В частности, наша компания АМТ-ГРУП, входящая по данным cnews.ru в Топ 20 российских компаний – поставщиков IT услуг для банков, имеет успешный опыт работы с интеграционными шинами и их внедрения в разных сферах деятельности, включая банковский сектор. Наши специалисты имеют богатый опыт создания сервис-ориентированных архитектур на основе интеграционных шин, включая аудит бизнес-процессов и их последующую автоматизацию, создание коннекторов для интегрируемых систем и оптимизацию рабочей среды.

В статье использованы материалы из открытых источников:
http://www.tibco.com/multimedia/ss-ctcb_tcm8-15110.pdf
http://www.eawriter.com/images/case_studies/TIBCO_2.pdf
http://www-01.ibm.com/software/success/cssdb.nsf/CS/JSTS-7V4BWP?OpenDocument&Site=corp&cty=en_us

Оценить:

4 15

В Москве с 1958 года существовала 3-я улица Строителей, но в 1963 году её переименовали - теперь это улица Марии Ульяновой, а дом 25 по этой улице - хрущёвская пятиэтажка. В Ленинграде (Санкт-Петербурге) 3-ей улицы Строителей не существовало никогда…

Я снова про интеграцию приложений. Читал сегодня отечественный стандарт межведомственного документооборота ГОСТ Р 53898-2010 И стандарт вроде бы «правильный» на XML-е писанный и поля там всякие полезные на 53-х страницах приведены и все дела. Помнится, в конце прошлого века я всячески ратовал за появление стандартов электронных сообщений на страницах журнала Компьютера в заметке Фактор Internet в развитии систем «клиент-банк» В конце прошлого века все выглядело оптимистичней, чем в начале нынешнего. Дот-комы еще не рухнули, небо было выше, трава зеленее, социальные сайты вызывали доверие, а Филдинг еще не защитил диссертацию с названием Representational State Transfer. Что же случилось за десять с небольшим лет и почему идея стандартизации формата электронного документа больше меня не прикалывает? Да ничего важного, просто парадигма интеграции приложений изменилась.

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

Возвращаемся в современность. Если очереди сообщений существовали для того, чтоб безопасно и гарантированно сообщения доставлять, то сервисная шина появилась для того, чтоб обмен сообщениями исключить. И не надо мне рассказывать, что эта самая шина как раз и осуществляет обмен сообщениями. Я это знаю, мы и сами так делаем, только это не очень правильно. Изначальная идея сервисной шины, тем более Enterprise Service Bus (ESB) состоит не в том, чтоб передавать сообщения, а в том, чтоб любое приложение не заботилось о необходимости создания своего локального экземпляра объекта. Смысл сервиса в том, чтоб всегда можно было такой объект получить. Нужен вам документ – вбили URL и методом HTTP GET документ получили и почитали. Захотели документ изменить – по тому же самому URL, методом HTTP PUT документ изменили. POST-ом добавили, DELETE-ом удалили, ну что может быть проще? Присвойте вы документу URL. Воспользуйтесь протоколом в стиле WebDAV чтобы взять документ, поработать и в новом статусе вернуть на его место, то самое, определенное в качестве мастер-копии, т.е. на тот же URL с которого взяли

Иначе – апокалипсис. Квитанции и уведомления об изменении статуса – это еще полбеды. Необходимость одинаково толковать поля документов, а для этого синхронизировать справочники – вот это беда. Третья улица строителей в Москве и 3-я улица строителей в Питере, как это известно из главного новогоднего фильма, далеко не одно и то же. Пожалуй, единственный справочник одинаково трактуемый в разных ведомствах это григорианский календарь. И то, я до конца не уверен. Или другой пример — моё имя в загранпаспорте не совпадает с моим же именем на британской визе, вклеенной в тот же загранпаспорт. В паспорте написано MAXIM, а в визе — MAKSIM. Я из-за этого границу пересекать боюсь 🙂 Прибавим к этому различие наборов состояний документа в разных системах, разные графы переходов, составные документы, включающие в себя набор других документов, электронные конверты и пр. Мы получаем задачу невероятной комбинаторной сложности. А если документ не в одно ведомство пойдет, а сразу в несколько? В одном его исполнят, в другом отвергнут, в третьем – потеряют. Потому процессные человечки очень скоро добавят к этому документу маршрут, лаконично выраженный в нотации BPMN на десятке страниц. Исключения, возвраты, отмены, неверные результаты проверки ЭЦП, недоставленные квитанции, просроченные ключи… Матрица отдыхает (зато программисты продолжают работать)

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