Влияние исследований на технологию промежуточного программного обеспечения

Вольфганг Эммерих, Микио Аояма, Джо Свентек
Перевод: Сергей Кузнецов

Назад Содержание Вперёд

6. Промежуточное программное обеспечение, ориентированное на сообщения

Промежуточное программное обеспечение, ориентированное на сообщения (message-oriented middleware, MOM), поддерживает асинхронные коммуникации между компонентами распределенных систем. Это очень важный примитив, используемый в большинстве современных серверов приложений и корпоративных сервисных шин (enterprise services bus). В J2EE имеется спецификация JMS [64]. Эта спецификация хорошо интегрирована с другими спецификациями J2EE. В частности, в спецификациях EJB, начиная в версии 1.2, определяется понятие компонентов «message beans», которые могут быть сконфигурированы таким образом, что будут вызываться при получении сообщения через JMS.

В соответствии с [39], объем рынка лицензий на продукты категории MOM в 2005 г. составил миллиард долларов США, и крупнейшими поставщиками MOM являлись IBM с долей рынка в 500 миллионов США и TIBCO с долей рынка в 314 миллиона долларов США. Это составляет заметную часть всего рынка промежуточного программного обеспечения. Во время написания этой статьи наиболее значительными продуктами MOM являлись Websphere MQ компании IBM, MessageQ компании BEA, TIB/Rendevous компании Tibco, SonicMQ компании Sonic, MSMQ компании Microsoft, а также ряд продуктов с открытыми кодами, такие как JBoss Message Queue. Эти продукты как продаются изолированно, так и встраиваются в серверы приложений и корпоративные сервисные шины.

Важным событием, повлиявшим на признание рынка MOM, явилась публикация спецификации JMS, созданной организацией Java Community Process. Целью этой спецификации является обеспечение единообразного API для всех ведущих поставщиков MOM. В JMS поддерживаются как двухточечные коммуникации, так и коммуникации в стиле «публикация/подписка». Поддерживаются различные варианты качества обслуживания, такие как гарантированная доставка на основе персистентного хранения сообщений при недоступности получателей. Эти понятия были придуманы не комитетом, создававшим спецификацию JMS; они использовались в продуктах MOM за многие годы до этого. Обзор различных подходов к организации MOM, включая подходы, не завоевавшие значительного коммерческого успеха, приводится в [51]. В оставшейся части этого раздела мы исследуем происхождение ключевых понятий коммерчески успешных систем [51]. Общая картина трасс воздействия в области MOM показана на рис. 12.

Рис. 12. Воздействия на реализации JMS (увеличить)

Наибольшую долю рынка продуктов MOM занимает продукт Websphere MQ компании IBM, называвшийся ранее MQSeries [72]. Продукт MQSeries был успешным по ряду причин. Во-первых, в нем интегрировались примитивы обмена сообщениями с обработкой транзакций за счет того, что в этом промежуточном программном обеспечении поддерживался протокол OpenGroup XA, являющийся частью стандарта ODTP. Трактовка очереди сообщений как менеджера ресурсов, поддерживающего XA, позволяла программистам приложений вставлять сообщение в очередь или извлекать его из очереди в рамках распределенной транзакции, в которой можно было выполнять и операции с базами данных для обработки посланного или полученного сообщения. Во-вторых, MQSeries можно было использовать в среде более 30 операционных систем и аппаратных платформ, и между платформами был возможен надежный обмен сообщениями с использованием одних и тех же примитивов.

Созданию MQSeries как системы очередей двухточечных сообщений способствовал банк State Street Bank в Бостоне, которому потребовалось интегрировать продукт EzBridge компании System Strategies International (SSI) с абстракциями интерфейса MQI (Message Queue Interface), определенного в стандарте IBM Networking Blueprint [69]. Для удовлетворения этих потребностей в IBM UK Laboratories в Херсли, откуда происходит продукт CICS, были приобретены лицензии на программное обеспечение ezBridge для Tandem и VMS, оно было снабжено интерфейсами MQI, сделано совместимым с протоколом XA и интегрировано с собственной реализацией MQI, доступной для платформы CICS. Мы интервьюировали Дика Дивендорфа (Dick Dievendorff), одного из архитекторов MQSeries. Дивендорф утверждал, что группа MQSeries для преодоления неоднозначности двухфазного протокола фиксации использовала идеи прямого восстановления. Он упомянул, что в его группе использовались методы прямого восстановления, описанные в статье [121], которая была опубликована в трудах конференции VLDB 1989 г. В 1999 г. эта статья была признана наиболее влиятельной статьей десятилетия. Доказательство приводится в статье Мохана (C. Mohan) [154], дополняющей его выступление по поводу вручения награды VLDB. В этой статье говорится: «Стала достаточно популярной асинхронная коммуникация программ в форме транзакционного обмена персистентными сообщениями. Успешным продуктом в этой области является, например, MQSeries компании IBM. В MQSeries для управления сообщениями применяется собственный, не основанный на СУБД механизм персистентного хранения с использованием расширенной версии ARIES». Вдобавок к использованию статьи [121], Мохан был привлечен в группу Дивендорфа в качестве консультанта для содействия в реализации этих механизмов восстановления в MQSeries. Дивендорф также утверждает, что исходные идеи MQSeries происходят от DEC Message Queue. Он говорит, что «DEC опережала нас на два года, но они опубликовали все свои ключевые идеи в техническом отчете, что позволило нам наверстать упущенное». IBM MQSeries являлся не единственным продуктом MOM, на который оказал воздействие продукт DEC Message Queue.

В июне 2005 г. в интервью, данном Полу Криллу (Paul Krill) из издания InfoWorld, Пол Патрик (Paul Patrick) из компании BEA Systems подтвердил, что BEA приобрела продукты DEC ObjectBroker (CORBA ORB) и MessageQueue, после чего произвела реижениринг ObjectBroker для своей реализации CORBA Web Logic Enterprise (WLE). В продукте WLE служба транзакций была реализована на основе монитора транзакций Tuxedo, обсуждавшегося в предыдущем разделе. Служба CORBA Notification Service [109] реализовывалась в продукте WLE путем построения «обертки» вокруг BEA MessageQ. Пример приложения, построенного с использованием служб транзакций и нотификации WLE, описывается в [49]. До внедрения MessageQ в продукт WLE компания BEA продавала MessageQ отдельно и встраивала этот продукт в свой монитор транзакций Tuxedo.

Но откуда же происходят примитивы обмена сообщениями, использовавшиеся в продукте DEC MessageQueue? У компании DEC имелся более ранний продукт DEC Fuse. В DEC Fuse использовались методы синхронных и асинхронных коммуникаций для поддержки интеграции инструментальных средств инженерии программного обеспечения. Система Fuse основывалась на коде, лицензированном компанией DEC у Стивена Рейса, который разработал механизм интеграции на базе передачи сообщений для среды разработки программного обеспечения Field [120]. В статье [65], описывающей Fuse, говорится, что «код Fuse был основан на коде Field». На самом деле, продукты интеграции инструментальных средств ToolTalk компании Sun и Broadcast Message Server компании Hewlett Packard также основывались на концепциях Field. В статье Мартина Кагана (Martin Cagan) [28], посвященной продукту SoftBench компании Hewlett Packard, говорится, что «наибольшее влияние на разработку SoftBench оказали система Field, созданная в Brown University, система FSD, сделанная в USC-ISI (University of Southern California-Information Sciences Institute), и среда HP NewWave». В своей статье по поводу Field Каган ссылается на технический отчет Brown University за 1987 г. [119], а в связи с FSD – на [13]. В своем интервью Стивен Рейс подтвердил, что узнал про Field в ходе своего пребывания в Brown University, и что он лицензировал код Field для его включения в Fuse. Кроме того, он подтвердил, что система Fuse была предшественицей DEC Message Queue.

Интересно заметить, что служба CORBA Event Service [108], важный предшественник CORBA Notification Service, была определена консорциумом, во главе которого стояли компании Sun, DEC и HP. Однако остается неясно, оказали ли воздействие на эту разработку предыдущие работы компаний Sun, DEC и HP над механизмами интеграции инструментальных средств Tooltalk, Fuse и Broadcast Message Server соответственно. Кроме того, в рабочей группе, которая определила CORBA Event Service, участвовал Дейл Скин из компании Teknekron. До этого Скин работал в Teknekron над продуктом The Information Broker [130]. В действительности, в статье [107], опубликованной в трудах конференции ACM SIGOPS Principles of Operating Systems в 1993 г., описывается механизм публикации/подписки, очень похожий на тот, который использовался в CORBA Event Service. При обсуждении родственных работ в этой статье утверждается, что к объектам были применены идеи, предложенные в [32] для организации многоадресного режима в сетях (multicast networking) и в [19] для построения менеджера репликаций ISIS. После поглощения компании Teknekron компанией Reuters она была переименована в Tibco, и о The Information Broker теперь напоминает только акроним TIB. Как уже отмечалось, Tibco обладает второй по объему долей рынка MOM.

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

Назад Содержание Вперёд