Logo Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
Конференция «Технологии управления данными 2018»
СУБД, платформы, инструменты, реальные проекты.
29 ноября 2018 г.
2007 г.

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

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

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

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.

Новости мира IT:

Архив новостей

Последние комментарии:

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
тел. +7 985 1945361
Пресс-релизы — pr@citforum.ru
Обратная связь
Информация для авторов
Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2015 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...