Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Нужны ли публичные Web-службы?

Амит Асаравала

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

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

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

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

Действовать в открытую

Год назад компания Amazon.com начала предлагать Web-службу, специально разработанную для своей партнерской программы Amazon.com Associates. Представитель компании Пэтти Смит объяснила, что это дает разработчикам превосходный инструмент для совершенствования своих продуктов. Если сайт участника этой программы станет популярным, то для Amazon это будет означать увеличение продаж. Не приводя точных цифр, Пэтти Смит заявила, что тысячи разработчиков уже зарегистрировались, с целью получения доступа к этой службе.

Джефф Гроу, главный управляющий компании ServiceObjects (шт. Калифорния), уверен, что эта служба окажет влияние и на других розничных торговцев. Он считает, что такие компании, как Amazon, вынудят своих конкурентов открыть доступ к данным. По мере того, как все новые компании будут предоставлять публичный доступ к своим ресурсам, разработчикам станет гораздо легче создавать более полезные приложения, способные, например, соединяться с множеством онлайновых магазинов и сравнивать их текущие цены. Компания ServiceObjects помогает разработчикам создавать такого рода приложения, предоставляя им свой пакет DOTS (Data On-Time Services), который распространяется по подписке. Гроу надеется, что даже компания Target откроет свои службы внешнему миру.

Если напримере Amazon видно, как компания может извлекать доходы из публичной Web-службы, то одна из самых разрекламированных служб - Google Web API - пока не принесла ни копейки. Выпустив в марте прошлого года бесплатную бета-версию этого продукта, компания Google предоставила сторонним разработчикам интерфейс SOAP к своей поисковой службе. Инженеры этой компании инициировали этот проект лишь после того, как заметили, что Web-разработчики встраивают средства поиска Google в свои приложения.

Нельсон Минар, создатель интерфейса Google Web API, говорит, что люди упорно ищут возможность использовать средства Google в собственных программах. А Web-служба оказалась самым простым способом, позволяющим им делать это при относительно небольших усилиях. Для Google же эти "небольшие усилия" вылились в инсталляцию ПО Apache SOAP и создание серверных объектов, имеющих доступ к индексу Google, который охватывает около 2 млрд документов. Со своей стороны разработчики пишут клиентское ПО, поддерживающее серверные объекты Google.

Конкурирующая поисковая машина AltaVista не спешит присоединиться к Google в гонке Web-служб. Ян Педерсон, руководитель исследовательского подразделения AltaVista, критично настроен по отношению к Google Web API. Он считает, что это всего лишь красивая упаковка, и, на его взгляд, этот продукт не является чем-то по настоящему эффективным. Компания AltaVista уже некоторое время снабжает "избранных" партнеров API-интерфейсом к своей поисковой машине. Однако базируется этот API не на SOAP или WSDL, а на собственном, фирменном протоколе. Технический директор компании Дуг Янг отмечает, что они вряд ли станут тратить свое время на SOAP, по крайней мере, до возникновения спроса на рынке. Пока же компания AltaVista просто не видит заметного интереса к этому с их стороны.

Недостатки SOAP

У протоколов Web-служб по-прежнему отсутствуют важные составляющие, уже много лет имеющиеся у их более зрелых "родичей", таких, как CORBA и DCOM (см. "А почему не CORBA?"), и одной из самых серьезных проблем этих протоколов остается безопасность. В условиях высокого риска отсутствие механизмов безопасности в SOAP является большим минусом. При написании стандартных SOAP-клиентов разработчики могут маршрутизировать все вызовы через один объект и использовать тот же самый синтаксический анализатор XML при получении ответных сообщений. Но если возникнет нужда в дополнительных нестандартных процедурах безопасности, то разработчикам самим придется писать дополнительный управляющий код для каждого клиента.

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

Одной из простых защитных мер является настройка фильтров на перехват всех сообщений с MIME-типом контента text/xml-soap. Можно также заставить клиентов присылать запросы не традиционным методом POST, а только методом M-POST. В запросах M-POST одно или более полей заголовка являются обязательными для заполнения. Администратор МЭ может потребовать, чтобы в заголовках входящих SOAP-запросов указывалось, какие действия предполагается предпринять, и отфильтровывать сообщения, исходя из этой информации. (Опытные администраторы вдобавок постараются убедиться в соответствии содержимого запроса его заголовку.)

Проблемой, с которой пока сталкиваются Web-службы, остается сетевая задержка. Соединения с низкой пропускной способностью, перегруженные маршрутизаторы и серверы всегда были "ахиллесовой пятой" распределенных приложений, а Web-службы добавляют новое "узкое" место - синтаксический анализатор SOAP. Поскольку сообщение SOAP является XML-документом, то любой получивший его клиент или сервер должен построить объектное дерево документа в памяти, прежде чем действовать в соответствии с ним. И любому посетителю Web-сайта каждый раз придется ждать пока:

* браузер запросит страницу у сервера;

* сервер сформулирует SOAP-запрос и отошлет его Web-службе;

* Web-служба проанализирует запрос, осуществит затребованные действия, сформулирует SOAP-ответ и отошлет его серверу;

* сервер проанализирует SOAP-ответ, использует его данные для создания Web-страницы, чтобы, наконец, отослать ее клиенту.

Время ожидания можно уменьшить, а безопасность повысить, но ни одна из этих проблем не причиняет столько беспокойства, как стандарт, допускающий различные интерпретации. Когда разработчики начинают работать с протоколом SOAP, они сталкиваются с тем, что его спецификация допускает неопределенность описаний некоторых элементов. Например, когда команда разработчиков Google Web API подошла к реализации массивов, они обнаружили, что даже этот важнейший для традиционного программирования тип данных не имеет четкого определения. Существуют несколько интерпретаций этой спецификации, и не все они обеспечивают совместимость.

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

Игра ва-банк

Опыт компаний Amazon и Google выглядит вполне позитивным, но они относятся к тем ранним приверженцам технологии, которые мало чем рискуют. Если импульс, продвигающий Web-службы, ослабнет, любая из этих компаний сможет отказаться от своих программ без особых потерь в плане прибыли. А что будет с теми фирмами, которые ждали значительно больше от успеха SOAP, WSDL и всей технологии распределенных вычислений?

Представив свою стратегию .Net, компания Microsoft ясно дала понять, что она рассчитывает на самое широкое принятие и реализацию SOAP. (Именно Microsoft была автором SOAP, вместе с компаниями UserLand Software и DevelopMentor.) Чтобы доказать сообществу Интернет, что Web-службы - это дело стоящее, Microsoft начала работу сразу над двумя крупными проектами.

Результат первого этапа выполнения проекта, получившего название HailStorm (а затем Persona, и еще позже .Net My Services), был встречен шквалом критики. Так, Джонатан Шварц, главный стратег компании Sun Microsystems, доказывал, что хранение пользовательских данных на серверах Microsoft приведет к появлению ненужного посредника между бизнесом и заказчиком. Бизнес согласился с этим, в результате чего Microsoft не смогла найти ни одного партнера для участия в этой программе. В апреле прошлого года проект HailStorm отправился на полку, а Microsoft пришлось вернуться к тому, что получается у нее лучше всего - к продаже ПО. Вместо того чтобы предлагать онлайновую службу .Net My Services, она решила встраивать такие средства в серверное ПО, хостинг которого будет осуществляться самими компаниями.

Неудача с HailStorm еще не означает, что публичные Web-службы не могут работать. Примерно в то же время, когда проект HailStorm сошел со сцены, группа MapPoint той же Microsoft выпустила вторую версию картографической и адресной службы. Служба MapPoint.Net с API-интерфейсом на базе спецификации SOAP стала для Microsoft первой корпоративной реализацией ее платформы, а возможно, и первой публичной Web-службой, приносящей доход.

В число пользователей MapPoint .Net среди прочих входят компании Dollar Rent A Car, немецкая hotel.de, Tellme Networks и Zone Labs. И хотя Microsoft не сообщила о том какой доход приносит эта Web-служба, известно, что она берет за ее услуги солидную плату. Новые партнеры, приобретающие лицензию, должны платить по 15 тыс. долл. за каждые 2 млн. транзакций или по 50 тыс. долл. за каждые 7,5 млн. транзакций. Стив Лоулер, директор службы MapPoint.Net, говорит, что она осуществляет "миллионы транзакций" в день.

Служба MapPoint .Net является наглядным примером того типа приложений, которые имеет смысл реализовывать как Web-службы. Раньше организациям, таким, как MapPoint или U.S. Postal Service, которые имели дело с большими объемами данных, приходилось регулярно снабжать своих партнеров обновленной информацией на компакт-дисках. При этом партнеры, пользующиеся этими данными, никогда не были уверенными в том, что располагают самой свежей информацией. Более того, отделам ИТ приходилось тратить сотни часов, копируя обновленную информацию на множество ПК и портативных компьютеров, разбросанных по всей организации.

Лоулер говорит, что услуги, предоставляемые по подписке, имеют смысл при постоянном изменении данных. Так, данные в MapPoint могут меняться поминутно, когда ее партнер - компания Tele Atlas - обновляет отчеты о движении транспорта на главных магистралях. Чтобы воспользоваться услугами MapPoint.Net, некоторым компаниям сначала придется инсталлировать пакет SOAP, но те из них, у которых уже есть доступ к другим Web-службам, смогут немедленно приступить к настройке клиентского ПО, которое будет управлять входящими картографическими данными.

А много ли компаний уже инсталлировали у себя поддержку SOAP? И действительно ли они всерьез намерены подписываться на Web-службы для поддержки реальных бизнес-функций?

Чарльз Муар, главный управляющий компании Xara Online, признает, что, решая эти вопросы, большинство компаний все еще находятся на стадии эксперимента. Муар считает, что Web-службы его компании вызывают большой интерес, но это пока не приводит к большому результату в плане бизнеса. Гроу из компании ServiceObjects согласен с оценкой Муара, но он отмечает, что многие клиенты его компании, которых он описывает как "фирмы среднего размера", все еще находятся на стадии опробования предлагаемых ServiceObjects SOAP-служб в своих интрасетях.

Выживут ли Web-службы?

Имея столько недостатков, позиции SOAP выглядят достаточно шаткими. Может пройдет немного времени, и Web-службы сойдут со сцены так же, как VRML, Java-аплеты и прочие неудачные технологии? Но существенное отличие между ними и Web-службами состоит в том, что первые так и не дождались широкой поддержки от поставщиков.

Компании BEA Systems, IBM, Microsoft, Oracle и Sun Microsystems уже выпустили и каждая по платформе для разработки приложений, поддерживающей Web-службы на базе SOAP. В 2000 г. газета USA Today сообщила о том, что "тысячи разработчиков Microsoft работают над стратегией .Net". А агентство CNet поведало о миллиардах долларов, уже потраченных Microsoft на Web-службы, и это еще не конец. Неудача Web-служб приведет к колоссальным потерям для многих основных игроков в области высоких технологий, а они просто не могут позволить себе, чтобы это случилось.

В некотором роде Web-службы нужны поставщикам даже больше, чем их клиентам. Первые отчаянно нуждаются в новой технологии, которая подтолкнула бы замедлившиеся темпы продаж при нынешнем плохом состоянии экономики. Все же концепция Web-служб вряд ли может служить примером "предложения без спроса". Тысячи разработчиков, подписавшихся на Web-службы Amazon, Google и ServiceObjects, доказывают обратное, так же как и 2,5 млн. разработчиков, которые, по словам Microsoft, участвуют в бета-тестировании платформы .Net.

Критики же утверждают, что Web-службы - это технология, в которой нет надобности. Тот факт, что подписавшиеся на Web-службы Amazon, Google и ServiceObjects разработчики только испытывают эту технологию, а не используют ее в критически важных бизнес-приложениях, придает этим утверждениям некоторый вес. Однако бизнесу Web-службы действительно нужны, ведь компании начали применять разные формы распределенных вычислений задолго до появления спецификации SOAP. Например, AltaVista первой использовала фирменный формат VAL для своей поисковой службы. Позже она переключилась на разработанный ею же XML-формат, аналогичный SOAP. Когда компания Intel захотела упростить и формализовать способ подтверждения поставок сырья, она модифицировала приложение EDI, чтобы оно могло принимать XML-документы от фирм-поставщиков.

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

А вам это нужно?

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

Нужно превращать в службы те приложения, которые открывают новые каналы для предложения продуктов. Компания Amazon сделала это, чтобы обеспечить новый способ доступа к каталогу своих товаров. В случае же с Google причина создания Web-службы заключается в другом. Хотя ее API-интерфейс и обеспечивает дополнительный канал, сама же компания больше заинтересована в привлечении разработчиков. Деловой успех этого проекта зависит не от сиюминутной прибыли, а от приложений, которые разработчики создадут для этой службы. При некоторой удаче, одно (а может и не одно) приложение может предоставить такие возможности для бизнеса, о которых Google даже не помышляла.

Конечно, если ваши партнеры требуют Web-услуг и суммарные издержки на реализацию их меньше тех денег, которые они готовы за них выложить, то ваше решение очевидно. Однако Хэнк Барнс, старший вице-президент по стратегии в подразделении программных служб компании Divine, предостерегает относительно переписывания приложений. Он считает, что просто надо "упаковывать свои приложения в обертку Web-служб", если же вы приметесь переделывать все, что сделали до сих пор, то, как говорится, "отстанете от поезда".

Компаниям важно тщательно изучить типы приложений, которые они намерены выставить на всеобщее обозрение. К приложениям, хорошо работающим в качестве служб, относятся приложения с постоянно меняющимися данными, вроде MapPoint. Для приложений, требующих быстрых коммуникаций между клиентом и сервером, могут потребоваться серьезные инвестиции в оборудование. Аналогично, приложениям, для которых недопустимы обычные для сети Интернет потери пакетов или простои, понадобятся значительно более серьезные переделки, чем просто инсталляция "упаковщика" (wrapper) SOAP. Менеджер такого проекта должен также определиться с тем, как компания будет решать проблему отсутствия в SOAP стандарта безопасности.

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





  
4 '2003
СОДЕРЖАНИЕ

бизнес

• Анализ возврата инвестиций

• Открытый источник инноваций. Интервью Сергея Тарасова

• Кто проложит русло широкополосному потоку

• Российский ИТ-рынок считает доходы

• Еще раз об экономике контакт-центров

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

• Тестируем коммутаторы Fibre Channel среднего класса

информационные системы

• Спектр электронных покупателей

• Нужны ли публичные Web-службы?

• Как стать уверенным в своем Web-сайте

сети связи

• Передача голоса поверх IP, ATM и DSL

• Системы DWDM: особенности и применение

• Fast Ethernet в кольце

кабельные системы

• Новое поколение оптических рефлектометров

• Тональные генераторы и щупы — простые, но важные инструменты

защита данных

• Основы безопасности ИТ

• Тактика защиты информации

новые продукты

• Консольные серверы Digi СМ, Система широкополосного радиодоступа i-BRAIN


• Калейдоскоп



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх