Занимаясь своим обычным делом — рассказом о новейших маркетинговых «пузырях» ИТ-отрасли, я продолжаю исследование очередной «совершенно замечательной вещицы», Web-служб. В последнее время проповедники «церкви Web-служб» принялись обращать в свою веру сообщество разработчиков средств интеграции корпоративных приложений (Enterprise Application Integration, EAI). Как вы знаете, технологии EAI призваны обеспечить совместную работу разнородных внутрикорпоративных систем с целью повышения их производительности и продуктивности. Это довольно старая проблема в сравнении с временем существования современных информационных бизнес-систем; тем не менее публика всегда готова испытать на себе какой-нибудь новейший эликсир, который, как обещают, волшебным образом излечит все ссадины и ушибы.

За фасадом Web-служб

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

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

Копнув поглубже, вы обнаружите, что Web-службы базируются на двух краеугольных стандартах — XML и HTTP. Первый из них привлекателен своей простотой. XML — полностью текстовый формат информации, намного более понятный человеку, чем поток шестнадцатеричных данных в частном формате. Все системы работают с двоичными данными, тем не менее они все в состоянии так или иначе «читать» простой текст или строки. Поэтому любую систему легко адаптировать для работы с XML, а точнее, для передачи информации в виде текста. HTTP также используют по причине его простоты и, что еще важнее, из-за его повсеместной распространенности в Интернете. Это основной протокол передачи информации в Web и один из немногих протоколов, допускающий свободное прохождение трафика через брандмауэры. Если нужен простой уже существующий механизм передачи данных, альтернативы протоколу HTTP практически нет.

«Плюсы» и «минусы»

Таким образом, преимущество перечисленных стандартов — в легкости их использования и интеграции, а также в их вездесущности. Однако есть и недостаток — они далеко не самый эффективный способ электронной коммуникации. В XML каждая единица информации выделяется парой тегов, которые привносятся в массив данных и увеличивают их объем. Теги пишутся в удобном для чтения человеком виде, поэтому их длина обычно намного больше, чем хотелось бы. Кроме того, длина одного символа документа в формате Unicode может достигать четырех байтов. Четыре байта в других частных двоичных форматах, используемых в таких технологиях, как DCOM или RMI, способны нести намного больше информации, чем один-единственный символ. В настоящее время стоимость дискового пространства упала, поэтому проблема не в недостаточной емкости жестких дисков, а в способности сериализации данных при пересылке через подключение и быстром и эффективном их разборе.

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

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

Связь в мире EAI

Так какое отношение имеет все вышесказанное к EAI? В мире B2B основное преимущество заключено в гибкости и возможности взаимодействия через Интернет самых различных систем, принадлежащих разным компаниям. В таких обстоятельствах достоинства Web-служб перевешивают их недостатки. Однако в EAI-решениях основной движущей силой становится не только способность к взаимодействию, но и быстродействие и производительность. А Web-службы далеко не всегда соответствуют этим требованиям.

Важно не забывать, что EAI — это внутренняя бизнес-среда, в которой у вас есть контроль над работающими платформами, используемыми языками и развертываемым ПО. В ситуации со многими компаниями, организованными в электронную цепочку поставок, подобного контроля у вас нет. Именно в таких обстоятельствах Web-службы могут прийтись ко двору. Тем не менее даже при наличии двух сильно различающихся систем (допустим, одна написана на C++ и работает на Windows, а вторая базируется на связке Java и Solaris) существует множество других, более эффективных и производительных способов их интеграции, чем Web-службы.

В Java предусмотрена архитектура Connector Architecture, предназначенная именно для такой интеграции и больше ориентированная на внутренние соединения, чем на формат данных. Она обеспечивает связь с другими существующими внутренними системами на основе ряда технологий, среди которых сокеты или «родные» API-интерфейсы. Это означает, что придется приложить больше усилий для интеграции систем, чем при создании более общего решения на основе Web-служб, однако Connector Architecture обеспечивает достаточный уровень модульности, а производительность подобного решения на порядок выше, чем у Web-служб.

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

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

Молодо — зелено

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

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

Иногда использование Web-служб в EAI-среде может иметь смысл — например, в рамках внутрикорпоративной инициативы по исследованию возможности применения Web-служб. Однако в общем случае это напоминает попытку общаться с сидящим рядом человеком посредством электронной почты, а не обычной человеческой речи. Тем не менее от многих ИТ-специалистов с исследовательской жилкой (ваш покорный слуга в их числе), любящих копаться в новых технологиях из чистого интереса, вы услышите: «А что же в этом плохого?».

Майкл Хадсон (Michael J. Hudson) — инженер по инфраструктурам в компании Blueprint Technologies (Маклин, шт. Виргиния). В настоящее время занимается разработкой архитектурных решений для клиентов компании, в число которых входит NASA. С ним можно связаться по e-mail: mhudson@blueprinttech.com.