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

Изобретение относится к способу разработки и использования объекта привязывания сообщений к аспектам обмена данными. Техническим результатом является повышение безопасности при обмене данными. В способе разработчик представляет и выбирает элементы привязывания, которые в конечном счете будут использованы, чтобы создавать канал обмена данными рабочих модулей для передачи сообщения между конечной точкой клиента и службы. После приема пользовательского ввода создаются метаданные, заводские настройки канала и заводские настройки приемника. Метаданные описывают элементы привязывания и предоставляют абстрактное представление стека протоколов, который реализует аспекты связи в рабочем модуле. Заводские настройки канала сконфигурированы, чтобы использовать набор метаданных в рабочем модуле, чтобы генерировать канал обмена данными рабочих модулей. Заводские настройки приемника сконфигурированы, чтобы допускать канал обмена данными рабочих модулей и демультиплексировать аспекты связи, чтобы обрабатывать сообщение в конечной точке службы. 3 н. и 17 з.п. ф-лы, 12 ил.

 

Область техники, к которой относится изобретение

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

Уровень техники

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

Связанные со службами архитектуры дают возможность приложениям совместно использовать данные и в большей степени активировать возможности других приложений безотносительно того, как эти приложения были созданы, на какой операционной системе или платформе они выполняются и какие устройства используются, чтобы осуществлять доступ к ним. Типично эти системы активируются по Интернету посредством стандартных протоколов, в том числе SOAP (простой протокол объектного доступа), XML (расширяемый язык разметки), UDDI (универсальное описание, поиск и взаимодействие), WSDL (язык описания веб-служб) и т.д. Хотя эти службы остаются независимыми друг от друга, они могут неявно связывать их в совместную группу, которая выполняет конкретную задачу.

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

Связанные со службами понятия (к примеру, шаблоны адресов, привязок и взаимодействия посредством сообщений), описывающие службу, могут быть включены в модель программирования. К модели программирования затем можно осуществлять доступ потребителям услуг, которые хотят обмениваться данными с описанной службой. В целом, связанные со службами понятия (к примеру, модель программирования) описаны в соответствии с определенным связанным со службами стандартом, такими как, например, распределённая модель компонентных объектов (DCOM), общая архитектура посредника запросов к объектам (CORBA) или веб-службы. Веб-службы могут быть дополнительно заданы в соответствии с различными спецификациями веб-служб, такими как, например, язык описания веб-служб (“WSDL”), структура политик веб-служб (WS-Policy) и т.д.

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

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

Дополнительно, текущие NPDL привязывают контракт к ограниченному набору аспектов обмена данными, которые включают в себя шаблон обмена сообщениями (к примеру, односторонний, только запрос, публичные подписки, дуплексный и т.д.), механизм кодирования или формат сообщения (к примеру, огибающая SOAP) и тип передачи для обмена сообщениями со службой (к примеру, HTTP (протокол передачи гипертекстовых файлов), FTP (протокол передачи файлов), SMTP (простой протокол электронной почты), TCP (протокол управления передачей), UDP (протокол передачи дейтаграмм пользователя), SMS (служба коротких сообщений), SNA (архитектура сетевых систем), GPRS (общая служба пакетной радиопередачи) и т.д.). Дополнительные аспекты передачи данных (к примеру, безопасность, надежность, контекстный поток, поток транзакций, параметры ведения журналов, параметры плавного регулирования соединений и т.д.) должны быть заданы в других документах (к примеру, WS Policy) или сконфигурированы вне клиента и службы.

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

Помимо этого, поскольку не все аспекты связи предусмотрены в NPDL, и клиент, и служба должны иметь значительное количество кода в каждом приложении, чтобы использовать и поддерживать аспекты связи. Например, в случае контекста безопасности клиенту необходимо иметь код, который: (1) распознает, что обмен данными с приложением службы должен использовать маркер контекста безопасности; (2) запрашивает этот маркер у стороны, выдающей маркер; (3) предоставляет надлежащую информацию в рамках запроса; (4) сохраняет маркер контекста безопасности для будущего обмена данными; и (5) ссылается на соответствующий базовый маркер и совместно используемый секрет при приеме данных от службы с помощью маркера контекста безопасности. Так же, приложение службы должно быть закодировано таким образом, чтобы при приеме защищенных сообщений от клиента на основе маркера контекста безопасности приложение службы могло: (1) идентифицировать базовый маркер; (2) определять надлежащий сеансовый ключ, ассоциативно связанный с базовым маркером, чтобы дешифровать сообщение; (3) сохранять маркер контекста безопасности; и (4) повторно использовать маркер контекста безопасности, чтобы шифровать сообщения и подписывать их для безопасности доставки клиенту.

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

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

Раскрытие изобретения

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

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

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

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

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

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

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

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

Фиг. 2A иллюстрирует пример элементов привязывания, сгруппированных в соответствии с примерными вариантами осуществления;

Фиг. 2B иллюстрирует пример пользовательского интерфейса для выбора стандартных привязок;

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

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

Фиг. 5 иллюстрирует блок-схему последовательности операций способа предоставления разработчику списка широко используемых и совместимых объектов привязывания в соответствии с типичными вариантами осуществления настоящего изобретения;

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

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

Осуществление изобретения

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

Перед подробным описанием примерных вариантов осуществления настоящего изобретения полезно определить некоторые термины, используемые в оставшейся части заявки. "Аспекты связи" соответствуют конкретному набору формальных правил для переноса сообщений между конечными точками в распределенной системе. Примеры аспектов связи включают в себя, но не только: (1) фактическую спецификацию семейства веб-служб (WS) (к примеру, WS-Security, WS-Reliable Messaging, WS-Atomic Transactions и т.д.); (2) конкретный механизм сетевой передачи данных (к примеру, HTTP, TCP, UDP и т.д.); (3) конкретный механизм сетевого кодирования сообщения (к примеру, текстовое, двоичное и т.д.); и (4) различные другие протоколы передачи. Эти аспекты связи предназначены, чтобы сочетаться друг с другом, чтобы создать "стек протоколов", который может быть реализован посредством использования описанного ниже канала обмена данными рабочих модулей. Каждый стек протоколов типично включает в себя, по меньшей мере, аспект транспортного механизма и аспект механизма кодирования (к примеру, сообщение SOAP по TCP). Заметим, тем не менее, что каждый аспект связи сам является протоколом. Следовательно, "стек протоколов" при использовании в данном документе должен быть широко истолкован, чтобы включать в себя один или более аспектов связи.

Абстрактное представление аспекта связи называют "элементом привязывания", который может быть использован, чтобы создать канал обмена данными рабочих модулей, чтобы реализовать аспекты связи (и, таким образом, стек протоколов). Набор элементов привязывания указывается ссылкой в данном документе как "объект привязывания", который представляет абстрактное представление конкретного стека протоколов или сочетания аспектов связи.

Настоящее изобретение, в общем, предоставляет системы, способы и вычислительные программные продукты для создания и использования объектов привязывания, чтобы переносить сообщения между конечными точками. Фиг. 1A иллюстрирует распределенную систему 100 с различными компонентами, которые могут быть использованы, чтобы создавать и использовать объекты привязывания для переноса сообщения от клиента к службе в соответствии с типичными вариантами осуществления. Как показано, разработчику службы может быть предоставлен пользовательский интерфейс 112 в приложении 110 разработчика для выбора элементов 115 привязывания. Эти элементы 115 привязывания представлены легкодоступным способом и могут предоставлять различные описания, чтобы помочь пользователям в их выборе. Например, пользовательский интерфейс может предлагать пользователю информацию, например "вам требуется безопасность?", "вам требуется надежность?" и т.д. На основе пользовательского ввода могут последовать другие варианты или вопросы. Дополнительно, как описано подробнее ниже, эти элементы привязывания могут быть объединены в группы или составлены в стандартные объекты привязывания в ходе процесса представления. После этого разработчик может выбирать из множества различных вариантов, предоставленных с помощью пользовательского интерфейса 112.

Заметим, что настоящее изобретение также поддерживает задание элементов привязывания и/или объектов привязывания по умолчанию. Следовательно, если разработчик не выбирает элементы привязывания, а просто продолжает, объект привязывания по умолчанию, который включает в себя один или более элементов 115 привязывания, может быть автоматически выбран для пользователя. По существу, использование термина "выбранный пользователем" или другого аналогичного написания в данном документе должно быть широко истолковано, чтобы включать в себя элемент или объект привязывания по умолчанию. В этом случае пользовательский ввод, принятый для выбора элемента 115 привязывания по умолчанию, может быть введен, чтобы продолжать без выбора элементов привязывания (или других объектов привязывания, как описано ниже).

После того как разработчик завершил свой выбор, объект привязывания создается из объединенных выбранных элементов привязывания. С помощью объекта привязывания составляется описание 120 привязывания, которое используется конструктором привязывания (не показан), чтобы создать несколько различных примерных вариантов осуществления. Во-первых, описание 120 привязывания может быть использовано, чтобы создавать набор метаданных 125, которые являются описанием объекта привязывания, который может быть сохранен на запоминающем устройстве 105. Несмотря на то, что эти метаданные могут размещаться в службе 140, она также может размещать документ NPDL (к примеру, документ WSDL), сохраненный в каталоге служб, к примеру, который использует универсальное описание, поиск и взаимодействие (UDDI).

Во-вторых, описание 120 привязывания также может быть использовано, чтобы создать заводские настройки 135 канала, которые используют метаданные 125, чтобы создавать канал обмена данными рабочих модулей 165. Каналы (к примеру, канал 165 обмена данными рабочих модулей) предоставляют абстрагирование от ядра для обмена сообщениями между клиентом 130 и службой 140. В частности, каналы (к примеру, канал 165 обмена данными рабочих модулей) представляют абстрагирование от ввода-вывода и отвечают за: (1) прием данных приложений или сообщений 170 (к примеру, сообщений SOAP); (2) реализацию различных аспектов связи (к примеру, надежности, безопасности, кодирования и т.д.); (3) форматирование сообщения 170 для передачи в соответствии с аспектами связи; и (4) передачу сообщения 170 по сети. Заметим также, что канал 165 обмена данными рабочих модулей может поддерживать и сохранять плавное регулирование и управление потоком данных с помощью основанного на выталкивании механизма в аспектах связи.

Помимо этого, описание 120 привязывания используется, чтобы создавать заводские настройки 145 приемника для службы 140. На стороне службы 140 заводские настройки 170 приемника прослушивают конкретный сетевой адрес на новые сообщения, к примеру сообщение 170, и предоставляет механизм для создания приемника 150, который обменивается данными с конкретной конечной точкой 160 службы 140. Заводские настройки 145 приемника затем могут демультиплексировать часть сообщения 170 и отправить сообщение 170 соответствующему приемнику 150.

Заметим, что возможность получать метаданные 125 (к примеру, документ WSDL) от службы 140 и последующее генерирование канала 165 обмена данными рабочих модулей является важной частью удобства использования, предусмотренной в настоящем изобретении. Например, разработчик может подобрать элементы 115 привязывания для службы 140, а затем другой разработчик может удаленно запросить у службы 140 ее метаданные 125. Из этих метаданных 125 приложение может сгенерировать канал 165 обмена данными рабочих модулей и использовать его, чтобы передавать сообщения службе 140 в соответствии с выбором разработчиком службы элементов 115 привязывания.

Дополнительно заметим, что хотя вышеуказанные объекты 125, 135, 145, созданные с помощью описания 120 привязывания, описаны в конкретном порядке, настоящее изобретение не ограничено порядком и распределением по времени генерирования этих объектов. Например, метаданные 125, заводские настройки 135 канала и заводские настройки 145 приемника могут быть одновременно созданы, созданы отдельно в любом порядке или использованы любые сочетания.

Вне зависимости от того, когда созданы объекты 125, 135, 145 связи, чтобы осуществить доступ к службе 140, клиент 130 активно запрашивает 180 у канала из заводских настроек 135 канала конкретную службу 140. Заводские настройки 135 канала затем осуществляют доступ к метаданным 125 с запоминающего устройства 105 и могут использовать это описание объекта привязывания, чтобы инициировать канал 165 обмена данными в реальном времени. Хотя конкретные детали канала 165 обмена данными рабочих модулей не относятся к данному примерному варианту осуществления, стоит отметить, что канал 165 обмена данными рабочих модулей типично составлен из компонентов связи, соответствующих различным аспектам связи (которые, когда объединены и реализованы, комплектуют стек протоколов). Например, канал 165 обмена данными рабочих модулей может включать в себя компонент безопасности, компонент надежности, транспортный компонент и компонент кодирования. Эти компоненты затем объединяются, чтобы создать общий канал 165 обмена данными рабочих модулей для реализации протокола.

После приема запроса 180 заводские настройки 135 канала возвращают дескриптор 175 (которым может быть канал 165 обмена данными рабочих модулей или его идентификатор) клиенту 130, так чтобы клиент 130 мог надлежащим образом ссылаться и использовать канал 165 обмена данными рабочих модулей, чтобы передавать сообщение 170 службе 160 в соответствии с указанными аспектами связи. Заметим, что хотя настоящее изобретение получило эти аспекты связи из выбранных элементов привязывания от разработчика, текущий вариант осуществления не ограничен этим процессом выбора. Например, метаданные 125 могут представлять объект привязывания по умолчанию, заданный посредством конфигурационной семантики системным администратором на стороне службы. Следовательно, для данного варианта осуществления важно именно использование метаданных 125 для создания канала 165 обмена данными рабочих модулей. Заметим, тем не менее, что канал 165 обмена данными рабочих модулей должен типично включать в себя, по меньшей мере, аспект транспортного механизма и аспект механизма кодирования, как упоминалось выше.

Вне зависимости от того, как инициирован канал 165 обмена данными рабочих модулей, на стороне службы 140 заводские настройки 145 приемника прослушивают канал 165 обмена данными рабочих модулей и создают соответствующий приемник 150. Приемник 150 представляет абстрагирование для прослушивания и приема новых каналов 165 обмена данными рабочих модулей на стороне службы 140. Когда новый канал (к примеру, канал 165 обмена данными рабочих модулей) распознан приемником 150, конечная точка 160 может вызвать "канал приема", который дает возможность приемнику демультиплексировать сообщение 170 в соответствии с аспектами связи, реализованными каналом 165 обмена данными рабочих модулей. Альтернативно, конечная точка 160 может "перевести в состояние ожидания" невыполненный прием начала, который позднее может быть завершен после того, как сообщения были обработаны. В любом случае, после этого конечная точка 160 может обрабатывать сообщение надлежащим образом и отправлять надлежащий ответ при необходимости.

Заметим, что в зависимости от шаблона обмена сообщениями между клиентом 130 и службой 140 канал 165 обмена данными рабочих модулей может быть сгенерирован из службы 140 клиенту 130. Например, шаблон дуплексного обмена сообщениями между клиентом 130 и службой 140, обратный канал от службы 140 к клиенту 130, возможно, должен быть сгенерирован для такого обмена данными. Следовательно, вышеописанный процесс связи, возможно, должен быть переключен таким образом, чтобы служба 140 действовала как клиент 130, и наоборот. Дополнительно, могут быть другие способы реализации вышеупомянутых примерных вариантов осуществления. Например, метаданные 125, заводские настройки канала 135 и заводские настройки 145 приемника могут быть автоматически сгенерированы без описания привязывания. Следовательно, конкретные реализации для генерирования канала 165 обмена данными рабочих модулей и использования этого канала связи, чтобы передавать сообщения, используются только в иллюстративных целях и не предназначены, чтобы ограничивать или иным образом сужать область применения настоящего изобретения, если иное не заявлено явно.

Фиг. 2A иллюстрирует общий пользовательский интерфейс 101, в котором различные элементы привязывания были сгруппированы согласно трем основным характеристикам. Например, одна группировка 182 включает в себя группировку по надежности 186, которая может иметь несколько элементов 184 привязывания (показываемых как группировка по надежности A и группировка по надежности B 196). Эти элементы 196 привязывания по надежности могут быть из семейства WS, привязанного к конкретному транспортному механизму (к примеру, HTTP), или они могут быть собственными 196 элементами привязывания по надежности. Такая организация элементов 184 привязывания на группы 182 облегчает задание элементов 184 привязывания и представляет наиболее часто требуемые признаки этой конкретной группы 182.

Как показано, другие группировки могут включать в себя группу 188 безопасности с различными элементами 198 привязывания безопасности (к примеру, WS-Security, HTTPS, собственные и т.д.), группу 190 транспортных механизмов с элементами 181 привязывания транспортных механизмов (к примеру, HTTP, HTTPS, HTTPR, именованные каналы, TCP, UDP, обмен сообщениями из очереди, обмен интегрирующими сообщениями из очереди и т.д.) и группу 192 механизмов кодирования с элементами 183 привязывания механизмов кодирования (к примеру, текстовое, двоичное, SOAP, механизм оптимизации передачи сообщений (MTOM) и т.д.) и смешанную группу 194. Разумеется, могут быть другие группировки 182 (к примеру, группировка "WS Family"), представляющая другие стандартные аспекты связи. Фактически, как упомянуто подробнее ниже, группировки являются полностью подключаемыми и расширяемыми, позволяя собственные и другие группировки. По существу, вышеупомянутый список группировок и элементов привязывания в рамках каждой группы используется только в иллюстративных целях и не предназначен, чтобы ограничивать или иным образом сужать область применения настоящего изобретения, если иное не заявлено явно.

Последняя смешанная группировка 194 может включать в себя другие элементы 185 привязывания, которые не подходят точно ни в одну из конкретных групп 182. Например, другими элементами 185 привязывания может быть одно из следующего: (1) составной дуплексный элемент привязывания, в котором различные каналы связи могут быть объединены в один дуплексный канал; (2) элемент привязывания форматов сообщений для определения того, является сообщение RPC/литеральным, RPC/кодирование, документом/ литеральным, документом/закодированным; (3) элемент привязывания контекстных потоков для исполнения контекста; и (4) элемент привязывания потоков транзакций для потоков транзакций. Разумеется, могут быть другие элементы 185 привязывания, которые не подходят к другим стандартным группировкам 182. Следовательно, вышеуказанный список элементов 185 привязывания используется только в иллюстративных целях и не предназначен, чтобы ограничивать или иным образом сужать область применения настоящего изобретения, если иное не заявлено явно.

Фактически, как упоминалось выше, примерные варианты осуществления предусматривают, что группировки 182 и элементы 184 привязывания являются полностью подключаемыми и наращиваемыми. Т.е. группировки 182 и даже элементы 184 привязывания в каждой группе 182 могут быть удалены, вставлены или расширены, как требуется, без необходимости перезаписывать приложение для создания объектов привязывания. Заметим, что поскольку каждая из группировок 182 и элементы 184 привязывания в рамках каждой группировки являются подключаемыми и наращиваемыми, вышеуказанный список групп 182 и элементов 184 привязывания не предназначен, чтобы быть включающими в себя все. Следовательно, вышеуказанные списки и другие списки ниже используются только для иллюстративных целей и не предназначены, чтобы ограничивать или иным образом сужать область применения настоящего изобретения, если иное не заявлено явно.

Также заметим, что пользовательский интерфейс, показанный на фиг. 2A, является просто экраном элементов 184 привязывания, которые могут быть выбраны с помощью переключателя. Другие пользовательские интерфейсы, тем не менее, также доступны для настоящего изобретения. Например, элементы привязывания и/или группировки 182 могут отображаться отдельно или вместе. Более того, тип выбора может различаться от простого переключателя до, к примеру, флажка, выделения и т.д. Дополнительно, элементы привязывания (или объекты в зависимости от ситуации) могут быть предусмотрены для мастера, в котором следующие доступные параметры могут зависеть от ранее сделанного выбора. Помимо этого, когда разработчик приложения пишет класс, может появиться всплывающее окно, которое дает возможность пользователю прокручивать и автоматически завершать выбор параметров. Фактически, существует множество разработок пользовательских интерфейсов, несущих не себе различные эстетические аспекты для выполнения вышеуказанной функции. По существу, любой конкретный пользовательский интерфейс, описанный или показанный в данном документе, используется только в иллюстративных целях и не предназначен, чтобы ограничивать или иным образом сужать область применения настоящего изобретения, если иное не заявлено явно.

Хотя вышеописанные группировки 182 элементов 194 привязывания предоставляют гибкий механизм задания пользовательских объектов привязывания связи из набора стандартных признаков связи, эта гибкость создает значительную проблему наличия множества объектов привязывания (т.е. числа элементов привязывания и их возможных сочетаний). Фактически, если провести математические расчеты, число возможных объектов привязывания простирается до десятков тысяч. По существу, разработчики, незнакомые с конкретными элементами привязывания, могут не знать о том, какое сочетание лучше всего подходит под их конкретные потребности.

Следовательно, другие примерные варианты осуществления предоставляют стандартные привязывания, которые являются набором или сочетанием наиболее распространенных в отрасли типов объектов привязывания связи. Другими словами, примерные варианты осуществления предусматривают заготовленные объекты привязывания посредством сочетания различных элементов привязывания, для которых проверено, что они являются самыми распространенными типами. Фиг. 2B иллюстрирует примерный пользовательский интерфейс 102 для предоставления разработчику различных стандартных привязываний 104, из которых пользователь может выбирать. Пользователю также может быть представлен вариант выбора отдельных элементов привязывания, как показано на 106.

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

Одним типом текущего заготовленного объекта привязывания может быть объект привязывания базовых профилей, подходящий для связи с веб-службами, которые являются совместимыми с Web Services Interoperability: Basic Profile (WSI-BP). Этот объект привязывания использует текстовое кодирование по HTTP или HTTPS и поддерживает односторонние шаблоны обмена сообщениями (MEP) и шаблоны обмена сообщениями "запрос-ответ". Тем не менее, этот объект привязывания не поддерживает дуплексный MEP, транспортные сеансы и надежные сеансы.

Еще одним стандартным привязыванием может быть привязывание WS-профилей, которое подходит для безопасной, надежной связи с веб-службами, которые используют транспортный механизм набора или семейства WS по HTTP или HTTPS. Этот объект привязывания может кодировать в тексте или MTOM и поддерживает транспортные протоколы HTTP или HTTPS. Помимо этого, данный транспортный механизм предлагает надежный сеанс и односторонние MEP, MEP "запрос-ответ" и дуплексные MEP. Другим аналогичным привязыванием является двойное HTTP-привязывание WS-профилей, которое подходит для защищенной надежной связи с веб-службами, которые используют двухстороннюю HTTP-связь в сочетании с семейством WS.

Объекты TCP-привязывания NET-профилей могут быть доступны и подходят для защищенной надежной связи между службами, которые реализуют NET-семейство протоколов посредством транспортного механизма "двоичный по TCP" с или без TLS/SSL, используемых для защиты. Другим аналогичным заготовленным объектом привязывания может быть объект привязывания именованных каналов NET-профилей, который подходит для защищенной надежной связи между процессами на одной машине. Помимо этого, также может быть доступно двойное TCP-привязывание NET-профилей, которое подходит для защищенной надежной связи между службами, которые реализуют NET-семейство протоколов по двухсторонним TCP-соединениям. Более того, также доступны привязывания обмена сообщениями из очереди NET и защищенного обмена сообщениями из очереди, которые подходят для защищенной надежной связи между службами, которые допускают использование различных механизмов безопасности транспортного уровня. Также доступно привязывание интеграции из очереди, которое подходит для привязывания приложения, которое взаимодействует с существующим приложением организации очереди.

Другие стандартные типы объектов привязывания связи могут включать в себя промежуточные привязывания, к примеру промежуточные привязывания HTTP, TCP и именованных каналов. Каждый из них подходит для привязывания промежуточного SOAP, который прослушивает HTTP, TCP или именованные каналы, соответственно.

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

Фиг. 3A-E иллюстрируют, как различные группировки и стандартные привязывания, описанные ранее, могут быть представлены в пользовательском интерфейсе на основе мастеров. Например, фиг. 3A иллюстрирует пользовательский интерфейс 300 мастера привязываний, который дает возможность выбора привязываний 305 безопасности, если такие существуют. Аналогично, фиг. 3B иллюстрирует пользовательский интерфейс 300 мастера привязываний, который дает возможность выбора различных элементов 310 привязывания безопасности. На фиг. 3C пользовательский интерфейс 300 мастера привязывания дает возможность пользователю выбирать из множества транспортных механизмов 315 и механизмов кодирования 320. Как описано выше, фиг. 3D предоставляет мастер 300 привязываний со смешанной группировкой 325, который включает в себя необязательные элементы привязывания, которые могут быть выбраны вместе с другими привязываниями 330. Наконец, фиг. 3E представляет пользовательский интерфейс 300 мастера привязываний со списком стандартных привязываний 325, описанных выше. Разумеется, этот пользовательский интерфейс 300 может включать в себя вариант создания собственного привязывания 340.

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

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

Фиг. 4-6 иллюстрируют блок-схемы последовательности операций способа для различных вариантов осуществления настоящего изобретения. Последующее описание фиг. 4-6 иногда ссылается на соответствующие элементы из фиг. 1A-C и 3A-E, хотя ссылка может быть сделана на конкретный элемент из этих рисунков, эти элементы используются только для иллюстративных целей и не предназначены, чтобы ограничивать или иным образом сужать область применения настоящего изобретения, если иное не заявлено явно.

Фиг. 4 иллюстрирует примерную блок-схему последовательности операций способа 400 предоставления разработчику автоматического удобного в использовании способа создания объекта привязывания для использования в создании канала обмена данными рабочих модулей, используемого, чтобы передавать сообщения между конечными точками. Способ 400 включает в себя действие представления 405 множества элементов привязывания пользователю для выбора. Например, приложение 110 разработчика службы может использовать пользовательский интерфейс 112, чтобы представлять множество элементов 115 привязывания пользователю для выбора. Элементы 115 привязывания представляют аспекты связи канала 165 обмена данными рабочих модулей для транспортировки сообщения 170 между клиентом 130 и службой 140 или конечной точкой 160 службы.

Эти аспекты связи должны включать в себя, по меньшей мере, аспект транспортного механизма (к примеру, UDP, HTTP, HTTPS, HTTPR, TCP, SMTP, промежуточное программное обеспечение, интеграцию промежуточного программного обеспечения и т.д.) и аспект механизма кодирования (к примеру, текстовое, двоичное, SOAP, MTOM и т.д.). Дополнительно, аспекты связи могут включать в себя надежность, безопасность, составной дуплекс, формат сообщения, контекстный поток, поток транзакций и т.д. Помимо этого, элементы привязывания являются полностью наращиваемыми и настраиваемыми в том, что элементы привязывания могут быть добавлены, модифицированы или удалены без необходимости перезаписывать приложение, которое представляет множество элементов привязывания пользователю или базовому конструктору, который создает метаданные, заводские настройки канала и заводские настройки приемника, описанные выше. Более того, эти элементы привязывания могут быть представлены пользователю в группах, к примеру группе надежности, группе безопасности, группе транспортных механизмов, группе механизмов кодирования, смешанной группе и т.д. Аналогично отдельным элементам привязывания группы являются полностью наращиваемыми и подключаемыми в том, что элементы привязывания могут быть добавлены, удалены или модифицированы для каждой группы и сами группы могут быть добавлены, удалены или модифицированы без нарушения работы системы.

Способ 400 также включает в себя действие приема 410 пользовательского ввода, принимающего один или более элементов привязывания из множества элементов привязывания. Следовательно, приложение 110 разработчика служб может принимать пользовательский ввод, который выбирает элементы 115 привязывания, соответствующие аспекту транспортного механизма и/или аспекту механизма кодирования. На основе выбора способ 400 также включает в себя действие создания 415 метаданных, заводских настроек канала и заводских настроек приемника. Более конкретно, приложение 110 службы (или конструктор привязываний, как описано выше) после приема выбора элементов 115 привязывания может генерировать набор метаданных 125, который описывает объект привязывания, который включает в себя элементы привязывания. Набор метаданных 125 предоставляет абстрактное представление протокола, который реализует аспекты связи в рабочем модуле. Метаданные 125 могут быть частью документа WSDL или в какой-либо другой форме. Помимо этого, приложение поставщика служб может создавать заводские настройки 135 канала, которые могут быть сконфигурированы, чтобы использовать набор метаданных 125 в рабочем модуле, чтобы генерировать канал 165 обмена данными рабочих модулей. Дополнительно, приложение 110 разработчика служб может быть использовано, чтобы генерировать или создавать заводские настройки 145 приемника, которые сконфигурированы, чтобы принимать канал обмена данными рабочих модулей, чтобы обрабатывать сообщение в конечной точке службы. Когда выбран составной дуплексный элемент привязывания, два элемента привязывания транспортных механизмов и/или два элемента привязывания механизмов кодирования могут быть выбраны. Разумеется, один элемент привязывания транспортных механизмов и/или механизмов кодирования может быть выбран и принят для обоих направлений.

Фиг. 5 иллюстрирует способ 500 предоставления разработчику короткого способа автоматического создания объекта привязывания посредством предоставления разработчику списка наиболее распространенных и совместимых объектов привязывания, которые могут быть использованы, чтобы создавать канал обмена данными рабочих модулей. Способ 500 включает в себя действие представления 505 множества элементов привязывания пользователю. Т.е., как показано на фиг. 1C, пользователю может быть предоставлен пользовательский интерфейс 102, который включает в себя множество объектов 104 привязывания для выбора, каждый из которых включает в себя множество элементов 115 привязывания, которые объединяются на основе совместимости и промышленной вероятности объединения множества элементов привязывания. Дополнительно, каждый из множества элементов 115 привязывания представляет множество аспектов связи, которые в конечном счете будут использованы, чтобы создать канал 165 обмена данными для транспортировки сообщения 170 между клиентом 130 и конечной точкой 160 службы. Аспекты связи могут включать в себя вышеупомянутые аспекты типа механизма кодирования, типа транспортного механизма, надежности, безопасности, составного дуплекса и т.д.

Способ 500 также включает в себя действие приема 510 пользовательского ввода, выбирающего объект привязывания из множества объектов привязывания. Т.е. пользовательский интерфейс 102 может принимать пользовательский ввод, выбирающий объект привязывания из множества объектов 104 привязывания. Способ 500 также включает в себя действие автоматического создания 515 метаданных, описывающих выбранные объекты привязывания. Т.е. метаданные 125 могут быть сгенерированы на основе выбора стандартного привязывания 104 из множества стандартных привязываний 104. Объект привязывания, описанный в метаданных, предоставляет абстрактное представление стека протоколов, который реализует аспекты связи в рабочем модуле.

Помимо этого, могут быть созданы заводские настройки 135 канала, которые сконфигурированы, чтобы использовать метаданные 125 в рабочем модуле, чтобы генерировать канал 165 обмена данными рабочих модулей. Дополнительно, заводские настройки приемника могут быть сконфигурированы, чтобы принимать канал 165 обмена данными рабочих модулей и демультиплексировать аспекты связи для обработки сообщения в конечной точке 160 службы. Объектами привязывания может быть одно или более из привязывания базовых профилей, привязывания WS-профилей, двойного привязывания WS-профилей, TCP-привязывания Net-профилей, двойного TCP-привязывания Net-профилей, привязывания именованных каналов Net-профилей, привязывания Net-профилей из очереди, привязывания интеграции из очереди, промежуточного привязывания и т.д.

Фиг. 6 иллюстрирует способ 600 использования объекта привязывания, чтобы создавать канал обмена данными рабочих модулей для реализации протокола, используемого, чтобы передавать сообщения между конечными точками. Способ 600 включает в себя действие осуществления доступа 605 к метаданным, которые описывают объект привязывания. Более конкретно, заводские настройки 135 канала могут осуществлять доступ к метаданным 125, которые включают в себя объект привязывания со множеством выбранных пользователем элементов привязывания, которые представляют то, как сообщения должны транспортироваться между конечными точками в распределенной системе 100. На основе объекта привязывания способ 600 также включает в себя действие инициирования 610 канала обмена данными рабочих модулей. Более конкретно, на основе объекта привязывания в метаданных 125 заводские настройки 135 канала могут инициировать канал 165 обмена данными рабочих модулей, который включает в себя аспекты связи, соответствующие выбранным пользователем элементам привязывания. Аспекты связи объединены в протокол, который включает в себя, по меньшей мере, аспект транспортного механизма и аспект механизма кодирования, описанные выше. Дополнительно, способ 600 включает в себя действие использования 615 канала обмена данными рабочих модулей, чтобы передавать сообщение в соответствии с аспектами связи. Более конкретно, клиент 130 после запроса канала 180 из заводских настроек 135 канала может принимать дескриптор 175, который используется, чтобы ссылаться на канал 165 обмена данными рабочих модулей. Затем сообщение 170 может быть отправлено или передано в соответствии с аспектами связи стека протоколов в конечную точку 160, ассоциативно связанную со службой 140.

Другие примерные варианты осуществления предусматривают, что перед отправкой сообщения 170 в конечную точку 160 приемник 150, соответствующий конечной точке 160 службы, допускает канал 165 обмена данными рабочих модулей и создает канал обмена данными служб для демультиплексирования аспектов связи из сообщения, чтобы потребить сообщение в конечной точке 160 службы. Другие вышеописанные аспекты также доступны для данного конкретного способа 600.

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

Фиг. 7 и последующее обсуждение предназначены, чтобы предоставить краткое общее описание подходящего вычислительного окружения, в котором может быть реализовано изобретение. Хотя это и необязательно, изобретение описано в общем контексте машиноисполняемых инструкций, таких как программные модули, исполняемые вычислительными машинами в сетевых окружениях. Программные модули, в общем, включают в себя процедуры, программы, объекты, компоненты, структуры данных и т.д., которые выполняют отдельные задачи или реализуют отдельные абстрактные типы данных. Машиноисполняемые инструкции, ассоциативно связанные структуры данных и программные модули представляют примеры средств программного кода для исполнения этапов способов, раскрытых в данном документе. Конкретная последовательность этих исполняемых инструкций или ассоциативно связанных структур данных представляет примеры соответствующих действий для реализации функций, описанных в этих этапах.

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

Относительно фиг. 7, примерная система для реализации изобретения включает в себя вычислительное устройство общего назначения в виде традиционной вычислительной машины 720, включающей в себя блок 721 обработки, системную память 722 и системную шину 723, которая соединяет различные компоненты системы, включая системную память, с блоком 721 обработки. Системная шина 723 может быть любой из некоторых типов шинных структур, включающих в себя шину памяти или контроллер памяти, периферийную шину и локальную шину, использующую любую из многообразия шинных архитектур. Системная память включает в себя постоянное запоминающее устройство 724 (ПЗУ) и оперативное запоминающее устройство 725 (ОЗУ). Базовая система 126 ввода-вывода (BIOS), содержащая базовые процедуры, которые помогают передавать информацию между элементами в рамках вычислительной машины 720, к примеру, в ходе загрузки, может быть сохранена в ПЗУ 724.

Вычислительная машина 720 может дополнительно включать в себя накопитель 728 на жестких дисках для считывания и записи на магнитный жесткий диск 739, накопитель 728 на магнитных дисках для считывания и записи на сменный магнитный диск 729 и накопитель 730 на оптических дисках для считывания и записи на сменный оптический диск 131, например CD-ROM или другие оптические носители. Накопитель 727 на жестких дисках, накопитель 728 на магнитных дисках и накопитель 730 на оптических дисках подключены к системной шине 723 посредством интерфейса 732 накопителя на жестких дисках, интерфейса 733 накопителя на магнитных дисках и интерфейса 734 накопителя на оптических дисках, соответственно. Накопители и ассоциативно связанные с ними машиночитаемые носители предоставляют энергонезависимое хранение машиночитаемых инструкций, структур данных, программных модулей и других данных для вычислительной машины 720. Хотя типичная вычислительная система, описанная в данном документе, использует магнитный жесткий диск 739, сменный магнитный диск 129 и сменный оптический диск 131, могут быть другие типы машиночитаемых носителей для сохранения данных, такие как магнитные дискеты, карты флэш-памяти, цифровые видеодиски, картриджи Бернулли, ОЗУ, ПЗУ и т.п.

Средство программного кода, содержащее один или более программных модулей, в том числе операционную систему 35, одну или несколько прикладных программ 36, другие программные модули 737 и программные данные 738, может быть сохранено на жестком диске 739, магнитном диске 729, оптическом диске 731, ПЗУ 124 или ОЗУ 125. Пользователь может вводить команды и информацию в вычислительную машину 120 посредством клавиатуры 140, указательного устройства 142 или других устройств ввода, таких как микрофон, джойстик, игровая панель, спутниковый диск, сканер и т.п. Эти и другие устройства ввода часто подключены к блоку 721 обработки через интерфейс 746 последовательного порта, который соединен с системной шиной. Альтернативно, устройства ввода могут быть подключены посредством других интерфейсов, таких как параллельный порт, игровой порт или универсальная последовательная шина (USB). Монитор 747 или другой тип дисплейного устройства также подключен к системной шине 723 посредством интерфейса, такого как видеоадаптер 748. Помимо монитора персональные вычислительные машины типично включают в себя другие периферийные устройства вывода (не показаны), такие как динамики и принтеры.

Вычислительная машина 110 может работать в сетевом окружении, использующем логические соединения с одной или более удаленными вычислительными машинами, такими как удаленные вычислительные машины 749a и 749b. Удаленной вычислительной машиной 749a и 749b может быть персональная вычислительная машина (ПЭВМ), сервер (ЭВМ общего пользования), маршрутизатор, сетевая персональная ЭВМ, одноранговое устройство или другой общий узел сети, и она типично включает в себя многие или все элементы, описанные выше относительно вычислительной машины 720, хотя на фиг. 7 проиллюстрированы только запоминающие устройства 750a и 750b и ассоциативно связанные с ними прикладные программы. Логические соединения, показанные на фиг. 7, включают в себя локальную вычислительную сеть 171 (ЛВС) и глобальную вычислительную сеть 173 (ГВС), которые представлены здесь в качестве примера, а не ограничения. Такие сетевые окружения широко распространены в офисах, корпоративных вычислительных сетях, сетях интранет и в Интернете.

Когда использована в сетевом окружении ЛВС, вычислительная машина 720 подключена к ЛВС 751 посредством сетевого интерфейса или адаптера 753. Когда использована в сетевом окружении ГВС, вычислительная машина 720 типично включает в себя модем 754, беспроводной канал связи или другое средство для установления связи по глобальной вычислительной сети 752, такой как Интернет. Модем 754, который может быть внутренним или внешним, подключен к системной шине 723 посредством интерфейса 746 последовательного порта. В сетевом окружении программные модули, показанные относительно вычислительной машины 720, или их части могут быть сохранены в удаленном запоминающем устройстве хранения. Следует принимать во внимание, что показанные сетевые соединения являются примерными, и могут быть использованы другие средства установления линии связи по глобальной вычислительной сети.

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

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

2. Способ по п.1, в котором выбирается элемент привязывания транспортных механизмов и элемент привязывания механизмов кодирования, которые соответствуют аспекту транспортного механизма и аспекту механизма кодирования соответственно, причем аспект транспортного механизма - это одно из UDP, HTTP, HTTPS, HTTPR, именованных каналов, TCP, SMTP, организации очереди обмена сообщениями, интеграции организации очереди обмена сообщениями, а аспект механизма кодирования - это одно из текстового, двоичного, МТОМ.

3. Способ по п.1, в котором набор метаданных является частью документа WSDL.

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

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

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

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

8. Способ по п.1, в котором выбирается составной дуплексный элемент привязывания и в котором выбирается два элемента привязывания механизмов кодирования.

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

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

11. Способ по п.10, в котором один или более из множества объектов привязывания включает в себя элемент привязывания транспортных механизмов и элемент привязывания механизмов кодирования, которые соответствуют аспекту транспортного механизма и аспекту механизма кодирования соответственно, причем аспект транспортного механизма -это одно из UDP, HTTP, HTTPS, HTTPR, именованных каналов, TCP, SMTP, организации очереди обмена сообщениями, интеграции организации очереди обмена сообщениями, а аспект механизма кодирования - это одно из текстового, двоичного, МТОМ.

12. Способ по п.10, в котором набор метаданных является частью документа WSDL.

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

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

15. Способ по п.10, в котором объекты привязывания выбираются из одного или более из привязывания базовых профилей, привязывания WS-профилей, двойного привязывания WS-профилей, TCP- привязывания Net-профилей, двойного ТСР-привязывания Net-профилей, привязывания именованных каналов Net-профилей, привязывания Nеt-профилей из очереди, привязывания интеграции из очереди или промежуточного привязывания.

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

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

18. Способ по п.16, в котором один или более из элементов привязывания включают в себя элемент привязывания транспортных механизмов и элемент привязывания механизмов кодирования, которые соответствуют аспекту транспортного механизма и аспекту механизма кодирования соответственно, причем аспект транспортного механизма - это одно из UDP, HTTP, HTTPS, HTTPR, именованных каналов, TCP, SMTP, организации очереди обмена сообщениями, интеграции организации очереди обмена сообщениями, а аспект механизма кодирования - это одно из текстового, двоичного, МТОМ.

19. Способ по п.16, в котором метаданные являются частью документа WSDL.

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