Основные технологии сетевых служб

Описание и поиск служб

Описание программной службы в традиционном понимании основывается на интерфейсе и языке описания интерфейса (IDL). Спецификации на IDL нужны для автоматической генерации переходников и установления основы для динамического связывания. Семантика различных операций, порядок, в котором к ним надо обращаться, и другие (возможно нефункциональные) свойства служб предполагаются известными разработчикам клиентских программ заранее. Это разумно, поскольку клиенты и серверы разрабатываются одними коллективами программистов. Кроме того, интеграционные платформы неявно определяют и вводят ограничения на многие аспекты описания служб и процесса связывания, которые поэтому не требуется считать частью описания службы. В сетевых службах такой неявный контекст отсутствует, поэтому описания должны быть точнее.

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

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

· Интерфейсы. Языки описания интерфейсов находятся в основе любой парадигмы, ориентированной на службы. Описания интерфейсов сетевых служб напоминают описания на языке IDL спецификации CORBA, хотя имеются и отличия, в частности, разрешается описывать типы систем с помощью схем XML. Кроме того, при описании службы необходимо указывать ее адрес и транспортный протокол (например, HTTP), иначе будет нельзя вызвать операции службы. В настоящее время наиболее вероятным представляется использование языка описания сетевых служб WSDL.

· Бизнес протоколы. Сетевая служба обычно предлагает несколько операций, которые должны вызываться клиентом в определенном порядке. Такие обмены между клиентами и службами называются разговорами. Набор правил, регулирующих разговоры, называется бизнес протоколом, поддерживаемым службой, что отличает их от коммуникационных протоколов. Для точного описания службы одного интерфейса недостаточно, и бизнес протоколы необходимы. Однозначного выбора стандарта описания бизнес протоколов к настоящему времени не произошло. Широко используются язык WSCL и язык BPEL.

· Свойства и семантики. Традиционные интегрирующие платформы не содержат в описаниях своих служб ничего, кроме функциональных интерфейсов, но разработчики при связывании служб имеют возможность привлекать другую информацию, кроме того, традиционные службы являются тесно связанными компонентами. При описании автономных и слабо связанных сетевых служб надо учитывать, что клиенты принимают решения об использовании службы только на основании их описаний. В эти описания могут вставляться нефункциональные свойства (стоимость, качество и т. д.). Такая информация очень важна для служб, но она не входит в то, что обычно считается частью интерфейса. Дополнительная информация о службе присоединяется к ее описанию спецификацией универсальных средств описания, обнаружения и интеграции UDDI (Universal Description, Discovery, and Integration), в которой показано, как организуется информация о сетевой службе и как эта информация может регистрироваться и запрашиваться.

· Вертикальные стандарты. Языки и свойства, описанные ранее, имеют обобщенный характер. Они не стандартизуют ни содержание службы, ни ее семантику (то есть смысл конкретных параметров или результат выполнения конкретной операции). Для того, чтобы определить конкретные интерфейсы, протоколы, свойства и семантики, предлагаемые сетевыми службами в конкретных приложениях, необходимы вертикальные стандарты. Например, стандарты RosettaNet описывают автоматизированный обмен коммерческой информацией. Эти стандарты дополняют ранее описанные слои, но связаны с определенными приложениями, они уточняют способы использования стандартного инструментария для управления обменами. Ими руководствуются при написании клиентских приложений, которые могут осмысленно взаимодействовать с любой сетевой службой, совместимой с данными вертикальными стандартами.

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

Спецификация UDDI определяет стандартный прикладной интерфейс для опубликования и поиска информации в справочниках служб.

Взаимодействие служб

Взаимодействие служб проходит под управлением серии стандартов, определяющих это взаимодействие на разных уровнях. Каждый уровень характеризуется одним или несколькими протоколами, которые применимы ко всем сетевым службам, поэтому они реализуются в промежуточном слое сетевых служб. Протоколы взаимодействия невидимы для разработчиков, также как взаимодействия, проходящие между объектами CORBA, что позволяет сосредотачиваться на бизнес логике.

· Транспортные протоколы. Эти протоколы скрывают от сетевых служб коммуникационные сети. Наиболее часто используется протокол HTTP.

· Сообщения. На базе транспортных протоколов можно определять форматы и методы упаковки информации. Для сетевых служб используется протокол доступа к объектам (Simple Object Access Protocol, SOAP). Этот протокол задает шаблон обобщенного сообщения. Для указания конкретных свойств над протоколом SOAP делаются дополнительные надстройки. Например, протокол WS-Security описывает, как с помощью протокола SOAP осуществлять безопасные обмены.

· Инфраструктура протоколов (метапротоколы). Бизнес протоколы связаны с конкретными приложениями, но многое из нужной им поддержки может быть реализовано обобщенными инфраструктурными компонентами. Эти компоненты могут, например, хранить сведения о состоянии разговора между клиентом и службой, ассоциировать сообщения с теми или иными службами, верифицировать сообщения на соответствие правилам, определенным в протоколах, выполнять метапротоколы, которые создаются с целью координации выполнения бизнес протоколов. Например, перед началом фактического взаимодействия клиенты и службы должны выбрать протокол, назначить ответственного за его выполнение и так далее. Эти метапротоколы, а также способы использования языка WSDL и протокола SOAP определяются в спецификации WS-Coordination.

· Промежуточные (горизонтальные) протоколы. Сетевые службы и поддерживающая их инфраструктура по своей природе имеют распределенный характер, и их свойства, выходящие за рамки базовых коммуникационных свойств, реализуются с помощью децентрализованных протоколов. Эти протоколы называются горизонтальными, поскольку они применимы ко многим сетевым службам. Например, для надежности и транзакционности при взаимодействии требуется следовать некоторым протоколам (например, 2РС). Эти протоколы могут поддерживаться метапротоколами, но их лучше скрывать от разработчиков. Именно поэтому они включаются в стек взаимодействия, а не описания служб: их целью является не описание службы, а определение высокоуровневых свойств любого взаимодействия. Первым протоколом такого рода был протокол транзакционного взаимодействия сетевых служб WS-Transaction.

· Сетевая служба (называемая в таком случае базовой) может получать запросы от других сетевых служб (называемых при этом композитными), возможно предоставляемых разными компаниями. С точки зрения клиента базовые и композитные службы неразличимы: это просто сетевые службы, описываемые и реализуемые одинаковыми способами. По мере роста числа используемых сетевых служб и возможности реализации, потребности в композиции служб растут. Стандартизация композитных служб находится в самом начале пути, а наиболее продвинутым стандартом является BPEL.