Техническая группа ASAP призывает к участию в работе

Члены OASIS сформировали новый Технический комитет ASAP с целью разработки
протокола асинхронных или долго исполняемых Web-сервисов

Члены консорциума OASIS сформировали новый Технический комитет ASAP (Asynchronous Service Access Protocol, Протокол доступа асинхронного сервиса), цель которого создание самого простого расширения протокола SOAP, который сделает возможным асинхронные или долго исполняемые Web-сервисы. В своей деятельности комитет будет опираться на технические наработки, которые были представлены комитетом по инженерным вопросам Internet (IETF) в Запросе на комментарии (RFC) по SWAP (Simple Workflow Access Protocol, Простой протокол доступа к потокам работ), и составленной на их основе спецификации AWSP (Asynchronous Web Services Protocol, Протокол асинхронных Web-сервисов), написанной Джеффри Рикером (Jeffrey Ricker) и Китом Суэнсоном (Keith Swenson).

По заявлению членов комитета, "не все сервисы мгновенные. Поэтому необходим стандартный протокол, который объединит асинхронные сервисы через Internet и обеспечит их взаимодействие. Интеграция и взаимодействие состоит из контроля и наблюдения за сервисом. Этот протокол должен быть несложным и легким для реализации, чтобы было охвачено множество устройств и ситуаций".

Ожидается, что спецификация ASAP будет согласоваться с работой W3C над XML Protocol и SOAP, она также обеспечит общее решение, являющееся дополнением к ряду спецификаций, включая документы Рабочей группы W3C Web Services Description Language (Язык описания Web-сервисов), Технического комитета OASIS ebXML Messaging Services (Сервисы обмена сообщениями ebXML), Технического комитета OASIS Web Services Business Process Execution Language (Язык реализации бизнес-процессов Web-серсисов) и некоторых других.

Каковы же причины формирования технического комитета?

Большинство существующих протоколов, как HTTP, опираются на неписаное предположение о мгновенном удовлетворении запроса. Если клиент запрашивает ресурс, для генерации которого требуется более одной минуты, то этот запрос "сворачивается", то есть не исполняется. Поскольку технология Internet находит все более широкое применение, указанное выше допущение становится проблематичным. Существует множество ресурсов, к которым желательно обращаться с помощью Web-сервисов и которые не могут ответить в течение 60 секунд - например, data mining, процессоры технологических потоков, ручные процессы и мобильные беспроводные устройства. Однако все, что необходимо, это запросить ресурс и получить от него ответ: Информация еще не готова. Куда ее направить по ее готовности?" Под стартом (start) подразумевается экземпляр асинхронного сервиса. Необходимо сделать возможным обращении к ресурсам с вопросами, подобными тем, что встречаются в реальном мире, "Выполнен ли запрос? Где требуемые документы?" Под этим будет пониматься наблюдение (monitor). Наконец, необходимо иметь возможность изменить задание в середине процесса - с помощью таких инструкций, как "Измените это на пять элементом управления окном, а не шесть". Под этой функциональностью понимается контроль (control).

Как известно, при формировании Технического комитета, на его Web-странице публикуется документ, в котором определяются цели создаваемого комитета. Перечислим некоторые из задач, которые поставили перед собой члены комитета ASAP.

• Этот протокол должен согласоваться с XML Protocol и SOAP.
• Необходимо, чтобы его было можно легко включить в другие основанные на SOAP протоколы, которые требуют асинхронного взаимодействия.
• Протокол должен выдвигать минимальные требования для поддержки обобщенного асинхронного сервиса. Под этим понимается возможность запрашивать, наблюдать, обмениться данными и контролировать обобщенный асинхронный сервис на различных системах.
• Протокол должен быть расширяемым. Первая версия определит минимальный набор функциональности. Тем не менее чтобы такой высокий уровень функциональности мог быть передан для выполнения требований определенной системы, любая система должна быть способна расширить этот набор, который оказывается еще более ограниченным при взаимодействии с системами, которые не оперируют такими расширениями.
• Подобно другим протоколам Internet спецификация ASAP не должна делать какое-либо предположение о платформе или технологии, используемой для реализации обобщенного асинхронного сервиса.
• Лаконичность выражения не является целью этого протокола. Легкость обобщения, понимания и синтаксического разбора должно иметь приоритет над сжатостью.

Автор: По материалам зарубежных сайтов