Использование абстрактных XML-интерфейсов и асинхронная передача SOAP-сообщений
|
| Рохит Харе: «Реальные трудности интеграции возникают на уровнях 8 и 9 стека OSI — экономическом и политическом» |
Все, кто занимается Web-службами, согласны с тем, что они должны быть слабо связанными. Но что именно это значит и как этого добиться, каждый понимает по-своему. На недавней конференции O?Reilly Emerging Technology Conference Адам Босуорт, вице-президент компании BEA Systems, продемонстрировал, как инструментарий WebLogic Workshop добивается слабого связывания. Один из способов основан на отображении XML-документов на сложившийся интерфейсный уровень, который представляет собой абстракцию постоянно меняющихся реализаций. Другой базируется на асинхронной передаче сообщений; она реализована в «переговорном» стиле, причем здесь используется присущая протоколу SOAP возможность однонаправленной передачи сообщений, которая превращает SOAP в нечто большее, чем просто диалект CORBA с угловыми скобками. Не ясно только, в какой мере слабое связывание будет востребовано и чем придется пожертвовать, чтобы его добиться.
Большинство ориентированных на SOAP инструментальных пакетов в явном виде не поддерживают отображение XML. Автогенераторы WSDL, как правило, предоставляют локальные пространства имен непосредственно как общедоступные интерфейсы, а это лучший способ скомпрометировать безопасность. Инструментальные пакеты первого поколения, как отметил Босуорт, сделали сильное связывание слишком простым и притягательным средством.
На это Дейв Статц из Microsoft заметил, что Visual Studio .Net был призван подтолкнуть к действию самый широкий круг разработчиков. Так и произошло. Нестабильные интерфейсы действительно являются серьезной проблемой, поскольку приходится иметь дело с большим их количеством.
Отображение и обмен сообщениями
Отображение — стиль обработки сообщений SOAP, который хорошо характеризует название doc/literal. Для самого распространенного вида удаленного вызова процедур — Remote Procedure Call, который поддерживает знакомый шаблон вызова методов с именованными и типизированными параметрами ввода и вывода, XML не является лучшим типом данных. На самом деле SOAP в стиле RPC работает со стандартными типами данных языков программирования, такими как строки, числа и сложные структуры, созданные из этих примитивов. Чтобы XML передавался как данные, его необходимо инкапсулировать. Альтернативный стиль, который фактически стал предпочтительным в Visual Studio .Net, — это просто обмен XLM-документами.
Переход на этот стиль будет непростым и, возможно, никогда не завершится. RPC естественным образом соответствует тому, что делают программисты, но он не обязательно предполагает строгое связывание. При наличии некоторой дополнительной подготовки можно изолировать интерфейс в стиле RPC от изменений в базовой реализации. Этот подход также служит своего рода мостом, связывающим процедурный стиль программирования с более декларативным стилем. В WebLogic Workshop, к примеру, служба просто декларируется «диалоговой» во многом так же, как служба COM+ может быть объявлена службой, поддерживающей транзакции. Инструментальный пакет обеспечивает поддержку инфраструктуры, которая может включать в себя оперативные информационные сообщения, регистрацию методов обратной связи или даже автоматический опрос конечных точек, которые защищены межсетевыми экранами и не могут напрямую получать ответные сообщения.
Когда элементы SOAP вступают в такого рода переговоры, возникает не просто слабо связанный интерфейс, а субстрат передачи сообщений как таковой. Задержки и ненадежность Internet диктуют необходимость асинхронной передачи сообщений, поскольку бизнес-процессы длятся днями, неделями и годами. Привязка SOAP к внутреннему, ориентированному на сообщения промежуточному программному обеспечению вполне осуществима, и это весьма перспективная стратегия для тех, кто специализируется на интеграции приложений предприятия. Таким образом, слабое связывание будет означать абстрактные интерфейсы и асинхронную передачу сообщений, и в соответствии с этими определениями выполняется очень важная работа.
Маршрутизация SOAP
Когда дело дошло до дела, обобщенное представление о слабом связывании постепенно начало уточняться. Маршрутизация, на которой зиждется Internet, возникла как способ координации взаимодействий между объектами в глобальном пространстве.
Маршрутизация SOAP описывается в двух спецификациях Global XML Architecture, предложенных корпорации Microsoft. Так, WS-Routing определяет, как указать маршрут SOAP-сообщения, прокладываемый через цепочку посредников. WS-Referral предоставляет этим посредникам право менять маршрут. Эти предложения пока существуют лишь в виде тестовых вариантов, но первые продукты, такие как Event Router компании KnowNow, свидетельствуют о формировании тенденции к более активному поведению посредников.
На конференции Рохит Харе из компании KnowNow в общих чертах описал модель, которую он назвал организацией межсетевого взаимодействия на уровне приложений.
В этом случае маршрутизаторы SOAP позволяют формировать композицию систем, являющихся слабо связанными в самом широком смысле.
При подобном подходе такие службы, как перевод валют, выполняются маршрутизаторами SOAP, в то время как виртуальные частные сети и антивирусные службы предоставляются маршрутизаторами уровня IP. Более того, маршрутизаторы SOAP могут действовать с учетом «интересов» не только пары конечных точек SOAP.
Харе в шутку заметил, что «реальные трудности интеграции возникают на уровнях 8 и 9 стека OSI — экономическом и политическом». Реализация возможностей, позволяющих учитывать такие интересы непосредственно в структуре Web-служб, — интересная, трудная и, возможно, невыполнимая задача.
В связи с вышесказанным возникает огромное количество вопросов, среди которых, возможно, самые важные связаны с надежной передачей сообщений и федерации компонентов, находящихся в доверительных отношениях между собой. Современное промежуточное программное обеспечение, ориентированное на обмен сообщениями, такое как IBM MQSeries, Java Message Service компании Sun Microsystems и Microsoft Message Queuing, является сугубо внутренней разработкой соответствующих компаний. IBM предлагает производный от HTTP протокол HTTPR (HTTP Reliable) в качестве открытого способа гарантировать одноразовую доставку асинхронных SOAP-сообщений. Но общей уверенности в том, следует ли расширять HTTP таким образом, нет.
Доверие — действительно острый вопрос. Спецификация WS-Security, совместно подготовленная IBM и Microsoft, решает задачи, связанные только с цифровыми подписями и шифрованием, но никоим образом не позволяет установить доверительные отношения или верифицировать их. Microsoft и поддерживаемый Sun альянс Liberty Alliance активно работают над созданием альтернативных схем для формирования федераций пользующихся доверием элементов в рамках некоторых наборов Web-служб. Компания Grand Central Networks предлагает временное решение, маршрутизируя Web-службы в зоне доверия, которую она создает. Прежде чем осядет пыль, возможно, будет написана еще одна глава в тягостной саге PKI (public key infrastructure — «инфраструктура открытого ключа»).
Разработчики, только начавшие осваивать на Web-службы, могут посчитать, что слабое связывание — это кнут и пряник, что правила меняются прежде, чем игра действительно начинается. Но слабое связывание — стиль конструирования, а не технология. Реализовать его можно множеством разных способов. Хотя ни один из них не дает ответы на все вопросы, подходы, реализованные BEA в рамках WebLogic Workshop, — важные шаги в верном направлении.
Распределенные вычисления в Web
Протокол SOAP (Simple Object Access Protocol) позволяет легко связать между собой COM (Component Object Model), Appel Events, CORBA, JRMI (Java Remote Method Invocation) при помощи XML
