В стремительном процессе эволюции компьютерных технологий иногда совершенно неожиданно раскрываются новые возможности старых идей. Например, такой, как, казалось бы, давно забытая память на ферритовых сердечниках. При всех недостатках ее положительным качеством была способность запоминать и сохранять данные бесконечно долго без подпитки — в отличие от современных модулей 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. О происходящем на этом фронте можно прочитать в [1], а более подробно о SonicMQ, непосредственном предшественнике SonicXQ, — в [2]. Обе эти публикации сохраняют актуальность, но за прошедший год пейзаж корпоративного программного обеспечения заметно изменился, особенно под воздействием Web-служб. Еще год назад, когда готовились указанные публикации, представление о том, что такое Web-службы и каково их значение, было достаточно расплывчатым. За прошедшее время ситуация заметно прояснилась, и Web-службы следует назвать в качестве второго источника SonicXQ.
Enterprise Service Bus
Среди событий прошедшего года следует отметить появление в профессиональной терминологии нечто нового и непривычного. Одни, приверженцы лагеря Micrososft/IBM, называют это «оркестровкой» (orchestration) Web-служб, другие, из лагеря Sun/BEA, — «хореографией» (choreography) [3]. Разгорается очередная битва в войне стандартов, за то, как лучше наладить согласованную работу корпоративных приложений с использованием Web-служб. Причина новой активности заключена в том, что всем, наконец, стало ясно: в сложившихся условиях исчерпаны возможности жестко связанных приложений, сложность систем стала слишком велика. Однако исходная схема распространения Web-служб с использованием построенных по стандарту UDDI репозиториев оказалась малоприменимой для корпоративных целей. В то же время, Web-службы и особенно их асинхронные ориентированные на документы версии предлагают реальный выход из «тупика сложности». С технической точки задача создания корпоративной инфраструктуры приложений с использованием слабосвязанных асинхронных процессов имеет несколько альтернативных решений.
Enterprise Service Bus, построенная на основе SonicXQ является одним из них. С помощью формируемой SonicXQ корпоративной магистрали реализуется распределенная архитектура, ориентированная на службы. ESB позволяет создавать контейнеры для размещения служб. Службы легко собрать и согласовать, поскольку упакованная в контейнер и являющаяся частью ESB служба представима другим частям ESB. При этом вся конструкция является виртуальной; реальная физическая сеть, в которой она «живет», может подвергаться изменениям без потери функциональности.
 |
| Рис. 1. Enterprise Service Bus — информационная магистраль предприятия |
В процессе функционирования 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. Леонид Черняк. МОМ, второе рождение // Открытые системы, 2001, № 1
2. Валерий Коржов. Почтальон для приложений // Открытые системы, 2001, № 10
3. Stuart J. Johnston, Web Services Wars Take Artistic Turn. Choreography or orchestration? XML Magazine, 2002, № 10/11
