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

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

Иллюстрации

Показать все

Реферат

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

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

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

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

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

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

Одним типом т