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

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

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

4. Промежуточное программное обеспечение для сервис-ориентированного компьютинга

Со времени своего возникновения в 2000 г. технологии Web-сервисов развивались с удивительной скоростью. Ряд спецификаций, относящихся к Web-сервисам и сервис-ориентированным архитектурам (Service Oriented Architecture, SOA), уже стандартизован, и еще большее число спецификаций находится в стадии разработки. Поскольку Web-сервисы – это платформенная технология, они оказывают гигантское влияние на практику разработки программного обеспечения. Хорошее введение в технологию Web-сервисов обеспечивается в [148].

Ключевыми технологиями, лежащими в основе любых Web-сервисов, являются Simple Object Access Protocol (SOAP) [26, 62], Web Services Description Language (WSDL) [36, 35] и Business Process Execution Language (BPEL) [6]. На этих технологиях основываются большинство корпоративных сервис-ориентированных архитектур. Отследим происхождение этих технологий промежуточного программного обеспечения, но сначала кратко охарактеризуем их актуальность.

Появление в 2000 г. технологий SOAP и WSDL немедленно вызвало энтузиазм. Однако, поскольку по своей природе они являлись платформенными технологиями, потребовалось несколько лет для разработки вспомогательных технологий, таких как объемистые спецификации Service Security [101], а также для получения технической зрелости и опыта для разработки распределенных приложений с использованием Web-сервисов. Современные Web-сервисы обеспечивают универсальную и общепринятую инфраструктуру для построения распределенных систем. Такая инфраструктура является незаменимой для межкорпоративной интеграции приложений.

Web-сервисы теперь реализуются во всех продуктах серверов приложений, включая Microsoft BizTalk, Web Logic Server компании BEA, Websphere компании IBM, Oracle Application Server, JBoss и различные другие продукты категории open source. Результирующее воздействие Web-сервисов является гигантским. По данным компании Forrester Research, около 50% крупных предприятий уже использует SOA или будет использовать ее до конца 2006 г. [67]. Следует заметить, что технологии Web-сервисов являются не только вычислительной платформой. Они начинают изменять бизнес-модель программного обеспечения от ориентации на продажу программного обеспечения на ориентацию на продажу услуг через Web, а также и способ развития бизнеса. Поэтому воздействие Web-сервисов и SOA выходит за пределы [63, 18]. Обсудим теперь происхождение основных спецификаций, образующих основу технологии Web-сервисов.

4.1. Simple Object Access Protocol

SOAP – это стандартный формат сообщений, основанный на eXtensible Markup Language (XML). SOAP обеспечивает механизм для представления вызова объекта и его результата в XML-сообщениях, которые затем передаются с использованием основного сетевого транспортного протокола, такого как HTTP или SMTP. Таким образом, SOAP является независимым от транспортных протоколов. SOAP поддерживает два стиля передачи сообщений: RPC и документально-литеральный. На рис. 6 показаны трассы воздействий, которые привели к определению SOAP.

Рис. 6. Воздействия на определение SOAP

SOAP часто реализуется в Web-сервере или Web-контейнере, к числу которых относятся Apache Axis и Microsoft IIS (Internet Information Services). Серверы приложений, обеспечивающие прямую поддержку SOAP, включают BEA Web Logic Server, Fujitsu Interstage Application Server, IBM WebSphere Application Server, IONA Artix и Microsoft BizTalk Server. Инструментарий для обработки SOAP-сообщений включает инструментальный комплект Apache, доступный на Java и C++, IBM Web Services Toolkit и Microsoft SOAP Toolkit. Имеется также несколько SOAP-процессоров с открытым кодом, реализованных на языках Perl, PHP и Ruby.

В настоящее время действует и широко используется спецификация SOAP 1.2, принятая в качестве рекомендации консорциума World-Wide-Web в июне 2003 г. Разработка SOAP началась в 1998 г., и с тех пор спецификация подвергалась ряду изменений. Эволюция спецификации SOAP засвидетельствована в [25] первым автором исходной заметки по поводу SOAP, опубликованной World-Wide-Web. В этом отчете Дон Бокс, по существу, утверждает, что SOAP происходит непосредственно из ранних протоколов RPC, отмечая, что «мы посмотрели на существующие форматы сериализации (ASN.1 BER, NDR, XDR, CDR, JRMP) и протоколы RPC (GIOP/IIOP, DCE/DCOM, RMI, ONC) и постарались найти ‘лакомый кусочек’, который полностью бы удовлетворял нас в 80% случаев и мог бы быть как-то применен в оставшихся 20% случаев». Таким образом, Бокс утверждает, что SOAP был создан под влиянием и на основе технологий вызовов удаленных процедур и распределенных объектов. В разд. 7 и 8 мы обсудим происхождение этих технологий.

В SOAP используется XML [27] для кодировки данных запросов и ответов, передаваемых между клиентом и сервером при обработке вызова Web-сервиса. В начале работы над SOAP язык для определения системы типов XML был не слишком хорошо развит. В частности, в XML отсутствовали язык определения схем и спецификация XML Schema, используемые в окончательном варианте SOAP для определения типов данных. Окончательная спецификация XML Schema появилась только в 2004 г. [22]. Отсутствие языка определения схем для XML несколько задержало процесс стандартизации SOAP, и была быстро определена и принята промежуточная спецификация XML/RPC [149]. В своем окончательном варианте SOAP поддерживает как вызовы в стиле RPC в соответствии с предложениями, изложенными в [149], так и документально-литеральные вызовы, при выполнении которых передаются типизированные XML-сообщения, в которых кодируются данные запроса и ответа.

Консорциумом World-Wide-Web было принято семейство спецификаций XML, включающее спецификации самого языка XML [27], XML Schema [22] и XPath [37]. XML образует основу для SOAP, WSDL и BPEL. XML происходит из стандартизованного ISO языка SGML (Standardized General Markup Language) [73]. SGML был определен той же группой, которая разрабатывала GML (General Markup Language) компании IBM [58], работа над которым была начата в Кэмриджском научном центре IBM в MIT. В [58] признается, что понятие процедурной разметки (procedural markup) было введено в работе [118], посвященной системе обработки документов Scribe. Полностью система Scribe описывалась в [117]. Центральной идеей GML, сохранившейся в SGML и XML, являлось строгое разделение аспектов содержания и представления. Разделение аспектов не является особым новшеством для специалистов по разработке программного обеспечения, и поэтому не удивительно, что Голдфарб использовал в [58] в качестве практического примера применения GML технологический процесс подготовки учебника Клиффа Джонса (Cliff Jones) по инженерии программного обеспечения [75].

4.2. Web Services Description Language

WSDL обеспечивает языковые абстракции для определения интерфейсов Web-сервисов. В нем поддерживается идентификация типов портов (port-type), которые соответствуют модулям или типам в других IDL, идентификация операций и сигнатур операций. Обсудим теперь происхождение WSDL. Трассы воздействий, приведших к возникновению WSDL, показаны на рис. 7.

Рис. 7. Воздействия на определение WSDL

WSDL поддерживается во многих серверах приложений и средах разработки приложений. В Apache Axis обеспечивается генератор двунаправленных посредников между Java/C++ и WSDL. Большинство серверов приложений оснащается инструментальными средствами разработки Web-сервисов. Продукт IBM Rational Application Developer for WebSphere генерирует WSDL-документ на основе существующих приложений и Java-посредников на основе WSDL-документа. Microsoft Visual Studio генерирует посредников для .NET Framework на основе WSDL-документа. К числу других инструментальных средств относятся Workshop for WebLogic Platform компании BEA, Interstage Apworks компании Fujitsu и Artix компании IONA.

В марте 2001 г. компании Ariba, Microsoft и IBM совместно представили в W3C записку с определением Web Services Description Language [36]. В записке говорилось, что «в этом наброске представлены текущие соображения по поводу описаний сервисов в продуктах компаний Ariba, IBM и Microsoft. В документе объединяются понятия, заложенные в NASSL, SCL и SDL (предыдущих предложениях в данной области)».

Язык NASSL (Network Accessible Service Specification Language) был определен группой компонентных систем в IBM Research [41]. В техническом отчете [41] говорится, что «языки, подобные MS IDL и OMG IDL, являются популярными промышленными стандартами, используемыми для описания интерфейсов RPC. Вместо того чтобы вводить совсем другой язык, для NASSL заимствуются ключевые понятия из этих языков, и они приспосабливаются для распространения на сервисы, не относящиеся к категории RPC». К числу примеров понятий, попавших в NASSL и WSDL из языков определения интерфейсов компании Microsoft и консорциума OMG, относятся однонаправленные операции (oneway operation), семантика отказов и строгая типизация. Происхождение MS IDL и OMG IDL мы определим в разд. 7 и 8. Наиболее значительный вклад самого технического отчета по поводу NASSL состоит в предложении использовать другие системы типов, основанные на XML-схемах, для определения типов параметров и результатов Web-сервисов, которое, в конце концов, было принято для WSDL.

SOAP Contract Language (SCL) и Service Description Language (SDL) были определены компанией Microsoft в 1999-2000 гг.^* для поддержки модели удаленных вызовов для Component Object Model (COM) компании Microsoft, основанной на понятии Web-сервисов. Язык SDL относительно широко использовался, и его определение распространялось как часть инструментария Microsoft SOAP. Жизнь SCL длилась относительно недолго, и этот язык был довольно быстро вытеснен WSDL. Основное воздействие SDL от Microsoft на WSDL и современные Web-сервисы заключалось в возможности использования различных правил привязки для используемых транспортных протоколов. В документе по поводу SDL приводятся примеры использования в DCOM HTTP, HTTPS и варианта RPC от Microsoft.

WSDL, NASSL, SDL и SCL основаны на языке XML. Первое предложение по использованию XML для представления языка определения интерфейсов для Web-сервисов появилось в записке с предложением языка Web Interface Definition Language (WIDL), опубликованной консорциумом World-Wide-Web [93]. Хотя мы не можем представить прямых доказательств того, что в WSDL, NASSL, SDL и SCL эта идея позаимствована из WIDL, по ряду причин это кажется весьма вероятным. Во-первых, определения WSDL, NASSL, SDL и SCL появились в то время, когда Microsoft и IBM очень активно участвовали в Рабочей группе по протоколам консорциума World-Wide-Web. Во-вторых, язык WIDL был представлен в виде записки в консорциум World-Wide-Web в 1997 г. Наконец, что наиболее важно, Рабочая группа по протоколам XML, которая в итоге приняла WSDL, в 2000 г. опубликовала матрицу, в которой сравнивались различные подходы к определению Web-сервисов [115]. Среди прочих языков в матрице сравниваются WIDL, WSDL, NASSL и SCL, и это означает, что разработчики языка WSDL были осведомлены о языке WIDL.

4.3. Business Process Execution Language

В [114] определяются две модели компоновки Web-сервисов: оркестровка (orchestration) и хореография (choreography). Основное различие между этими моделями состоит в области действия компоновки. В то время как в оркестрованных Web-сервисах учитывается поток управления с точки зрения одного участника, при хореографии подчеркивается сотрудничество всех участников и охватывается область действия всех участников и их взаимодействий с глобальной, системной точки зрения. BPEL предназначается для оркестровки Web-сервисов на основе некоторого бизнес-процесса. На рис. 8 показана диаграмма трасс воздействий, приведших к появлению BPEL.

Рис. 8. Воздействия на определение BPEL

Имеется значительное число реализаций BPEL. IBM разработала BPEL4J (Business Process Execution Language for Web Services Java Run Time). В Microsoft BizTalk Server 2004 WS-BPEL транслируется в XLANG/s, а затем, для лучшей производительности, в сборочные модули .NET (.NET assemblies) с поддержанием обратной совместимости с предыдущими версиями серверов BizTalk [52]. Компания Oracle приобрела компанию Collaxa и встроила ее пакет программ для BPEL в свой продукт BPEL Process Manager, который может использоваться самостоятельно или в качестве необязательного компонента Oracle Application Server Enterprise Edition. Имеется ряд процессоров BPEL с открытыми кодами от компаний Active Endpoints, RedHat/JBoss и Apache. Поддержка графического моделирования BPEL по лицензии open source доступна благодаря проекту Eclipse BPEL Designer, совместно поддерживаемого IBM, Oracle и UCL (University College London).

Первая спецификация BPEL под названием BPEL4WS (Business Process Execution Language for Web Services) была опубликована IBM и Microsoft в августе 2002 г. В спецификации BPEL4WS утверждалось, что в этом языке объединяются два более ранних языка, разработанные, соответственно, IBM и Microsoft: Web Services Flow Language (WSFL) от IBM [81] и XLANG от Microsoft [145], использовавшийся в продуктах семейства BizTalk Server.

Язык WSFL возник на основе более ранней работы IBM над языком FlowMark [83, 82]. В исследовательском отчете IBM Almaden [3] утверждается соответствие FlowMark стандарту консорциума Workflow Management Coalition (WfMC): «FlowMark очень близко следует эталонной модели WfMC». Еще одним доказательством полной осведомленности группы разработчиков FlowMark о работах WfMC является тот факт, что один из основных разработчиков FlowMark Вольфганг Альтенхубер (Wolfgang Altenhuber) являлся членом технического комитета WfMC.

Одним из ключевых артефактов консорциума WfMC является его эталонная модель [70]. Спецификация этой модели не включает каких-либо ссылок, но в ней утверждается, что, помимо прочего, эталонная модель происходит от «программного обеспечения поддержки проектов» («Project Support Software»). Далее говорится: «Программное обеспечение для управления проектами сложных IT-приложений (например, интегрированные среды поддержки проектов – Integrated Project Support Environments, IPSE) часто поддерживает некоторую разновидность функциональности потоков работ в среде проекта для «передачи» задач разработки между участниками проекта и маршрутизации информации между участниками для поддержки этих задач». Если бы эталонная модель была описана в какой-либо академической публикации, в ней присутствовали бы ссылки на обширные литературные источники, посвященные процессоцентричным средам разработки программного обеспечения, такие как [14].

В [92] предлагается формальное определение поведенческих аспектов BPEL с использованием многоместного π-исчисления [96]. В соответствии с [84] этот подход уже использовался в XLANG: «Наше использование ориентированных графов для моделирования потоков похоже на работы WfMC или на язык Web Services Conversation Language. Теоретическое обоснование этого подхода базируется на сетях Петри и π-исчислении. XLANG и BPML более близки к последнему формализму».

4.4. Резюме

Тремя ключевыми технологиями Web-сервисов, позволяющими конструировать сервис-ориентированные архитектуры, являются SOAP, WSDL и BPEL. Мы показали, что они реализованы во многих сервис-ориентированных системах промежуточного программного обеспечения. В этих технологиях Web-сервисов используются технологии XML для определения содержимого сообщений вызовов сервисов, интерфейсов Web-сервисов и для спецификации компоновки Web-сервисов. Мы отследили происхождение технологий XML от разработки языка GML в Кэмбриджской лаборатории IBM, базировавшейся в MIT. Мы показали, что ключевые понятия, используемые в Web-сервисах, не являются новыми, а скорее позаимствованы из систем удаленных вызовов процедур, распределенных объектов и управления потоками работ.

Сервис-ориентированные архитектуры часто наслаиваются на распределенные компонентные системы, такие как Java 2 Enterprise Edition (J2EE). Эти компонентные системы обеспечивают контейнеры компонентов, которые обычно являются распределенными только в локальной сети. В контейнерах поддерживаются механизмы персистентного хранения состояния компонентов, репликации, управления параллелизмом, активации и дезактивизации компонентов, безопасности и управления транзакциями. В следующем разделе мы обсудим происхождение средств обработки распределенных транзакций в таких распределенных компонентных системах.

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

---

* Заметим, что один и тот же акроним используется для совершенно разных понятий. Service Description Language компании Microsoft в корне отличается от принятого в качестве стандарта ISO/IEC языка Specification and Description Language, и его также не следует путать с Security Development Lifecycle той же компании Microsoft.