Использование абстрактных описаний для генерации, обмена и конфигурирования рабочих циклов сервиса и клиента

Использование абстрактных описаний для генерации, обмена и конфигурирования рабочих циклов сервиса и клиента

Иллюстрации

Показать все

Реферат

Область техники

Настоящее изобретение относится к распределенным моделям прикладного программирования, в частности к использованию абстрактных описаний для генерации, обмена и конфигурирования рабочих циклов сервиса и клиента.

Предшествующий уровень техники

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

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

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

Сообщения, обмен которыми производится (например, сообщения запроса сервиса и ответные сообщения сервиса), могут быть определены так, чтобы быть понятными каждому сервису (например, одному или более потребителей сервисов или одному или более провайдеров сервисов), участвующему в реализации желательной функциональности. В принципе сообщения могут быть определены в соответствии с некоторыми стандартами, такими как, например, DCOM (Модель объекта с распределенными компонентами), CORBA (Архитектура брокера (программное обеспечение, устанавливающее соответствие сервисных запросов клиента серверным реализациям) общего запроса объекта) или веб-сервисы. Веб-сервисы могут быть дополнительно определены в соответствии с различными спецификациями веб-сервисов, такими, например, как WSDL (Язык описания веб-сервисов), WS-policy (Инфраструктура стратегии веб-сервисов) и т.д.

Например, провайдер сервисов может описать свой сервис с использованием языка WSDL. Провайдер сервисов может опубликовать это описание в каталоге сервисов, который, например, использует Универсальное описание, обнаружение и интеграцию (UDDI). Потребитель сервисов может издать запросы по отношению к каталогу для локализации сервиса и определения, каким образом осуществлять коммуникацию с сервисом. Части таких WSDL-описаний, обеспечиваемые провайдером сервисов, поступают к потребителю сервисов в ответ на запрос. Потребитель сервисов использует эти WSDL-части для посылки запроса к провайдеру сервисов. В свою очередь, провайдер сервисов выдает соответствующий ответ потребителю сервисов.

В некоторых средах, для генерации сервиса, разработчик пишет исходный код (например, на C#, C++ или Visual Basic) в соответствии с заданной моделью программирования. Исходный код может затем компилироваться в тип сервиса, и тип сервиса исполняется в рабочем цикле сервиса для предоставления сервиса потребителю сервисов. Однако рабочие циклы сервисов могут создаваться по-разному, и различные модели программирования могут реализовывать функции распределенной передачи сообщений различными способами. Например, одна модель программирования может реализовать сообщение запроса с использованием одного интерфейса, а соответствующее ответное сообщение - с использованием второго, отличающегося интерфейса. С другой стороны, другая модель программирования может реализовать сообщение запроса и соответствующее ответное сообщение с использованием одного интерфейса, использующего разные методы. Этот единственный интерфейс может применять один метод для сообщения запроса и второй, отличающийся метод для соответствующего ответного сообщения.

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

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

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

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

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

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

Краткое описание сущности изобретения

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

В других вариантах осуществления компьютерная система преобразует абстрактное описание сервиса, которое описывает сетевой сервис. Компьютерная система получает доступ к дереву описания сервиса для некоторого сервиса. Формат дерева описания сервиса не зависит от модели программирования и генерировался из информации описания, которая была проанализирована из соответствующего типа сервиса и конфигурации сервиса. Компьютерная система преобразует дерево описания сервиса в другой формат представления, так чтобы информация описания могла быть совместимым образом перенесена в модуль, который обрабатывает информацию описания сервиса, определенную в соответствии с другим форматом представления. Компьютерная система выводит информацию описания в другом формате представления.

В дополнительных вариантах осуществления компьютерная система инициирует рабочий цикл сервиса из абстрактного описания сервиса, которое описывает сетевой сервис. Компьютерная система получает доступ к дереву описания сервиса для некоторого сервиса. Формат дерева описания сервиса не зависит от модели программирования и был генерирован из информации описания, которая была проанализирована из соответствующего типа сервиса и конфигурации сервиса. Компьютерная система вызывает относящийся к хосту метод инициализации сервиса, связанный с деревом описания сервиса. Компьютерная система инициализирует рабочий цикл сервиса для сервиса в соответствии с информацией описания, которая была проанализирована из соответствующего типа сервиса и конфигурации сервиса.

В других вариантах осуществления компьютерная система генерирует исходный код для канала. Компьютерная система импортирует метаданные в дерево описания канала для канала. Формат дерева описания канала не зависит от модели программирования. Компьютерная система генерирует модель объекта документа (объекта, который определяет, сохраняет и управляет данными документа) кода и соответствующую конфигурацию сервиса из дерева описания канала. Генерированные модель объекта документа кода и соответствующая конфигурация сервиса предназначены для реализации канала в соответствии с заданной моделью программирования. Компьютерная система выводит генерированную модель объекта документа кода в качестве исходного кода и выводит соответствующую конфигурацию сервиса, так что генерированные модель объекта документа кода и соответствующая конфигурация сервиса могут быть использованы в соответствии с заданной моделью программирования.

Указанные и другие задачи и признаки настоящего изобретения поясняются в последующем описании и формуле изобретения или могут быть изучены при практической реализации изобретения, как описано ниже.

Краткое описание чертежей

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

Фиг.1 - пример компьютерной архитектуры, обеспечивающей возможность использования абстрактных описаний в целях генерации, обмена и конфигурирования рабочих циклов сервиса и клиента.

Фиг.2 - пример абстрактного описания сервиса.

Фиг.3 - пример абстрактного описания канала.

Фиг.4 - подходящая операционная среда для реализации принципов изобретения.

Фиг.5 - блок-схема способа генерации абстрактного описания сервиса, которое описывает сетевой сервис.

Фиг.6 - блок-схема способа преобразования абстрактного описания сервиса, которое описывает сетевой сервис, в код, представляющий сетевой сервис.

Фиг.7 - блок-схема способа инициирования рабочего цикла сервиса из абстрактного описания сервиса, которое описывает сетевой сервис.

Фиг.8 - блок-схема способа генерации исходного кода для канала.

Детальное описание предпочтительных вариантов осуществления

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

В других вариантах осуществления компьютерная система преобразует абстрактное описание сервиса, которое описывает сетевой сервис. Компьютерная система получает доступ к дереву описания сервиса для некоторого сервиса. Формат дерева описания сервиса не зависит от модели программирования и был генерирован из информации описания, которая была проанализирована из соответствующего типа сервиса и конфигурации сервиса. Компьютерная система преобразует дерево описания сервиса в другой формат представления, так чтобы информация описания могла быть совместимым образом перенесена в модуль, который обрабатывает информацию описания сервиса, определенную в соответствии с другим форматом представления. Компьютерная система выводит информацию описания в другом формате представления.

В дополнительных вариантах осуществления компьютерная система инициирует рабочий цикл сервиса из абстрактного описания сервиса, которое описывает сетевой сервис. Компьютерная система получает доступ к дереву описания сервиса для некоторого сервиса. Формат дерева описания сервиса не зависит от модели программирования и был генерирован из информации описания, которая была проанализирована из соответствующего типа сервиса и конфигурации сервиса. Компьютерная система вызывает относящийся к хосту метод инициализации сервиса, связанный с деревом описания сервиса. Компьютерная система инициализирует рабочий цикл сервиса для сервиса в соответствии с информацией описания, которая была проанализирована из соответствующего типа сервиса и конфигурации сервиса.

В других вариантах осуществления компьютерная система генерирует исходный код для канала. Компьютерная система импортирует метаданные в дерево описания канала для канала. Формат дерева описания канала не зависит от модели программирования. Компьютерная система генерирует модель объекта документа кода и соответствующую конфигурацию сервиса из дерева описания канала. Генерированные модель объекта документа кода и соответствующая конфигурация сервиса предназначены для реализации канала в соответствии с заданной моделью программирования. Компьютерная система выводит генерированную модель объекта документа кода в качестве исходного кода и выводит соответствующую конфигурацию сервиса, так что генерированные модель объекта документа кода и соответствующая конфигурация сервиса могут быть использованы в соответствии с заданной моделью программирования.

Варианты осуществления в пределах объема настоящего изобретения включают в себя машиночитаемые носители (среды передачи) для переноса или содержания в них исполняемых компьютером команд или структур данных, сохраненных на них. Такие машиночитаемые носители могут представлять собой любые доступные носители, доступ к которым может осуществляться универсальной или специализированной компьютерной системой. Например, но не в качестве ограничения, такие машиночитаемые носители могут содержать физические носители для хранения данных, такие как RAM (ОЗУ), ROM (ПЗУ), EPROM (стираемое программируемое ПЗУ), CD-ROM (ПЗУ на компакт-дисках), или другие ЗУ на оптических дисках, ЗУ на магнитных дисках или другие магнитные ЗУ, или любые другие носители, которые могут быть использованы для переноса или хранения желательных средств программного кода в форме исполняемых компьютером команд, считываемых компьютером команд, или структур данных, и доступ к которым может осуществляться универсальной или специализированной компьютерной системой.

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

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

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

Фиг.1 иллюстрирует примерную компьютерную архитектуру 100, которая обеспечивает использование абстрактных описаний для генерации, обмена и конфигурирования рабочих циклов сервиса и клиента. Как изображено в компьютерной архитектуре 100, компьютерные системы 101 и 121 соединены через сеть 141. Сеть 141 может быть локальной сетью (LAN) или сетью широкого охвата (WAN), или даже сетью Интернет. Компьютерные системы, соединенные с сетью 141, могут принимать данные и посылать данные к другим компьютерным системам, соединенным с сетью 141. Соответственно, компьютерные системы 101 и 121, а также другие подсоединенные компьютерные системы (не показаны) могут создавать данные, относящиеся к сообщениям, и обмениваться данными, относящимися к сообщениям (например, дейтаграммы IP-протокола и сообщения в других протоколах более высокого уровня, которые используют IP-дейтаграммы, таких как Протокол управления передачей (TCP), Протокол передачи гипертекста (HTTP), Простой протокол передачи электронной почты (SMTP), Простой протокол доступа к объектам (SOAP) и т.д.), через сеть 141.

Компьютерная система 101 содержит модуль 104 загрузки сервиса, модуль 107 экспорта метаданных, модуль 108 импорта метаданных и генератор 113 контракта. В принципе, модуль 104 загрузки сервиса конфигурирован для получения типа сервиса (например, типа CLR (Рабочий цикл на общем языке)) или другого объекта модели объектно-ориентированного программирования, представляющего сетевой сервис. Модуль 104 загрузки сервиса может также конфигурироваться для приема соответствующей информации конфигурации опционального сервиса. Модуль 104 загрузки сервиса может преобразовывать тип сервиса (или другой объект) и соответствующую информацию конфигурации сервиса (если таковая загружена) в абстрактное описание сервиса.

В некоторых вариантах осуществления сетевой сервис представлен в соответствии с заданной моделью программирования. Заданная модель программирования может представлять собой тип, который реализует один или более интерфейсов. Каждый интерфейс может далее реализовывать один или более методов. Интерфейсы и методы, включенные в тип, могут аннотироваться атрибутами, указывающими, как обрабатывать и публиковать интерфейсы и методы и как выполнять обработку заданного рабочего цикла с использованием интерфейсов и методов. Альтернативно или в комбинации с аннотированием атрибутов, информация конфигурирования сервиса может также указывать, как обрабатывать и публиковать интерфейсы и методы и как выполнять обработку заданного рабочего цикла с использованием интерфейсов и методов.

Соответственно, модуль 104 загрузки сервиса может загружать тип сервиса и соответствующую информацию конфигурирования сервиса. Модуль 104 загрузки сервиса может анализировать компилированный код, который представляет модель программирования и соответствующую информацию конфигурирования сервиса, для идентификации функциональности представленного сетевого сервиса. Например, модуль 104 загрузки сервиса может идентифицировать конечные точки, стеки каналов и связывания от типа сервиса и соответствующей информации конфигурирования сервиса. Модуль 104 загрузки сервиса также может идентифицировать другие опции рабочего цикла, такие, как, например, опции защиты, опции надежной передачи сообщений, опции регистрации сообщений, опции дросселирования соединений и т.д. Из идентифицированной функциональности модуль 104 загрузки сервиса может создать абстрактное описание сервиса, которое описывает идентифицированную функциональность.

В некоторых вариантах осуществления абстрактное описание сервиса упорядочено как дерево информации описания, описывающей сетевой сервис. На фиг.2 показан пример абстрактного описания 201 сервиса. Описание 201 сервиса включает в себя тип 202 сервиса, указывающий тип (например, CLR) сетевого сервиса, описываемого описанием 201 сервиса. Указанный тип сервиса может быть типом, который реализует интерфейсы и методы для обеспечения описываемого сетевого сервиса. Тип 202 сервиса может представлять собой тип, который был идентифицирован из анализа типа сервиса и соответствующей информации конфигурирования сервиса.

Описание 201 сервиса также включает в себя атрибуты IServiceBehaviors 203A и 203В. Однако один или более атрибутов IServiceBehaviors также могут быть включены. Атрибуты IServiceBehaviors 203A и 203В представляют поведения, которые сетевой сервис, описываемый описанием 201 сервиса, должен реализовывать в рабочем цикле, например, дросселирование сервиса (т.е. ограничение числа конкурентных запросов для описываемого сервиса). Атрибуты IServiceBehaviors 203A и 203В могут представлять собой поведения, которые были идентифицированы из анализа типа сервиса и соответствующей информации конфигурирования сервиса.

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

Адрес конечной точки представляет собой электронный адрес (например, унифицированный указатель информационного ресурса - URL) для коммуникации с описываемым сервисом (т.е. указания, где находится описываемый сервис). Например, адрес 214 конечной точки может быть электронным адресом для коммуникации с сетевым сервисом, описываемым описанием 201 сервиса. Адрес 214 конечной точки может быть адресом конечной точки, который был идентифицирован из анализа типа сервиса и соответствующей информации конфигурирования сервиса.

Связывание указывает, каким образом данные должны передаваться при коммуникации с описываемым сервисом. Связывание может включать в себя множество различных элементов связывания, таких, например, как транспортный элемент связывания (например, использование протокола НТТР или протокола ТСР), элемент связывания для кодирования (например, использование UTF-8 или UTF-16), элемент связывания для защиты (например, использование заданного типа шифрования) и т.д., применимых к различным характеристикам передачи. Например, связывание 216 может указывать, каким образом данные должны передаваться к сетевому сервису, описываемому описанием 201 сервиса. Связывание 216 может представлять собой связывание, которое было идентифицировано из анализа типа сервиса и соответствующей информации конфигурирования сервиса.

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

Таким образом, описание 217А контракта может указывать шаблоны взаимодействия сообщений для коммуникации с сетевым сервисом, описываемым описанием 201 сервиса. Некоторые операции (например, операция 218) включают в себя одно сообщение (например, сообщение 228), например, сообщение ввода или сообщение вывода. Другие операции (например, операция 219) включают в себя два сообщения (например, сообщения 229 и 239), например, сообщение запроса и сообщение ответа.

Хотя на чертеже не показано, но описание 217В контракта может также указывать шаблоны взаимодействия сообщений для коммуникации с сетевым сервисом, описываемым описанием 201 сервиса. Таким образом, описание 217В контракта может также включать в себя одну или более операций, причем каждая операция включает в себя одно или более сообщений.

Согласно фиг.1 модуль 107 экспорта метаданных может экспортировать абстрактное описание сервиса, например описание 201 сервиса, в соответствующие метаданные, например в документ на языке описания веб-сервиса (WSDL). В общем случае, модуль 107 экспорта метаданных конфигурируется для анализа абстрактного описания сервиса и включения абстрактного описания сервиса в соответствующие метаданные, например, в WSDL-документ.

Модуль 107 экспорта метаданных может исполнять модель объекта, которая преобразуется в последовательную форму на расширяемом языке разметки (XML). Таким образом, модуль 107 экспорта метаданных экспортирует абстрактное описание сервиса в объект, который представляет метаданные. Затем объект, который представляет метаданные, может быть преобразован в последовательную форму для получения исходных метаданных. Например, модуль 107 экспорта метаданных может экспортировать абстрактное описание сервиса в объект, который представляет WSDL-документ. Затем объект может быть преобразован в последовательную форму для получения WSDL-документа. Либо, модуль 107 экспорта метаданных может экспортировать исходный WSDL-документ (или другие метаданные).

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

Модуль 108 импорта метаданных может импортировать метаданные, например WSDL-документ, в соответствующее абстрактное описание сервиса, например, описание 201 сервиса. В общем случае, модуль 108 импорта метаданных конфигурируется для анализа метаданных и включения метаданных в соответствующее абстрактное описание сервиса.

Модуль 108 импорта метаданных может принимать объект, преобразуемый в последовательную форму на расширяемом языке разметки (XML). Например, модуль 108 импорта метаданных может принимать объект, который представляет WSDL-документ. Модуль 108 импорта метаданных может анализировать объект для идентификации функциональности представленного сетевого сервиса. Например, модуль 108 импорта метаданных может идентифицировать конечные точки, стеки каналов и связанности от типа сервиса и соответствующей информации конфигурирования сервиса. Модуль 108 импорта метаданных также может идентифицировать другие опции рабочего цикла, такие, как, например, опции защиты, опции надежной передачи сообщений, опции регистрации сообщений, опции дросселирования соединений и т.д. Из идентифицированной функциональности модуль 108 импортирования метаданных может создать абстрактное описание сервиса, которое описывает идентифицированную функциональность. Альтернативно, модуль 108 импортирования метаданных может принимать исходный WSDL-документ (или другие метаданные) и выполнять подобные операции для создания абстрактного описания сервиса.

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

Как модуль 107 экспорта метаданных, так и модуль 108 импорта метаданных могут быть конфигурированы для поддержки сменных модулей третьей стороны, что облегчает расширяемость при преобразовании от абстрактного описания сервиса к метаданным и наоборот. Сменные модули третьей стороны могут реализовывать настраиваемые преобразования между абстрактным описанием сервиса метаданными. Например, сменные модули могут облегчать преобразование предписаний режимов, определенных в соответствии со спецификациями веб-сервисов, таких, например, как WS-Policy, WS-RM (надежная передача сообщений). WS-Policy может использоваться для определения операторов XML-элементов, представляющих по существу любой режим, такой как, например, для выполнения шифрования определенным способом, обеспечения информации ключей и т.д. WS-RM может использоваться для определения характеристик надежной передачи сообщений, таких, например, как значения таймаутов.

Соответственно, расширяемые предписания режимов могут экспортироваться и импортироваться в/из WSDL-документа. Например, сменный модуль экспорта для модуля 107 экспорта метаданных может исследовать абстрактное описание сервиса на наличие элементов режимов и вводить соответствующие утверждения режимов в WSDL-документ. Таким образом, если связывание в абстрактном описании сервиса содержит определенный RM-элемент связывания, то сменный модуль экспорта может отыскать RM-элемент связывания и добавить соответствующее утверждение RM-режима в экспортируемые метаданные. С другой стороны, сменный модуль импорта для модуля 108 импорта метаданных может исследовать WSDL-документ на наличие утверждений режимов и вводить соответствующие элементы режима в абстрактное описание сервиса. Таким образом, если метаданные содержат утверждение RM-режима для элемента связывания, то сменный модуль импорта может отыскать утверждение RM-режима и добавить соответствующий определенный RM-элемент связывания в импортируемое абстрактное описание сервиса.

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