ОБЗОРЫ
На пути новой технологии еще немало серьезных препятствий, но пора уже думать над способами ее использования
Тимоти Дик
Окончание. Начало смотри в PC Week/RE, № 1/2002, с. 16
Внутренние задачи - в первую очередь
Хотя конечной целью внедрения Web-сервисов является объединение разнородных устройств в распределенных сетях, первые исследования областей и способов применения этой архитектуры привели нас к удивительному выводу: самую быструю отдачу дает ее развертывание внутри вычислительной системы организации - например, с целью интеграции СУБД.
“Возможные варианты использования Web-сервисов нашей вычислительной системы достаточно интересны, и мы решили сделать их частью своей общей архитектуры, - рассказывает Санджи Сарати, директор по маркетингу продуктов, аренде приложений и услугам интеграции по направлениям iPlanet в фирме Sun-Netscape Alliance (Санта-Клара, шт. Калифорния). - Путь поэтапного внедрения, начиная с внутренних приложений и с последующим переходом к внешним, привлекателен для очень многих. А внедрять Web-сервисы без плана и системы, произвольными частями то внутри компании, то вне ее очень сложно”. Один из самых трудно преодолимых барьеров на пути организации взаимодействия - пропасть между моделью COM (Component Object Model) корпорации Microsoft, используемой в Windows-приложениях, и объектной моделью JavaBeans (или Enterprise JavaBeans) фирмы Sun - намного легче преодолевается с помощью SOAP.
Для проведения испытаний в Тестовом центре eWeek Labs мы взяли написанное на Java клиентское приложение, предназначенное для обращения по протоколу SOAP к серверному коду, исполняющемуся в среде iPlanet Application Server (в которой поддержка Web-сервисов реализована с использованием инструментария Apache SOAP группы Apache). После внесения небольших изменений это приложение стало обращаться уже к исполняющемуся на Windows-системе компоненту, специально написанному нами на языке C# .Net корпорации Microsoft. (Сравнительные характеристики языков программирования Си++, Java и C# приведены в таблице.)
Усилия по созданию архитектур распределенных вычислений предпринимались и раньше. Одной из наиболее известных является CORBA (Common Object Request Broker Architecture - общая архитектура посредника запросов к объектам) организации Object Management Group. “Проблема CORBA была в том, что ее пытались сделать всеобъемлющей, - комментирует главный идеолог фирмы Lutris Technologies (Санта-Крус, шт. Калифорния) Дэвид Янг. (Он участвовал в группе по стандартизации X/Open в начале 1990-х - в годы самой активной деятельности по разработке CORBA.) - Мы хотели выпить море и пересчитать звезды, сделать все для всех и лучше всех. SOAP опирается на значительно более простую концепцию независимости от реализации. Этот протокол, безусловно, является ключом к созданию нового, прекрасного совместимого мира”.
На плечах SOAP
SOAP должен обладать феноменально широкими - в особенности для протокола, которому не более двух лет от роду, - плечами, чтобы вынести на них все, что было от его имени наобещано. И все же быстрота и широта распространения SOAP и связанных с ним технологий поражают. На Web-узле www.soapware.org приводится список из 71 пакета ПО, уже обеспеченных поддержкой этого протокола, а еще во многие такая поддержка в настоящее время встраивается.
Кроме того, стремительно появляются все новые компоненты необходимой мета-инфраструктуры - такие, как Web-каталоги доступных служб, предлагаемые стандарты шифрования, цифровой подписи и маршрутизации сообщений. Информация о существующих службах содержится в каталогах стандарта Universal, Description, Discovery Integration (UDDI), размещенных на своих узлах корпорациями Microsoft и IBM. А вскоре их примеру последуют и другие компании.
В ближайшие два-три года можно ожидать появления гибкой модели взаимодействия приложений с источниками данных и проведения транзакций. Хорошо определенные интерфейсы, основанные на легко модифицируемом XML-коде, в сочетании с внешними и внутренними каталогами служб позволят разработчикам не тратить время на изобретение программного колеса.
С техническим директором Тестового центра eWeek Labs по Западному побережью
Тимоти Диком можно связаться по адресу: timothy_dyck@ziffdavis.com.
Ключ к Web-сервисам - языки программирования, ориентированные на создание компонентных приложений
Идеолог языков программирования из корпорации Microsoft Андерс Хейлсберг охарактеризовал C# (“си шарп”) как “первый настоящий компонентно-ориентированный язык программирования в семействе Си/Си++”. Он также уверен, что модель программирования, основанная на компонентах с ассоциированными с ними данными (соответствуют свойствам, properties, в некоторых других языках) и вариантами поведения (соответствуют событиям, events), поддерживается в C# более естественно, чем в Java. “Java эмулирует свойства с использованием специальной схемы именования методов доступа, - говорит Хейлсберг, - а обработчики событий - с помощью различных “переходников” и связующего кода”. Он согласен с тем, что и Java, и Си++ также поддерживают компонентно-ориентированный стиль программирования, но считает, что “компоненты в них не обладают гражданством первого класса”. Проиллюстрировать это его высказывание можно, например, следующим обстоятельством: в C# такие простые операции, как замена текста на экранной кнопке, описываются через более простой синтаксис и меньшее число строк кода, поскольку кнопка является компонентом и сама определяет свой внешний вид и поведение. Компонентная ориентированность, по словам Хейлсберга, позволяет разработчикам встраивать свои приложения в любую из целого ряда сред, пользователям которых могут понадобиться Web-сервисы. Ниже приведены сравнительные характеристики языков программирования Си++, Java и C#.
