Logo    
Продукты, технологии Проекты, внедрения Новости мира IT Форумы Курилка Новые публикации Учебный центр
CitForum    CITForum на CD Море(!) аналитической информации! :: CITFORUM.RU
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware HOWTO

22.10.2004

[an error occurred while processing this directive]
Google
WWW CITForum.ru

2004 г.

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

Дэвид Орчард (David Orchard)
Оригинал Web services == or != distributed objects?
Перевод: Intersoft Lab

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

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

По моему мнению, одно из различий между Web-ом, Web-сервисами, с одной стороны, и распределенными объектами, с другой, состоит в том, что первые позволяют человеку читать и понимать передаваемый формат данных (HTML, XML,..), объектные ссылки (URIs), протокольные сообщения и описание[1]. Хотя, возможно, язык 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-языков.


[1] Имеется в виду язык WSDL (Web Services Description Language - язык описания Web сервисов) [прим. перев.]

Ближайшие курсы Центра Информационных Технологий:

25-28 октября 2004, Москва
Введение в объектно-ориентированный анализ и проектирование и унифицированный процесс разработки программного обеспечения c использованием языка UML и CASE-средства IBM Rational Rose

1-4 ноября 2004, Москва
Современные технологии анализа и проектирования информационных систем

1-5 ноября 2004, Москва
Основы передачи данных

9-10 ноября 2004, Москва
Основы моделирования бизнес-процессов и спецификации требований к ПО

Подписка на новости библиотеки:

Новые поступления в on-line библиотеку:

19 октября

  • Функциональная безопасность программных средств
  • Технологические процессы и стандарты обеспечения функциональной безопасности в жизненном цикле программных средств
  • Так как же восстановить данные таблицы?
  • Использование CAST и табличных функций в PL/SQL

    14 октября

  • Разрезая биллионы
  • Платформа, которой не существует
  • Intel 9xx: время тестов
  • Сбалансированная система показателей: краткий обзор рынка программного обеспечения
  • Кросс-браузерность: теория и практика

    12 октября

  • В борьбе за каждый миллиметр
  • Хранилища данных и семантические разрывы
  • BI и ССП: связь между ними
  • Десять заповедей резервного копирования

    7 октября

  • XML-СУБД Sedna: технические особенности и варианты использования
  • Хранилище данных: вопросы и ответы
  • Порядок разработки ETL-процессов

    5 октября

  • Использование сокетов в Delphi
    Часть первая: стандартные сокеты
    Часть вторая: сокеты Windows
  • Задачи и аналитическая платформа для ВРМ
  • Методики, технологии и инструменты ВРМ
  • Выбор системы управления эффективностью бизнеса: решающие факторы

    30 сентября

  • MySQL: Руководство разработчика
  • MySQL: Руководство по ODBC и MyODBC

    28 сентября

  • СУБД ЛИНТЕР. Технический обзор
  • Новое в СУБД ЛИНТЕР 6.1
  • Использование ЛИНТЕР в качестве встроенной СУБД

    21 сентября

  • Материалы книги П.Б.Храмцова "Система доменных имен"
  • Храните свои терабайты в ящике
  • Тестирование контроллеров iSCSI
  • Девять ошибок, которые могут помешать работе SAN

    16 сентября

  • Курс лекций В.В.Воеводина "Параллельная обработка данных"
  • Заморочки от Oracle, или знать бы, где упасть
  • Реинжиниринг: многое в малом
  • CASE-технологии: что, когда, как?

    14 сентября

  • Сильнее угроза - крепче защита (обзор 16 инструментов)
  • GnuPG - OpenSource шифрование и цифровые подписи
  • Оптимизация не-HTML-сайтов для поисковых серверов
  • Новые графические супер-карты от ATI и NVidia
  • Новая жизнь Ethernet

    9 сентября

  • Экстремальное программирование и быстрая разработка ПО
  • 64 бита - "народные" и не очень
  • Рынок ЖК-дисплеев: компании меняют приоритеты
  • Футбольный стадион на рабочем столе

    7 сентября

  • Методология оценки безопасности информационных технологий по общим критериям
  • MySQL Administrator - рулить СУБД легко
  • Взгляд на Windows через лупу
  • Все яйца в одном лукошке
  • Жесткие диски: любимая емкость

    2 сентября

  • Обзор внешних жестких дисков
  • Техника безопасности в беспроводном мире
  • Добавляем в компьютер USB
  • OpenGL и Delphi на практике
  • OpenGL: раскрой глаза на трехмерную графику
  • Иллюзии и реалии безопасности (обзор журнала Computer)

    31 августа

  • Ipsysctl tutorial 1.0.4
  • От включения питания до приглашения Bash
  • OpenBSD - заметки конечного пользователя
  • Запуск Linux-приложений из FreeBSD

    24 августа

  • О системных таблицах InterBase
  • О blog-ах замолвим пару словечек
  • Что такое RSS?
  • Разгон... Sound Blaster'а

    19 августа

  • Введение в Delphi 8
  • Парное тестирование - возьмем от ХР лучшее
  • XML-RPC: вызов процедур посредством XML
  • Связь и интернет для всей планеты
  • Сети для ловли будущего
  • Три кита будущей беспроводной свободы

    17 августа

  • Стеганография. Особенности использования программ на основе метода наименьшего значащего бита
  • Ping своими руками
  • Спецификации XML 1.1 и "Пространства имен 1.1"
  • Что нового в WSDL 2.0

    11 августа

  • Информационная безопасность в современных системах управления базами данных
  • Методические рекомендации №1 "О порядке автоматизации отчетности по МСФО"
  • Черводинамика: причины и следствия
  • Оживляем веб-страничку
  • Тихий ПК: несколько простых способов избавиться от компьютерного шума

    10 августа

  • Полезные советы по Windows XP
  • Oracle и Perl - это очень просто

    9 августа

  • Проблемы при восстановлении и их решение
  • Восстановление сервера с помощью onbar и ISM
  • Настройка диспетчера хранения данных ISM

    5 августа
    Виктор Костромин. "Linux для пользователя"

    Все новости >>>



  • IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware HOWTO

    Реклама на IT-портале citforum.ru

    Нестандартные PR-акции - pr@citforum.ru
    Пресс-релизы и информация в каталог компаний - manager@citforum.ru
    Послать комментарий
    Информация для авторов
    Rambler's Top100 TopList This Web server launched on February 24, 1997
    Copyright © 1997-2000 CIT, © 2001-2004 CIT Forum
    Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав.