ИСПОЛЬЗОВАНИЕ АБСТРАКТНЫХ ОПИСАНИЙ ДЛЯ ГЕНЕРАЦИИ, ОБМЕНА И КОНФИГУРИРОВАНИЯ РАБОЧИХ ЦИКЛОВ СЕРВИСА И КЛИЕНТА Российский патент 2010 года по МПК G06N7/06 G06F13/16 

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

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

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

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

Сети в действительности стали настолько широко распространенными, что простая компьютерная система с сетевыми возможностями может осуществлять информационный обмен с любой из миллионов компьютерных систем, распределенных по всему миру, через конгломерат сетей, часто определяемый понятием «Интернет». Такие компьютерные системы могут включать в себя настольные, портативные, планшетные персональные компьютеры, персональные цифровые помощники (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-элемент связывания в импортируемое абстрактное описание сервиса.

Сменные модули также могут облегчать экспорт части абстрактного описания сервиса в произвольные XML-элементы и атрибуты в WSDL-документе и импорт произвольных XML-элементов и атрибутов в WSDL-документе в соответствующие части абстрактного описания сервиса.

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

Генератор 113 контракта может выполнять некоторую известную модель объекта, такую как, например, Модель объекта документа кода (CodeDOM). Провайдеры языка могут использовать CodeDOM для генерации кода (например, на C#, C++ или Visual Basic) на основе CodeDOM. Таким образом, абстрактное описание сервиса может быть преобразовано соответственно интерфейсам, которые представляют описание контракта, методам, которые представляют операции, и параметрам и возвращаемым значениям, которые представляют сообщения. Соответственно, исходный код в нейтральном формате языка может указывать, каким образом должен быть представлен XML-документ при отсылке, и может включать некоторую информацию защиты.

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

Компьютерная система 121 содержит модуль 124 загрузки канала, модуль 128 импорта метаданных, генератор 133 контракта, преобразователь 138 кода и компилятор 143.

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

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

Описание 301 канала также включает в себя атрибуты IChannelBehaviors 303A и 303В. Однако один или более атрибутов IChannelBehaviors также могут быть включены. Атрибуты IChannelBehaviors 303A и 303В представляют поведения, которые сетевой канал, описываемый описанием 301 канала, должен реализовывать в рабочем цикле, например, надежную передачу сообщений и авторизацию. Атрибуты IChannelBehaviors 303A и 303В могут представлять собой поведения, которые были идентифицированы из анализа типа канала и соответствующей информации конфигурирования сервиса.

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

Адрес 314 конечной точки может представлять собой электронный адрес для коммуникации с сетевым каналом, описываемым описанием 301 канала. Например, адрес 314 конечной точки может быть адресом конечной точки, который был идентифицирован из анализа типа сервиса и соответствующей информации конфигурирования сервиса. Связывание 316 может указывать, каким образом данные должны передаваться в сетевой канал, описываемый описанием 301 канала. Связывание 316 может представлять собой связывание, которое было идентифицировано из анализа типа сервиса и соответствующей информации конфигурирования сервиса. Описание 317 контракта может указывать шаблоны взаимодействия сообщений для коммуникации с сетевым каналом, описываемым описанием 301 сервиса. Некоторые операции (например, операция 318) включают в себя одно сообщение (например, сообщение 328), например, сообщение ввода или сообщение вывода. Другие операции (например, операция 319) включают в себя два сообщения (например, сообщения 329 и 339), например, сообщение запроса и сообщение ответа.

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

Генератор 133 контракта функционирует подобно генератору 113 контракта. Таким образом, генератор 133 контракта может преобразовывать абстрактное описание канала в модель объекта документа кода и соответствующую информацию конфигурирования сервиса. В общем случае, генератор 133 контракта конфигурируется для анализа абстрактного описания канала и превращения абстрактного описания канала в соответствующую модель объекта документа кода и информацию конфигурирования сервиса. Генератор 133 контракта может выполнять некоторую известную модель объекта для представления исходного кода в нейтральном к языку формате и затем преобразовывать код в поддерживаемый язык программирования. Таким образом, абстрактное описание канала может быть преобразовано соответственно интерфейсам, которые представляют описание контракта, методам, которые представляют операции, и параметрам и возвращаемым значениям, которые представляют сообщения. Соответственно, исходный код на нейтральном к формату языке может указывать, каким образом должен быть представлен XML-документ при отсылке, и может включать некоторую информацию защиты.

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

Преобразователь 138 кода конфигурируется для преобразования модели объекта документа кода в исходный код на языке программирования. Преобразователь 138 кода может быть частью той же модели объекта, которая используется для генерации модели объекта документа кода. Компилятор 143 конфигурируется для компилирования исходного кода языка программирования в компилированный код типа канала. Компилятор 143 может представлять собой компилятор C#, C++ или Visual Basics, и может представлять собой часть интегрированной среды разработки (IDE).

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

Способ 500 включает в себя действие оценки типа сервиса и соответствующего конфигурирования сервиса для реализации сервиса в соответствии с заданной моделью программирования (действие 501). Например, модуль 104 загрузки сервиса может получать доступ к типу 102 сервиса и конфигурации 103. Тип 102 сервиса может представлять компилированный код, который был компилирован из исходного кода языка программирования (C#, C++, Visual Basic и т.д.). Интерфейсы и методы, включенные в тип 102 сервиса, могут быть аннотированы атрибутами, описывающими сервис. Конфигурация 103 может включать в себя дополнительную информацию конфигурирования сервиса, описывающую сервис.

Способ 500 включает в себя действие анализа типа сервиса и соответствующей конфигурации сервиса для идентификации информации описания (действие 502). Например, модуль 104 загрузки сервиса может анализировать тип 102 сервиса и конфигурацию 103, чтобы идентифицировать информацию описания, соответствующую сервису, представленному типом 102 сервиса. Идентифицированная информация описания может включать в себя множество опций соединения и/или коммуникационного протокола, таких как, например, тип сервиса, поведения сервиса (например, опции защиты, опции надежной передачи сообщений, опции регистрации сообщений, опции дросселирования соединений и т.д.) и конечные точки сервиса (например, адреса конечных точек, связывания и описания контрактов, включая операции и сообщения).

Способ 500 включает в себя действие генерации дерева описания сервиса для сервиса на основе идентифицированной информации описания (действие 503). Например, модуль 104 загрузки сервиса может создать описание 106 сервиса на основе информации описания, идентифицированной из типа 102 сервиса и конфигурации 103. Описание 106 сервиса может представлять собой дерево описания сервиса, подобное описанию 201 сервиса. Идентифицированный тип сервиса, идентифицированные поведения сервиса и идентифицированные конечные точки сервиса могут быть созданы в соответствующих местоположениях в соответствующей структуре дерева.

На фиг.6 представлена блок-схема способа 600 преобразования абстрактного описания сервиса, которое описывает сетевой сервис, в код, представляющий сетевой сервис. Способ 600 описан ниже по отношению к компонентам и данным, изображенным в компьютерной архитектуре 100.

Способ 600 включает в себя действие обращения к дереву описания сервиса для получения сервиса (действие 601). Например, модуль 107 экспорта метаданных может получить доступ к описанию 106 сервиса. Альтернативно, генератор 113 контракта может получить доступ к описанию 106 сервиса.

Способ 600 включает в себя действие преобразования дерева описания сервиса в отличающийся формат представления, так чтобы информация описания могла совместимым образом переноситься в модуль, который обрабатывает информацию описания сервиса, определенную в соответствии с отличающимся форматом представления (действие 602). Например, модуль 107 экспорта метаданных может экспортировать описание 106 сервиса в метаданные 109 (или в объект, представляющий метаданные 109), так что модуль импорта метаданных (например, модуль 128 импорта метаданных) может затем импортировать метаданные 109 (или объект, представляющий метаданные 109) назад, в описание сервиса (или канала).

Альтернативно, генератор 113 контракта может преобразовать описание 106 сервиса в модель 114 объекта документа кода и конфигурацию 116. Модель 114 объекта документа кода может затем использоваться для генерации исходного кода на языке программирования. Разработчик может затем модифицировать код, как это необходимо, чтобы гарантировать соответствующую функциональность или добавить дополнительную функциональность. Затем может компилироваться исходный код на языке программирования. Конфигурация 116 включает в себя, по меньшей мере, поднабор информации конфигурирования из конфигурации 103. Например, конфигурация 116 может включать в себя соответствующие настройки конфигурации для формирования канала для коммуникации с рабочими циклами сервиса на основе типа 102 сервиса.

Способ 600 включает в себя действие вывода информации описания в отличающемся формате представления (действие 603). Например, модуль 107 экспорта метаданных может послать метаданные 109 в модуль 128 импорта метаданных. Альтернативно, генератор 113 контракта может послать модель 114 объекта документа кода и конфигурацию 116 в компьютерную систему 121. Либо метаданные 109 и модель 114 объекта документа кода и конфигурация 116 могут быть затем преобразованы, модифицированы и/или компилированы в канал в компьютерной системе 121.

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

Способ 700 включает в себя действие обращения к дереву описания сервиса для получения сервиса, причем дерево описания сервиса генерировано из информации описания, которая была получена путем анализа из соответствующего типа сервиса и конфигурации сервиса (действие 701). Например, компьютерная система 101 может получать доступ к описанию 106 сервиса, которое было генерировано из информации описания, полученной путем анализа из типа 102 сервиса и конфигурации 103 сервиса.

Способ 700 включает в себя действие вызова метода хоста инициализации сервиса, связанного с деревом описания сервиса (действие 702). Например, компьютерная система 101 может вызвать модуль 111 инициализации сервиса, связанный с описанием 106 сервиса. В некоторых вариантах осуществления хостом инициализации сервиса является исполняемый код, включенный в описание 106 сервиса. Таким образом, описание 106 сервиса может вызвать модуль 111 инициализации сервиса.

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

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

Способ 800 включает в себя действие обращения к метаданным, описывающим сервис (действие 801). Например, модуль 128 импорта метаданных может получить доступ к метаданным 109. Способ 800 включает в себя действие импорта метаданных в дерево описания канала для некоторого канала (действие 802). Например, модуль 128 импорта метаданных может импортировать метаданные 109 в описание 126 канала.

Способ 800 включает в себя действие генерирования модели объекта документа кода и соответствующей конфигурации сервиса из дерева описания канала (действие 803). Например, генератор 133 контракта может генерировать модель 134 объекта документа кода и конфигурацию 136 сервиса из описания 126 канала.

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

Модуль 124 загрузки канала может затем проанализировать тип 132 канала и конфигурацию 136 для генерирования уточненного описания 126 канала. Затем, описание 126 канала может вызвать модуль 131 инициирования канала для инициализации канала 132 в соответствии с информацией описания, полученной путем анализа из типа 132 канала и конфигурации 136. Канал 132 и рабочий цикл 112 могут затем осуществлять информационный обмен для использования сервиса, определенного типом 102 сервиса.

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

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

Как показано на фиг.4, приведенная для примера система для реализации изобретения включает в себя универсальное вычислительное устройство в форме компьютерной системы 420, содержащий блок 421 обработки, системную память 422 и системную шину 423, которая связывает различные системные компоненты, включая системную память 422, с блоком 421 обработки. Блок 421 обработки может исполнять команды, предназначенные для исполнения компьютером, для реализации функций компьютерной системы 420, включающих признаки настоящего изобретения. Системная шина 423 может быть любой из различных типов шинных структур, включая шину памяти или контроллер памяти, шину периферийных устройств, локальную шину, использующую любую из разнообразных шинных архитектур. Системная память включает в себя постоянную память (ROM, ПЗУ) 424 и оперативную память (RAM, ОЗУ) 425. Базовая система ввода/вывода (BIOS) 426, содержащая базовые подпрограммы, которые способствуют переносу информации между элементами в компьютерной системе 420, например, при запуске, в типовом случае сохранена в ПЗУ 424.

Компьютерная система 420 также может содержать накопитель 427 на жестком диске для считывания с жесткого магнитного диска 439 или записи на него, накопитель 428 на магнитных дисках для считывания со съемного магнитного диска 429 или записи на него, и накопитель 430 на оптических дисках для считывания со съемного оптического диска 431 (например, CD-ROM или иные оптические носители записи) или записи на него. Накопитель 427 на жестком диске, накопитель 428 на магнитных дисках и накопитель 430 на оптических дисках могут быть соединены с системной шиной 423 посредством интерфейса 432 накопителя на жестком диске, интерфейса 433 накопителя на магнитных дисках и интерфейса 434 накопителя на оптических дисках, соответственно. Накопители и связанные с ними машиночитаемые носители обеспечивают энергонезависимое хранение машиночитаемых команд, структур данных, программных модулей и других данных для компьютерной системы 420. Хотя при описании машиночитаемых носителей даются ссылки на жесткий диск 439, съемный магнитный диск 429 и съемный оптический диск 431, специалистам в данной области техники должно быть понятно, что могут использоваться другие типы машиночитаемых носителей записи для хранения данных, такие как кассеты на магнитных лентах, карты флэш-памяти, цифровые видеодиски, картриджи Бернулли, ОЗУ, ПЗУ и т.п.

Средство программного кода, содержащее один или более программных модулей, может быть сохранено на жестком диске 439, магнитном диске 429, оптическом диске 431, ПЗУ 424 или ОЗУ 425, включая операционную систему 435, одну или более прикладных программ 436, другие программные модули 437 и программные данные 438. Пользователь может вводить команды и информацию в компьютерную систему 420 посредством клавиатуры 440 и координатно-указательного устройства 442 или других устройств ввода (не показаны), таких как микрофон, джойстик, игровая панель, сканер и т.п. Эти и другие устройства ввода могут соединяться с блоком 421 обработки через интерфейс 446 ввода/вывода, связанный с системной шиной 423. Интерфейс 446 ввода/вывода логически представляет любой из широкого разнообразия различных интерфейсов, таких как интерфейс последовательного порта, PS/2-интерфейс, интерфейс параллельного порта, интерфейс универсальной последовательной шины (USB) или IEEE 1394-интерфейс (т.е. интерфейс FireWire), или может представлять комбинацию различных интерфейсов.

Монитор 447 или иное устройство отображения также соединено с системной шиной 432 через видеоинтерфейс 448. Другие периферийные устройства вывода (не показаны), такие как громкоговорители и принтеры, также могут быть соединены с компьютерной системой 420.

Компьютерная система 420 может работать в сетях, например в компьютерной сети предприятий, домашней сети, интранете и/или в Интернете. Компьютерная система может обмениваться по сетям данными с внешними источниками, такими, например, как удаленные компьютерные системы, удаленные приложения и/или удаленные базы данных.

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

Аналогичным образом, компьютерная система 420 содержит интерфейс 446 ввода/вывода, через который компьютерная система 420 получает данные от внешних источников и/или передает данные к внешним источникам. Интерфейс 446 ввода/вывода связан с модемом 454 (например, стандартным модемом, кабельным модемом или модемом цифровой абонентской линии (DSL)) через линию 459, посредством которой компьютерная система 420 получает данные от внешних источников и/или передает данные к внешним источникам. Как показано на фиг.4, интерфейс 446 ввода/вывода и модем 454 обеспечивают обмен данными с удаленной компьютерной системой 493 по линии 452. Линия 452 представляет часть сети, а удаленная компьютерная система 493 представляет узел сети.

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

В соответствии с настоящим изобретением модули включающие в себя модули загрузки сервисов, генераторы контрактов, модули импорта метаданных, модули экспорта метаданных, инициализации сервисов, рабочие циклы сервисов и каналы, а также ассоциированные данные, включая типы сервисов, конфигурацию, модели объектов документов кода, метаданные, описания сервисов и описания каналов, могут быть сохранены, и к ним может быть обеспечен доступ из любого из машиночитаемых носителей для хранения данных, связанных с компьютерной системой 420. Например, части таких модулей и части ассоциированных программных данных могут быть включены в операционную систему 435, прикладные программы 436, программные модули 437 и/или программные данные 438, для хранения в системной памяти 422.

Если устройство массовой памяти, такое, например, как магнитный жесткий диск 439, связывается с компьютерной системой 420, такие модули и ассоциированные программные данные могут также сохраняться в устройстве массовой памяти. В сетевой среде программные модули, изображенные по отношению к компьютерной системе 420, или их части, могут сохраняться в удаленных устройствах памяти, таких как системная память и/или устройства массовой памяти, связанные с удаленной компьютерной системой 483 и/или удаленной компьютерной системой 493. Исполнение таких модулей может выполняться в распределенной среде, как описано ранее.

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

Изобретение относится к вычислительной технике, а конкретнее к распределенным моделям прикладного программирования. Техническим результатом является обеспечение минимизации факторов несовместимости между рабочим циклом клиента и рабочим циклом сервиса. Компьютерная система анализирует компилированный код и, возможно, факультативную информацию конфигурации для реализации сервиса и преобразует компилированный код и информацию конфигурации в абстрактное описание сервиса. Абстрактное описание сервиса может затем преобразовываться в модель объекта документа кода и информацию конфигурирования сервиса или экспортироваться как метаданные. Соответствующий рабочий цикл сервиса может быть инициирован вызовом модуля инициализации сервиса, включенного в абстрактное описание сервиса. Модель объекта документа кода и информация конфигурации и/или метаданные могут быть перенесены на другую компьютерную систему. Другая компьютерная система может использовать модель объекта документа кода и информацию конфигурации и/или импортировать метаданные, чтобы способствовать инициализации совместимого канала для информационного обмена с рабочим циклом сервиса. 3 н. и 17 з.п. ф-лы, 8 ил.

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

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

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

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

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

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

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

8. Способ по п.1, в котором действие создания дерева описания сервиса для сервиса на основе идентифицированной информации описания содержит действие создания представления поведения сервиса.

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

10. Способ по п.9, в котором действие доступа к дереву описания сервиса для сервиса содержит действие доступа к поведениям для сервиса.

11. Способ по п.9, в котором действие доступа к дереву описания сервиса для сервиса содержит действие доступа к описанию контракта для сервиса, включающего в себя операции и сообщения.

12. Способ по п.9, в котором действие преобразования дерева описания сервиса в другой формат представления содержит действие экспорта дерева описания сервиса в метаданные.

13. Способ по п.12, в котором действие экспорта дерева описания сервиса в метаданные содержит действие экспорта дерева описания сервиса в WSDL-документ.

14. Способ по п.12, в котором действие экспорта дерева описания сервиса в метаданные содержит действие, в котором сменный модуль третьей стороны вводит утверждения режима в метаданные.

15. Способ по п.12, в котором действие экспорта дерева описания сервиса в метаданные содержит действие, в котором сменный модуль третьей стороны вводит произвольный XML-документ в метаданные.

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

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

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

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

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