Web-сервисы, grid-сервисы и другие

Вполне вероятно, в будущем удастся реализовать идеи utility computing, организовав доступ к компьютерным ресурсам как к другим коммунальным службам. Тогда grid как основа распределенных вычислений с полным основанием будет причислен к разряду великих инженерных достижений человечества, которые формируют нашу среду существования и без которых мы ее просто не представляем. Однако если подобное и случится, то, к сожалению, не завтра. А обидно — особенно для апологетов идеи создания всеобщей распределенной вычислительной среды.

История технологий свидетельствует, что путь идей подобного масштаба от замысла до воплощения никогда не был простым. Не одно десятилетие ушло на то, чтобы аэропланы превратились в современные самолеты, а наивные проекты космических летательных аппаратов воплотились в почти рутинные полеты на Международную космическую станцию. Это утверждение справедливо и по отношению к grid (даже с поправкой на то, что ИТ внедряются быстрее традиционных технологий). И этой идее предстоит пройти отмеренный ей путь.

В новом столетии невиданные прежде возможности распределенных вычислений обеспечены, помимо Internet, рядом основополагающих технологий и факторов:

• современные сетевые технологии (в том числе Gigabit Ethernet и Infiniband);
• кластерные технологии, серверы-лезвия и многоядерные процессоры;
• интеграция приложений и построение систем с использованием сервисов.

Как известно, количество рано или поздно переходит в качество. Наступил момент, когда сумма технологий computing + communication достигла той критической массы, которая обусловила формирование новой реальности. Ключевыми словами, определяющими эту реальность, стали «доступ» и «сервисы», а характеризуется она следующими факторами:

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

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

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

Сложность ситуации усугубляется тем, что коммерческие grid-решения и близкие им инициативы называют по-разному: в IBM и Computer Associates — вычислениями по требованию (On-demand Computing), в HP — адаптивным предприятием (Adaptive Enterprise), в Sun Microsystems — стратегией N1, в Microsoft — Dynamic Systems Initiative, а в Oracle — «попросту» Grid Computing. Но при всем различии фирменных названий суть таких начинаний примерно одна и та же. В конечном счете она сводится к попытке создать условия для динамического распределения вычислительных ресурсов и ресурсов хранения. Общность между перечисленными подходами заключается еще и в том, что соответствующие им решения так или иначе реализуют архитектуры, ориентированные на сервисы (service-oriented architecture, SOA), которые, в свою очередь, обеспечивают управление бизнес-процессами (business process management, BPM).

Несмотря на поднявшуюся пропагандистскую волну, говорить о практическом внедрении коммерческих grid-решений еще рано.

grid как результат эволюции

И все же, несмотря на шумиху, коммерциализацию и «захват» самого термина, «возвышение» grid вполне объективно. Обращения к истории компьютерной отрасли (рис. 1) достаточно, чтобы последовать совету Н.К. Рериха — «смотреть в прошлое, чтобы понять настоящее и в настоящем прозреть будущее». Сорокалетний период ее развития можно интерпретировать как движение к распределенной среде, позволяющей оптимально использовать вычислительные ресурсы, — пусть это будет grid (назовем кошку кошкой).

Рис. 1. Коэволюция вычислительных и сетевых структур

Все начиналось с мэйнфреймов, работавших в пакетном режиме и выполнявших задания последовательно, одно за другим. Среда была централизованной, КПД — низким. Для повышения эффективности работы мэйнфреймов были созданы операционные системы, предусматривающие режим разделения времени, затем появились суперкомпьютеры, еще позже — мощные Unix-серверы и, наконец, центры обработки данных. Все эти системы представляют собой централизованные решения с распределенным доступом. Был, правда, и инициированный академиком В.М. Глушковым утопический проект ОГАС (общегосударственная автоматизированная система сбора и обработки информации) для учета, планирования и управления), который, впрочем, остался нереализованным.

С отставанием лет на десять началось развитие децентрализованного направления — с работ Джозефа Ликлайдера и Роберта Тейлора, ставших затем основой проекта ARPANET. Позднее появились протоколы Ethernet и TCP/IP и соответственно возможности построения локальных и глобальных сетей. Наступление XXI века принесло два открытия, Web-сервисы и XML, которые радикально изменили представления о возможностях организации децентрализованных структур и дали новый импульс к формированию идей grid.

Собственную историю grid можно разделить на два периода. В течение первого из них (1998-2002 годы), «классического» периода предпринимались попытки создавать сетевые структуры для использования географически разнесенных и находящихся в разном подчинении вычислительных мощностей.

По функциональному назначению grid-среды можно разделить на предназначенные для вычислений (computational grids) и хранения данных (data grids). Первые стандарты спецификаций предложил Global Grid Forum, а инструментарий Globus Toolkit является фактическим стандартом программного обеспечения промежуточного слоя для grid.

Летом 2002 года наступил новый период; стройная картина была нарушена. Возмутителем спокойствия оказалась компания Sun Microsystems — ее сотрудники Джеймс Кумер и Чару Чаубал в серии Sun BluePrints OnLine выпустили многостраничный труд Introduction to the Cluster Grid. В нем они стали обозначать термином grid кластерные конфигурации разных масштабов, от уровня подразделения до глобального уровня. Зачем Sun, которая отождествляла сеть и компьютер, было посягать на уже «занятое» название, понять сложно, но именно с этого момента началась дискуссия о том, что такое кластер, а что — grid.

С тех пор к ней подключились представители индустрии и ученые, позиции которых обуславливают выбор ими того или иного определения. Теперь так называют и небольшую кластерную конфигурацию, собранную в одной стойке из серверов-лезвий (в этом особенно преуспела компания Oracle), и классические конструкции, основанные на принципах Open Grid Service Architecture (OGSA), которые пропагандирует корпорация IBM.

Распространение языка XML и Web-сервисов дало старт конвергенции grid и Web-сервисов, которая привела к формированию концепции Grid-сервисов. В рамках Global Grid Forum начались работы по стандартизации в новой области. Предложенная архитектура объединяет основные технологии Grid с Web-сервисами, что позволяет создавать каркасы инфраструктуры для интеграции, виртуализации и управления разнородными ресурсами в виртуальной организации.

Для создания справочной модели (reference model) была организована рабочая группа Open Grid Service Infrastructure. В июне 2003 года она выпустила спецификацию OGSI, в которой определены механизмы создания, управления и обмена данными между Grid-сервисами. Одним из последних событий в этой цепи стало появление Web Service Resource Framework (WSRF), где еще точнее отражена конвергенция двух миров. Как и любые другие Web-сервисы, сервисы «по OGSA» могут быть определены в терминах языка WSDL, что позволяет использовать преимущества известных стандартов SOAP, XML и WS-Security.

Помимо Global Grid Forum вопросами стандартизации теперь ведает и созданный летом 2004 года Enterprise Grid Alliance — консорциум ИТ-производителей, заинтересованных в развитии идей grid. Создавая свой альянс, они руководствовались стремлением применять технологии grid в бизнес-приложениях, а не для решения научных или технических задач, требующих большой вычислительной мощности. Поэтому в центре внимания альянса оказались статические grid-структуры, расположенные в одном географическом месте и являющиеся составляющей корпоративного центра обработки данных. Намерения участников альянса прагматичны; в основном они сводятся к адаптации существующих стандартов, а не к созданию новых.

Неполная сумма производителей?

Предложение об организации консорциума Enterprise Grid Alliance (EGA) прозвучало на конференции OracleWorld в сентябре 2003 года, одновременно с анонсом Oracle 10g. Его основателями стали EMC, Fujitsu Siemens, HP, Intel, NEC, Network Appliance, Oracle, Sun Microsystems и целый ряд меньших по размеру компаний, таких как AMD, Ascential Software, Cassatt, Citrix, Data Synapse, Enigmatec, Force 10 Networks, Novell, Optena, Paremus и Topspin. В ноябре 2004 года в состав консорциума вошла компания Dell; однако в нем до сих пор не числятся ни Microsoft, ни IBM.

В соответствии с программными документами Enterprise Grid Alliance представляет собой консорциум основных производителей и потребителей технологий работы с данными, основной целью которого является разработка решений, ориентированных на построение корпоративных grid-сред (Enterprise Grid).

• EGA сфокусировал внимание на двух классах приложений. Один из этих классов — коммерческие приложения с большой транзакционной составляющей, такие как ERP, CRM или бизнес-аналитика. Второй — так называемые «технические приложения».
• EGA намерен заниматься как стандартизацией, так и маркетингом, поскольку в современных условиях одно без другого невозможно. Однако, с учетом отрицательного опыта, EGA постарается не создавать избыточной шумихи.
• EGA намерен сотрудничать с другими организациями, занятыми стандартизацией в области grid, разумно пользуясь накопленным ими опытом.
• EGA не против членства в организации корпораций IBM и Microsoft, но на общих принципах, таких как «одна компания — один голос» и «равенство в оплате членства».

Несмотря на громкие заявления, сделанные более года назад, пока каких-либо конструктивных предложений EGA не сделал. Почему? Ответ, по всей видимости, можно найти в работе Кристиана Антонини (Is Oracle Database Moving Toward Grid Computing): «Oracle Database 10g не относится к категории Grid! Во всяком случае, не соответствует определению, которое используют специалисты, уже более десяти лет работающие в этом направлении. Можно сказать, что некоторые черты приближают 10g к grid-вычислениям, и компания явно движется в верном направлении. История повторяется, и, обратившись к прошлому, мы обнаружим схожую ситуацию. В 1999 году появилась первая СУБД для Internet Oracle8i, но практически ни одно из качеств Internet-компьютинга в ней не было реализовано — скорее всего, Gridaware мы обнаружим в версии 11 или 12».

Grid-сервисы и все, все, все

В поисках решения, которое обеспечит распределенный доступ к сетевым ресурсам, группа исследователей из Чикагского университета, возглавляемая Яном Фостером, поддерживаемая IBM и Национальной арагонской лабораторией, разработала архитектуру Open Grid Service Architecture (OGSA). Получилось решение со специфическим университетским и академическим «акцентом», основанное на специализированных grid-сервисах. Их можно рассматривать как надстройку над обычными Web-сервисами. Новый тип сервисов был предложен для утверждения в Global Grid Forum, где его одобрили и предложили рассматривать в качестве средства реализации Open Grid Service Initiative (OGSI).

Так началась полоса самостоятельного развития grid-сервисов, которая практически закончилась в 2004 году с появлением Web Services Recourse Framework (WSRF). В качестве практического инструмента для создания grid-сред тогда был предложен Globus Toolkit. Его последняя версия, GT3, основана на представлении о сервисах. Набор GT3 сменил GT2 и GT1, однако на его базе, как и на основе его предшественников, не было создано заметного числа работающих систем.

Отметим, что открытую архитектуру grid-сервисов создали в 1998 году, а это, по любым меркам, было совсем недавно. На тот момент признанные сегодня сервис-ориентированные архитектуры и Web-сервисы находились в зародышевом состоянии, и решение использовать их именно так, а не иначе было вполне оправданным. Как следствие, на протяжении пяти лет два подхода к идее использования сервисов в качестве системообразующего механизма развивались не параллельно. Две непараллельные прямые рано или поздно пересекутся; в данном случае точкой пересечения стал стандарт WSRF.

Рис. 2. OGSA, OGSI, GT3 и grid-сервисы

На рис 2. представлены основные составляющие архитектуры OGSA, которая определяет общие стандарты для приложений и интерфейсы к таким типам grid-сервисов, как управление работами, ресурсами и обеспечение безопасности. Средством для реализации архитектуры, которая определяет работу приложений в grid-среде, аналогичной OGSA, могло бы стать распределенное программное обеспечение промежуточного слоя, базирующееся на различных технологиях (в том числе CORBA, RMI или RPC). Но авторы OGSA предпочли архитектуру на основе сервисов, точнее — на основе расширенного набора Web-сервисов, названных grid-сервисами. Спецификация OGSI является формальным описанием того, что представляют собой grid-сервисы. Наконец, GT3 — это набор инструментальных средств, реализующих OGSI.

Взаимосвязь между этими тремя уровнями представления инфраструктуры, работающей на основе сервисных принципов, полностью соответствует тому, что происходит при создании физических конструкций. Сначала средствами OGSA фиксируется архитектурный замысел, затем с использованием OGSI выполняется инженерный проект, а из компонентов GT3 строится сооружение с grid-сервисами.

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

Авторы grid-сервисов считают основным преимуществом их интерпретации идеи обслуживания то, что предлагаемые ими сервисы имеют состояние и ограниченный потребностями пользователя срок жизни. Они представляют сервер не как что-то, оказывающее услуги, а как фабрику, на которой по заказу клиента создается нужный сервис, используемый в заданное время. Этот подход так и назвали — factory/instance, то есть буквально «фабрика образцов» (Рис. 3).

Рис. 3. Архитектура factory/instance

Сам сервер услуг не оказывает, он лишь фабрикует некий «экземпляр» услуг, осуществляющий сервис от его имени. С точки зрения вычислений это решение не вызывает возражений. Если требуется решить какую-то математическую задачу, где-то в Сети под нее создается виртуальный компьютер, предоставляющий нужный сервер. Физический сервер может поддерживать множество подобных виртуальных вычислительных машин, создаваемых под требования клиента и уничтожаемых, когда в них отпадает необходимость.

Виртуальному временному компьютеру требуется поддержка данными. Этой цели служит еще одна опция grid-сервисов. Service Data позволяет использовать наборы структурированных данных, которые распадаются на две категории:

• сведения о состоянии (state information), в том числе промежуточные и окончательные результаты вычислений;
• сервисные метаданные (service metadata), то есть сведения, относящиеся непосредственно к сервису, в том числе системные данные, поддерживаемые интерфейсы, стоимость услуги и др.

Для удобства пользования клиенты-подписчики могут уведомляться об изменениях в обслуживании. Инициатива OGSI предполагает, что сервисы могут группироваться, образуя сервисные группы, «члены» которых имеют одну точку входа. Получается что-то вроде экземпляра сервиса, состоящего из нескольких сервисов.

Наконец, еще одна группа отличий связана с практическими способами работы с сервисами. В Web-сервисах для адресации используются URI, а в grid-сервисах — расширенная схема адресации Grid Service URI или Grid Service Handle (GSH). А информация о том, как взаимодействовать с сервисами, находится в Grid Service Reference.

Жаркий январь 2004 года

В OSGI была заложена концептуальная основа grid, но обеспечиваемое ею квазистабильное состояние grid-сервисов продолжалось недолго.

7 января компании BEA Systems, Microsoft и Tibco опубликовали свою спецификацию WS-Eventing для Web-сервисов, основанную на принципах публикации/подписки. Она не привязана непосредственно к grid, а предназначена для описания коммуникаций между событиями в архитектуре Web-сервисов. Фактически принцип публикации/подписки призван помочь в создании временной среды, имеющей состояние (этой цели пытались достичь и авторы OSGA, но другими средствами). Буквально через две недели компании Akamai, Globus Alliance, Hewlett-Packard, IBM, Sonic Software и все та же Tibco предложили спецификацию WS-Notification, входящую в состав WS-Resource Framework и опять-таки реализующую принцип публикации/подписки.

Разработку упомянутых спецификаций вполне можно считать первыми серьезными попытками компенсации недостатков, характерных для нынешних стандартов на Web-сервисы. Это, в конечном счете, те же самые действия, которые предпринимались создателями OGSI. Одновременность объявлений о создании спецификаций свидетельствует, с одной стороны, об острой конкурентной борьбе, а с другой — о незрелости технологий, поскольку реальных результатов таких заявлений можно ожидать не раньше середины 2005 года. Положительным эффектом от появления альтернативных подходов можно считать, подход по принципу публикации/подписки, что гораздо образнее и точнее, чем «создание экземпляров». Разногласие в отношении стандартизации Web-сервисов между лагерями IBM и Microsoft совместно с BEA Systems несколько необычно — одна только Tibco присутствует сразу в двух лагерях. Это вызвало пересуды среди аналитиков, однако все они сходятся в том, что сосуществование двух подходов имеет временный характер и в недалеком будущем удастся выработать общее решение.

В январе аналитикам казалось, что конвергенция WS-Eventing и WS-Resource Framework произойдет примерно к 2006 году, но реальные события опережают прогнозы. В августе к лагерю приверженцев WS-Eventing присоединились IBM, CA и Sun. Кроме того, EDS, CA и ряд других компаний опубликовали предложения по языку управления центрами обработки данных Data Center Markup Language (DCML), который должен закрыть пробел между двумя точками зрения на SOA в отношении предоставления услуг, обслуживания и управления. Эти предложения, наряду с WSRF и WS-Eventing, переданы в OASIS. Трудно сказать точно, что сейчас происходит, но одно очевидно: в 2005 году есть основания ожидать окончания смутного времени для мира grid.

Этот загадочный рефакторинг

Практика показала: Web-сервисы прижились гораздо быстрее, чем grid-сервисы, которые, несмотря на громкие заявления, остались в основном на бумаге. Одно из объяснений замедленного развития grid заключается в том, что создававшее Web-сервисы сообщество оказалось прагматичнее, поскольку задалось целью создать жизнеспособную универсальную архитектуру, ориентированную на сервисы и способную работать через Internet. Эта цель конкретна, реализуема и, естественно, собрала вокруг себя достаточные силы.

grid-сообщество изначально представило свою задачу как значительно более узкую, ограничив ее распределением ресурсов (вычислительные данные и даже научные приборы) и созданием виртуальных организаций. Сработал традиционный механизм академического мышления, нарочитой замкнутости «яйцеголовых». Ситуация поневоле напоминает противоборство Windows и Unix, происходившее «на поле» операционных систем в середине 90-х.

Если же перевести объяснения из области общих рассуждений на программистский уровень, неуспех OGSI можно объяснить несколькими обстоятельствами. Во-первых, спецификация OGSI слишком сложна и длинна (а если признать, что все спецификации длинны, то особенно длинна). Во-вторых, в ней плохо учтены существующие средства создания Web-сервисов. В-третьих, она слишком объектно ориентирована (Web-сервисы оказались фактической альтернативой объектному подходу). Последний недостаток расценивают как один из самых существенных; он является чуть ли не главным родовым признаком grid-сервисов (отметим сохранение состояний и модель factory/instance model).

Подвергая критике OSGI как средство реализации OGSA, никто не сомневается в достоинствах архитектуры OGSA — просто требуется иная реализация. Чтобы избавить OGSA от перечисленных проблем и обеспечить конвергенцию двух типов сервисов, в январе 2004 года была предложена структура Web Services Resource Framework (WSRF), которая отличается отсутствием промежуточного слоя в виде OGSI (рис. 4). Важно, что новый стандарт влияет не на всю концепцию OGSA — на верхнем уровне все остается неизменным. Принципиально новым должен стать инструментальный набор GT4, хотя его авторы и утверждают, что на концептуальном уровне между OGSI и WSRF большой разницы нет и что различия имеют лишь синтаксический характер.

Со времени выхода GT3 прошло совсем немного времени. Чтобы избежать неловкости и сохранить лицо, авторы OGSI нашли удачное слово для наименования перехода от OGSI к WSGF, назвав его рефакторингом (от factoring — «разложение на множители»). Не ищите это слово в словарях; оно укрепилось в программистской терминологии с подачи Мартина Фаулера, автора книги «Рефакторинг. Улучшение действующего кода», который определяет рефакторинг как процесс изменения программного обеспечения, внешне не изменяющий поведения программного кода, но способствующий улучшению его внутренней структуры.

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

Рис. 4. От OSGI к WSRF

Знакомьтесь, WSRF

Что собой представляет справочная структура Web-сервисов (Web Service Reference Framework, WSRF)? Скорее всего, в перспективе WSRF будет представлять собой набор из шести спецификаций, которые поддерживают grid-сервисы и другие ресурсы, имеющие собственное состояние (stateful). Это — «стандарт» в том смысле, который подразумевается в англоязычном варианте данного слова. Цель, преследуемая при создании таких спецификаций, заключается в сближении OGSA с Web-сервисами и SOA. С помощью средств, соответствующих этим спецификациям, может быть реализован подход к моделированию и управлению состоянием в контексте Web-сервисов. Иными словами, делается попытка реализовать «состояние» — именно то, что отличает grid-сервисы от Web-сервисов. Подобный подход позволяет пользователям, находясь в контексте Web-сервисов, контролировать и изменять состояние доступных им ресурсов (WS-Resource). Перечислим эти спецификации:

• WS-ResourceLifetime определяет механизм прекращения существования WS-Resource (включая обмен сообщениями), позволяющий немедленно удалить ресурс или через указанное время;
• WS-ResourceProperties определяет, как WS-Resource может быть ассоциирован с интерфейсом, описывающим Web-сервис (включая обмен сообщениями) и позволяющим извлекать, изменять и уничтожать свойства ресурса WS-Resource.
• WS-Notification определяет механизм обработки сообщений о событиях, основанный на принципах подписки/публикации.
• WS-RenewableReferences определяет механизм расширения обычной системы адресации WS-Addressing, принятой в Web-сервисах.
• WS-ServiceGroup определяет интерфейс к набору гетерогенных Web-сервисов.
• WS-BaseFaults определяет механизм обработки сообщений об ошибках.

Перечисленные спецификации находятся в процессе разработки, который неформально распределен между командами, работающими в Globus Alliance, IBM и HP, Национальной лаборатории Лоуренса и ряде университетов.

WS-Eventing — скрытый «рефакторинг» Web-сервисов?

Предложенный Microsoft и BEA стандарт WS-Eventing обеспечивает общий метод взаимодействия Web-сервисов. Объявленная цель создания WS-Eventing заключается в поддержке обмена данными о событиях по схеме подписки/публикации. Формальная модель WS-Eventing строится на основе схемы XML, спецификации WSDL и поддерживает SOAP. Кажется, на WS-Eventing «сойдутся» все основные производители, о чем свидетельствует вхождение в союз с Microsoft и BEA еще и Sun с IBM.

В августе 2004 года был опубликован документ Web Services Eventing, авторами которого являются эксперты из Microsoft, Tibco, BEA, Sun и CA. В нем описывается протокол, позволяющий Web-сервисам предоставлять подписку «на себя» и подписываться на другие сервисы. Трудно оценить технические достоинства WS-Eventing, но бросается в глаза слабая системная подготовка авторов. Складывается впечатление, что они считают достаточным установить связи между компонентами для построения систем.

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

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

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