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

Не обязательно. Как я покажу в этой статье, даже если вы полностью реализуете потенциал Web-служб, вам все равно придется заботиться о разработке стратегических бизнес-приложений для информационного обмена. К счастью, у нас есть инструментарий Java 2 Enterprise Edition (J2EE), способный дополнить Web-службы. В совокупности эти два технологических подхода помогут построить бизнес-приложение, представляющее собой экономичное стратегическое решение.

Что они могут, а что — нет

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

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

В определении ничего не говорится о структуре или формате приложения, использующего службу, — наоборот, подразумевается, что это может быть программа любого типа, написанная на любом языке программирования. Поэтому, когда в скором будущем на рынке появятся мощные инструментальные средства, позволяющие относительно легко создавать Web-службы, вам тем не менее придется создавать приложения, ориентированные на эти службы, используя любимый инструмент, будь то J2EE, .NET, Visual Basic или Cobol.

Web-службы работают в слабосвязанной архитектуре, обеспечивающей взаимодействие и обмен информацией между разнородными приложениями. Интеграция прикладных программ никак не зависит от языков или среды исполнения. Этот подход работает на более высоком уровне абстрагирования, чем протоколы, которые в настоящее время обычно используются для решения этой задачи (такие, как RPC, компоненты CORBA и J2EE или EDI).

Web-службы способны сделать более гибкой работу ИТ-менеджеров, которым нужно предоставить общий доступ к большому объему информации клиентам, базирующимся на самых различных платформах и системах. Однако большинство задействуемых при этом открытых стандартов, таких, как протокол Simple Object Access Protocol (SOAP), спецификация Universal Description, Discovery and Integration (UDDI) и язык описания Web-служб Web Services Description Language (WSDL), находятся в процессе постоянного развития. Кроме того, до сих пор не решены такие важные проблемы, как безопасность и управление транзакциями. Более подробно я расскажу об этом ниже.

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

Пробелы в технологии

Некоторые эксперты предлагают перестроить существующие приложения, чтобы воспользоваться преимуществами нового подхода. Но прежде, чем браться за это, следует оценить соотношение риска и возможных преимуществ. Кроме того, при оценке различных вариантов следует рассматривать подход, основанный на архитектуре J2EE, и как альтернативу, и как дополнение к основному подходу. И вот почему. Исторически сложилось так, что инструментарий J2EE и среда распределенных объектов, которую он представляет, предусматривают тесную связь компонентов, содержащих большой объем «знаний» о бизнес-процессе и его данных. Это знание отражено в алгоритме самого компонента. С другой стороны, как уже было сказано, Web-службы базируются на не очень тесно интегрированной архитектуре, в которой компоненты сначала согласуют между собой определения служб, а затем обмениваются XML-документами, в которых содержится более подробная информация о данных, получаемых от Web-служб (таким образом осуществляют связывание).

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

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

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

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

Web-службы и архитектура J2EE

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

На верхнем уровне технология .Net напоминает технологию J2EE — они обе представляют комплект инструментальных средств для разработки приложений с распределенными компонентами. Для Microsoft Web-службы — это важная и очень заметная часть архитектуры .NET. В спецификациях J2EE прямой аналог служб отсутствовал до тех пор, пока Sun Microsystems не предусмотрела Web-службы в своей архитектуре Sun Open Net Environment (ONE).

Архитектура Sun ONE включает Web-службы (http://java.sun.com/webservices), но только как часть полнофункционального архитектурного решения. Sun ONE признает потребность в других технологиях, помимо распределенных компонентов, значимость которых не умаляется в угоду Web-службам. Фактически архитектура Sun ONE делает акцент на модели DART (Data, Applications, Reports and Transactions — данные, приложения, отчеты и транзакции) и проясняет необходимость проанализировать требования к приложению, позволяющие выбрать оптимальную технологию для конкретного решения. Нельзя сказать, что Sun ONE просто предлагает Web-службы как всеобъемлющее решение.

Чтобы понять архитектурные различия между J2EE и Web-службами, посмотрите на их определения. Web-службы определяются в терминах создаваемых ими сообщений и последовательностей «запрос — ответ». В Web-службах применяется протокол HTTP, а данные передаются в формате XML. Приложения J2EE не определяются в терминах сообщений, они используют наборы J2EE-компонентов — Enterprise Java Beans (EJB), Java Server Pages (JSP) и сервлетов, которые взаимодействуют посредством нескольких протоколов, в том числе (это касается EJB) двоичных.

Но, несмотря на все различия, Web-службы и J2EE дополняют друг друга. EJB — компоненты промежуточного слоя в архитектуре J2EE — на ряде серверов приложений могут предоставляться как Web-службы. В числе таких серверов можно назвать WebLogic компании BEA Systems и WebSphere корпорации IBM. В архитектуре J2EE можно также разработать Web-компоненты (JSP и сервлеты) и клиентские компоненты (апплеты и приложения Web Start), которые будут выполнять роль потребителей Web-служб.

В частности, корпоративное приложение, нуждающееся в определенной информации, может получать ее, обращаясь к Web-службе. И клиентское приложение, действующее в качестве потребителя Web-службы, и компонент, развернутый на Web-сервере, который предоставляет доступ к службе, можно написать на C#. С другой стороны, приложение-потребитель можно написать на C#, а Web-службу при этом разработать средствами EJB и развернуть на сервере, поддерживающем спецификацию J2EE. Еще одна возможность — приложение на базе JSP, которое использует Web-службу, развернутую в среде Microsoft IIS.

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

В J2EE предусмотрено огромное количество хитроумных средств. На практике Web-службы — это одно из таких средств, используемых разработчиками. Если анализировать ситуацию без предубеждений, оценивая технологии лишь на основе предоставляемых ими преимуществ, другие J2EE-технологии окажутся более подходящими для многих сервисов (например, EJB Entity Beans лучше подходит для взаимодействия с данными реляционных СУБД, а EJB Message Beans — для выполнения локальных асинхронных транзакций).

Будущее Web-служб и серверы приложений

Если вы отвлечетесь от шумихи вокруг Web-служб, то сможете более четко понять, что же вам в данном случае предлагают. Возможно, у вас возникнет сильное ощущения дежа вю. Все это мы слышали и раньше: EDI, распределенные компоненты, ActiveX, а в последнее время XML. Обо всех этих технологиях говорили как о волшебных средствах, призванных решить все проблемы.

А действительность проста — существующие проблемы взаимодействия приложений решить очень трудно. Эти проблемы, скажем, связанные с различными моделями безопасности приложений, несовместимостью схем, различиями в управлении транзакциями и сложными методиками реагирования на неполадки, полностью не решит ни SOAP, ни .Net, ни ebXML, ни какая-либо другая из предлагаемых в настоящее время технических новинок (см. врезку «Как насчет целостности транзакций?»).

Характер капиталистического предпринимательства таков, что организационные системы — средства управления информационными активами — существенно неоднородны. Стандарты, такие как SOAP, UDDI и WSDL, помогают учесть эту неоднородность, но простое взаимодействие между приложениями станет нормой лишь после принятия всеми стандартных схем и моделей транзакций и безопасности в обширных областях бизнеса. Но если учесть свойственное людям желание выделиться (и то, что непохожесть приносит экономическую выгоду), можно предположить, что общепринятые модели вряд ли станут реальностью в ближайшем будущем.

Арт Тейлор (Art Taylor) — независимый консультант и писатель, в настоящее время работающий над несколькими книгами по технологии Java. Обладает более чем 17-летним опытом деятельности в ИТ. С ним можно связаться по e-mail: taylorart@blast.net.

Как насчет целостности транзакций?

Повсеместному внедрению Web-служб препятствуют существенные технические трудности. До сих пор нет непротиворечивой модели транзакций для Web-служб. Ожидается, что управлять транзакциями будет нижележащая реализация SOAP. Это не очень привлекательный подход к управлению сложными бизнес-процессами, его непросто интегрировать с J2EE-приложениями, которые работают с транзакциями, управляемыми контейнером. Группа OASIS (Organization for the Advancement of Structured Information Standards — Организация по продвижению стандартов структурированной информации, http://www.oasis-open.org) работает над созданием не зависящей от поставщиков моделью транзакций, но ведущие участники рынка, например, Microsoft, IBM и Oracle, исповедуют свои подходы и пока никак ощутимо не поддерживают усилия группы.

Чувство «небезопасности»

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

Производительность

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

Получение сообщений

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

Ваша схема против нашей схемы

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

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