Необходимость Web-служб

Для каждой вновь появляющейся технологии один из самых распространенных признаков перспективности — частота упоминания в СМИ, в конференциях и т.д. По этому показателю концепция Web-служб может быть и не лидирует, но именно ее появление позволяет по-новому взглянуть на экономику информационных технологий.

Web-службы — новый способ общения информационных систем, позволяющий взаимодействовать приложениям, построенным на различных платформах, содержащих в себе непохожие и даже целиком различные технологии и стандарты. Появление новых технологий — дело обычное, появление технологий, рождающих спрос — редкая удача. Нечто подобное, похоже, происходит сейчас с Web-службами — предпосылки есть, технология появляется, дело за рынком — ответит ли он спросом или нет.

Сейчас все говорят о кризисе «новой экономики» и чуть ли не всей компьютерной индустрии в целом. Конечно, шумихи в этом куда больше, чем здорового анализа, но нужно признать оправданным беспокойство бизнеса возвратом инвестиций в информационную индустрию. Анализ причин низкой отдачи от ИТ — тема отдельного разговора, но нельзя не отметить, что одна из причин этого — отсутствие целостности и последовательности инвестирования в ИТ. Представьте, что происходило бы столетие с лишним назад, когда наиболее перспективным направлением развития был железнодорожный транспорт, если бы каждый завод или фабрика строили бы собственные ветки, покупали бы для них паровозы и вагоны. Говоря современным языком, корпоративные железные дороги были бы несовместимы. Возникло бы не меньшее разочарование в новой технологии, чем сейчас. А ведь ситуации очень схожи.

Что представляет собой современный бизнес-процесс, распределенный по нескольким организациям? Это люди, общающиеся между собой, пусть и по современным каналам передачи информации. Любой бизнес — общение, но и когда бизнес-процесс предельно отлажен и представляется хорошо структурированной последовательностью шагов, каждый этот шаг осуществляется человеком. Человек берет на себя не интеллектуальную составляющую — создание, отладку и контроль, а рутинную роль интерфейса.

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

История Сети

Предпосылки появления технологии Web-служб вытекают также и из истории публичных сетей и Internet, прошедших в своем развитии несколько стадий (рис. 1).

Рис. 1. Три этапа развития Internet

Сначала Internet соединила людей и при этом создание какого-либо средства публичного доступа было затруднено. Эти ограничения обходились с помощью онлайновых архивов, массовых рассылок и т.д. Но существовавшие на тот момент технологии не позволяли создать настоящее средство массовой информации.

Следующим шагом стало появление Web, благодаря которой появилась возможность создания собственных средств публичного доступа. Но найти необходимую информацию в Internet очень сложно, а использовать Сеть может только человек — написать программу, сканирующую Web-страницу в поисках необходимой информации сложно. Любое решение, подразумевающее взаимодействие с помощью Web, предполагает участие человека. Web — средство общения людей, но не компьютерных систем. Одновременно лежащий в основе Web протокол HTTP, а также почтовый протокол SMTP стали практически единственными средствами транспортировки информации в Internet. Все остальные транспортные протоколы закрыты различными средствами безопасности (в том числе, межсетевыми экранами).

Следующий шаг — появление технологии, связывающей между собой информационные системы посредством Web. И сейчас, с рождением Web-служб, происходит переход от Web как средства представления информации к Web как среде программирования.

Инфраструктура

Другой предпосылкой стала сложившаяся инфраструктура, те самые «железные дороги» Internet. Да, TCP/IP сейчас есть везде, и этот стек протоколов достаточно удобен для организации программного взаимодействия, но... попробуйте развить хоть какую-нибудь технологию, использующую в качестве транспорта протокол TCP/IP, что из этого получится? В лучшем случае новый протокол будет работать в пределах локальной сети, а выходить за ее пределы ему помешают повсеместно используемые фильтры и прокси-серверы с закрытыми портами, запрещающими любой трафик, кроме стандартных и безопасных HTTP и SMTP, а также еще очень небольшого числа стандартных протоколов.

В качестве транспорта для «публичной» технологии может выступать не TCP/IP, а только HTTP, со всеми его минусами в виде односторонней активности и синхронности (только клиент может спрашивать о чем-нибудь сервер, сервер же клиенту по собственной инициативе не может сообщить ничего), ненадежности и небольшого набора команд. В плюсах — лишь популярность и простота.

Однако по-настоящему широко распространенная технология должна быть независима от транспорта, допускать возможность общения по любому или почти по любому из транспортных протоколов Internet. Но выбор транспорта — только половина дела. Большое значение имеет выбор способа упаковки транспортируемой информации. Традиционная индустрия транспортных перевозок заходила в тупик при транспортировке нестандартных грузов — разнокалиберных ящиков, коробок, тюков и т.д., пока не были изобретены контейнеры. В компьютерном мире таким средством стал XML.

От монолитных систем к компонентам

В развитии технологий создания информационных систем можно проследить переход от монолитных приложений к приложениям, разделенным на модули, а затем и к компонентным приложениям (рис. 2). Именно тогда появилась «многоуровневая модель», в которой приложение разбивается на несколько слоев — доступа к данным, бизнес-логики, логики представления и пользовательского интерфейса. При этом уже не существует приложения, которое не обеспечивало бы доступ к своим функциям через программные интерфейсы — сразу на уровень бизнес-логики, минуя слои пользовательского интерфейса и представления.

Рис. 2. От монолитных приложений к компонентным

Увы, Web-технологии, которые создавались уже после появления многоуровневых моделей и стандартов открытых систем, не обошли те же самые «грабли» с монолитными приложениями. Преодоление этого состоит в применении Web-служб.

Web-службы

Web-службы — не только бизнес-инициатива, но и технологии, лежащие в их основе, еще один способ осуществления распределенных программных вызовов. Исторически такие технологии называются собирательным термином Remote Procedure Call (RPC). «Удаленный вызов процедур» состоит из двух одинаково важных частей: транспорта, обеспечивающего доставку информации и способа упаковки передаваемой информации. Некоторые средства удаленного вызова, например механизм DCOM, предоставляют дополнительные службы наподобие контроля ссылок и обеспечения безопасности, но основа везде одна и та же. Также существуют добавки, позволяющие удаленно вызывать не просто функции, но и указывать объектные ссылки — идентификаторы удаленных объектов, которым они принадлежат. Основными используемыми на данный момент технологиями такого рода являются: RPC, используемый в модели DCOM; CORBA IIOP (Internet Inter-ORB Protocol); Java RMI (Remote Method Invocation).

Все эти способы удаленного взаимодействия несовместимы друг с другом. В качестве транспорта в них используется, как правило, только ограниченный набор сетевых транспортных протоколов (таких, как TCP/IP и NetBEUI или SPX/IPX) с нестандартными портами, что делает невозможным их применение в Internet. Способ упаковки информации у всех этих протоколов двоичен и неспецифицирован, что сильно затрудняет их реализацию для разных платформ. Не существует и открытого и стандартного способа описания предоставляемой для удаленного использования функциональности.

В основе технологии Web-служб и лежит протокол SOAP (Simple Object Access Protocol — «Простой Протокол Доступа к Объектам»), основанный на произвольном транспортном протоколе и использующий в качестве способа представления информации XML. В нем учтены многие недостатки его предшественников (ORPC, IIOP и RMI), например, гораздо подробнее и точнее специфицированы транспорт и способ упаковки информации, а также способ описания предоставляемой функциональности. Стандартизация делает SOAP действительно всеобщим и открытым способом общения распределенных информационных систем. В то же время нельзя рассматривать SOAP как замену всех предыдущих способов удаленного взаимодействия — предназначение его несколько иное. Если DCOM, CORBA и RMI — это средства общения гомогенных компьютерных систем в локальных сетях, то SOAP — полностью открытый способ общения гетерогенных систем в Internet.

Как и любая другая технология, являющаяся основой для более высокоуровневых SOAP также обрастает вспомогательными технологиями. Среди них можно выделить наиболее распространенные — Disco и UDDI, предназначенные для обеспечения поиска и локализации местоположения ресурсов. Disco (Discovery protocol — «протокол обнаружения») помогает находить службы, доступные на данном сервере. А если адрес конкретного сервера неизвестен и необходимо найти ресурс (службу) в Internet, то для этого может использоваться UDDI (Universal Description, Discovery, and Integration — «универсальное описание, обнаружение и интеграция»). Назначение этой технологии — предоставить бизнесу возможность размещать информацию о предоставляемых услугах в Web в некоем глобальном каталоге (www.uddi.org). Этим каталогом могут пользоваться все желающие для поиска компаний, предоставляющих необходимые им услуги.

Все эти базовые службы стандартны и независимы от производителя, но помимо них, есть службы, предлагаемых отдельными производителями.

Полетит?

Неоспоримый плюс технологии Web-служб и залог ее успешного будущего — широкая поддержка компьютерной индустрии. Основной минус состоит в том, что для того, чтобы Web-службы по-настоящему заявили о себе, необходима широкая поддержка не только от гигантов, но и от множества средних и мелких независимых поставщиков решений. Возникнет ли эта поддержка, ответит ближайшее будущее, а пока рассмотрим существующие и возможные примеры использования новой технологии. Достаточно представительный каталог таких решений, постоянно пополняемый, приведен на портале Xmethods (www.xmethods.com).

.Net. Платформа Microsoft .Net представляет набор средств для разработки собственных и использования сторонних Web-служб. Разработка обычной библиотеки компонентов в Visual Studio.Net ничем не отличается от разработки своей Web-службы. Аналогично, использование Web-служб в Visual Studio.Net также ничем не сложнее использования локальных компонентов. Для тех, кто еще не перешел на платформу .Net, но уже готов к применению Web-служб, предоставляется SOAP Toolkit 2.0 for Visual Studio 6.0.

Favorites. С начала 2001 года в Microsoft работает группа разработчиков под управлением небезызвестной Мэри Киртленд, которая начала создание Web-службы для хранения списка любимых ссылок. С ее помощью можно организовывать единое хранилище ссылок, которое использовать независимо от того, где в данный момент находишься. Вся разработка сопровождалась подробными отчетами о процессе, техническими статьями, поднимающими те или иные вопросы создания Web-служб.

Hailstorm. Одно из первых по-настоящему широких применений Web-служб - ориентированный на пользователей набор, в процесс разработки получивший известность под кодовым названием Microsoft Hailstorm. В нем реализованы такие службы, как общая адресная книга, общий список любимых ссылок, календарь и т.д.

DigDes.eRate. Отделом исследований компании Digital Design в конце прошлого года была начата реализация примера Web-службы, предоставляющей информацию о курсе валют (www.digdes.ru/webservices/index.shtml). Разработка велась с использованием как Microsoft SOAP Toolkit 2.0, так и Microsoft Visual Studio.Net.