Web-сервисы == или != распределенные объекты?

Материал из Wiki.

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

Однако, чем же на самом деле отличаются друг от друга Web, Web-сервисы и распределенные объекты? В чем состоят конкретные архитектурные различия? Задавая этот вопрос, я не хотел бы услышать двусмысленный ответ в духе: «Web-сервисы – это крупно структурированные объекты, а распределенные объекты – мелко структурированные».

По моему мнению, одно из различий между Web-ом, Web-сервисами, с одной стороны, и распределенными объектами, с другой, состоит в том, что первые позволяют человеку читать и понимать передаваемый формат данных (HTML, XML,..), объектные ссылки (URIs), протокольные сообщения и описание. Хотя, возможно, язык WSDL далеко не самый удобочитаемый. Распределенные объекты же позволяют читать и понимать описание (IDL – язык описания интерфейса), а формат передачи, объектные ссылки и протокольные сообщения делают бинарным. Так что, возможно, этого вполне достаточно. Хотя существует множество других различий, например, позднее связывание(late binding of the information content to the user), возможность получения высокой производительности благодаря использованию протокола HTTP и URI для установления эквивалентности и т.п.

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

public interface PO {
getMyPo( in int poId, out PO purchaseOrder); }

тогда как HTTP мог бы быть смоделирован следующим образом:

public interface HTTP {
get (in URI address, out MIME body ); }

Давайте очень кратко остановимся на «HTML-ой версии» этого примера, поскольку именно с HTML связано большинство вызовов. Поэтому немного изменим интерфейс:

public interface HTTP {
get (in URI address, out HTML body ); }

У каждого из этих интерфейсов имеется две весьма различные конфигурации. Интерфейс PO может быть расширен новыми и произвольными методами - как и класс PO. Они оба произвольно расширяемые – то есть определяются интерфейсом – в отличие от обобщенных или унифицированных. HTTP, SQL и т.п. называются унифицированными, поскольку разработчик приложения не может изменять методы. Чтобы расширить команды HTTP, потребуется выполнить колоссальную работу, поскольку в этом процессе оказываются задействованными стандарты. Сказанное справедливо и в отношении официального HTML.

Поэтому может показаться, что благодаря произвольной расширяемости интерфейса в стиле dist-obj (распределенные объекты), эта конфигурация должна была бы иметь огромный успех. Однако существует нечто чрезвычайно важное, что не выражается в этом интерфейсе. Возможно, именно поэтому в выигрыше оказываются системы, которые основываются на соглашениях, а не на интерфейсах прикладного программирования (API). Хотя интерфейс HTTP и ограничен определенным набором команд, содержимое может быть расширено. В него можно поместить XML, MIME

Возвращаясь к HTML, стоит отметить, что в спецификации присутствует важная часть информации. Это – правило "Необходимо пропускать" ("Must Ignore"). Другими словами, и для HTML, и для заголовков HTTP, и даже для значительной части спецификации URI существует правило, согласно которому любое неизвестное должно быть пропущено. Если какое-либо содержимое появляется в произвольном месте, и получатель об этом не знает, его можно проверить на

допустимость, как если бы это неизвестное содержание было бы «выброшено» из экземпляра. Хотя данное правило указано в спецификации HTML, оно не выражено в схеме/dtd. По мнению автора, если бы HTML не имел возможности выразить правило "Необходимо пропускать" вне схемы, HTML, вероятно, не допускал бы столь широкую расширяемость.

В результате, стало возможным развитие HTML, которое, однако, не повлияло на интерфейс прикладного программирования HTTP, поскольку они ортогональны. Эти форматы и команды развиваются отдельно друг от друга.

Системы распределенных объектов навязали решение о том, что для расширения любого вида необходимо, чтобы обе стороны понимали расширенный интерфейс. Это – ошибка «единственного администратора». На устранение недостатков систем распределенных объектов была потрачена масса усилий, и, по убеждению автора, отсутствие «локальной» расширяемости ("touchless" extensibility) явилось основной причиной недостаточного понимания и успеха Web-а.

Давайте представим, что для распределенных объектов и Web-а применяются обратные правила. Тогда в случае систем распределенных объектов можно было бы поместить в класс PO желаемое содержание любого вида и, если оно неизвестно получателю, он просто пропустил бы его. В результате, системы распределенных объектов оказались бы гораздо более эластичными. И содержали бы меньше интерфейсов с астрономическим числом различных методов. По мнению автора, технология распределенных объектов была бы более притягательный, если бы для поддержания расширяемости параметров, и возможно даже расширяемости методов, не требовалось бы синхронного изменения обеих сторон.

Сейчас сложно представить, что HTML развивался бы столь быстро и успешно, не будь правило "Необходимо пропускать" встроенным, и поэтому HTML и не смог развиться вне рамок комитета по стандартизации. Изображения, формы, каскадные таблицы стилей и т.п. были разработаны после появления первой версии HTML.

А что с Web-сервисами? Похоже, что большинство разработчиков Web-сервисов при проектировании своих интерфейсов принимают такое же решение, как и в случае распределенных объектов. Они заново создают метод распределенного объекта "getPO" в сообщении SOAP, не допуская расширяемость в PO. Всякий раз, когда им необходимо расширить PO, они вынуждены расширять схему и выпускать новую версию. Хотя они могли бы расширить PO, используя механизм расширяемости XML-схемы.

XML-схема навязала решение, что любые расширения, которые необходимо проверить на допустимость, должны потребовать корректировки схемы на обеих сторонах. Более того, все понятия, согласующиеся с расширяемостью, выражаются на языке схемы. Это чрезвычайно близко к решениям распределяемых объектов.

Однако, эти решения не совсем такие. Так, XML-схема предоставляет элемент wildcard, который делает возможным присутствие в экземпляре элементов ограниченных пространств имен. Если схема PO обеспечивает групповые символы, разработчики PO могут воспользоваться групповыми символами для расширяемости. Они не получат произвольную расширяемость, присущую HTML – по мнению автора, это весьма проблематично. Существует общая модель, допускающая элементы из пространств имен, отличных от целевого пространства имен. Это обеспечивает по крайней мере какую-то расширяемость, хотя эта модель не исключает некоторых сложностей, которые детально рассмотрены в статье Examining wildcards for versioning. В статье Versioning XML Languages (Управление версиями XML-словарей), опубликованной на xml.com, показано, как их можно использовать для получения «локальной» расширяемости с полной проверкой допустимости; отмечу, однако, что в этом случае разработчик должен по-прежнему активно определять точки расширения.

Существует еще одно существенное различие между технологией расширяемости Web-а и XML-схемы - отличие активной спецификации расширяемости от пассивной. Так, XML-схема требует от разработчика активно вставлять что-нибудь в документ схемы, чтобы предугадать, где нужно обеспечить расширяемость для локального изменения, а большинство технологии Web уже располагает расширяемостью, по умолчанию пассивно встроенной в систему. Что, возможно, оказалось бы идеальным решением, если бы нам удалось добиться пассивного объединения правила "Must Ignore" c логикой проверки на допустимость. В этом случае мы могли добавить всю функциональность это правила в инфраструктуру, и не требовать, чтобы каждый формат данных и соответствующий код определял, где пропускаемые элементы допустимы, а где нет. И с учетом «уроков HTML» механизм определения правила "Must Ignore", возможно, следует выражать вне языка схемы.

Однако, высказывается мнение, что отсутствие команд с ограничениями (это мнение так называемых «рестафарианов» [RESTafarian]) свидетельствует о «недолгом веке» Web-сервисов. Автор полагает, что хотя сложность в обеспечении «локальной» расширяемости ухудшает возможность развертывания вободно связанных приложений, имеется достаточно способов, с помощью которых можно построить свободно связанные Web-сервисы. Но для этого потребуется явные действия от разработчика интерфейса. Именно поэтому, на мой взгляд, должна появиться более легкая модель, предназначенная для создания и проверки допустимости расширяемых XML-языков.

© Дэвид Орчард (David Orchard).

Источник | 2004