Результат интеллектуальной деятельности: ПРЕДОСТАВЛЕНИЕ ФУНКЦИОНАЛЬНЫХ ВОЗМОЖНОСТЕЙ ДЛЯ КЛИЕНТСКИХ СЛУЖБ ПОСРЕДСТВОМ РЕАЛИЗАЦИИ И ПРИВЯЗКИ КОНТРАКТОВ

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

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

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

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

Сущность Изобретения

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

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

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

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

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

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

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

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

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

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

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

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

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

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

ОСУЩЕСТВЛЕНИЕ ИЗОБРЕТЕНИЯ

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

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

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

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

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

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

Помимо этого, модель обслуживания может назначать один или более узлов (например, узлы I 221, II 222, III 223, IV 224 и V 225 на Фиг.2 и 3) в рамках распределенного вычислительного центра (см. позиционное обозначение 200 на Фиг.2 и 3) для поддержания вариантов ролей. Это может выполняться контроллером системы коммутации. Соответственно, модель обслуживания выполняет функцию создания копии интерфейса, предоставляя инструкции для организации составляющих программ, таких как ролевые варианты, целевой службы, а также и клиентской службы, в конкретных вариантах осуществления. То есть, модель обслуживания помогает управлять контроллером системы коммутации при координировании действий между составляющими программами после развертывания в рассредоточенных позициях по всей распределенной вычислительной среде. Эти позиции, как правило, описываются техническими характеристиками развертывания в рамках модели обслуживания. Вообще говоря, фраза "технические характеристики развертывания" подразумевает ограничение и используется для обозначения механизма, который организует конкретизацию ролевых вариантов на узлах, которые определяют, какие каналы связи использовать в качестве трактов информационного обмена между ролевыми вариантами, и/или который предоставляет информацию, описывающую конкретный способ, которым будет выполняться целевая служба.

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

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

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

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

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

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

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

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

Продолжая рассматривать Фиг.1, вычислительное устройство 100 включает в себя шину 110, которая непосредственно или косвенно соединяет следующие устройства: запоминающее устройство 112, одно или более обрабатывающих устройств 114, один или более компонентов 116 представления, порты 118 ввода/вывода, компоненты 120 ввода/вывода и иллюстративный источник 122 питания. Шина 110 символизирует собой то, что может быть одной или более шинами (такими, как адресная шина, шины данных, или их комбинация). Хотя различные блоки на Фиг.1 показаны как обведенные линиями ради ясности, в действительности разграничение различных компонентов не настолько явное, и, образно, было бы точнее сделать линии серыми и нечеткими. Например, можно принять во внимание такое представление компонентов, при котором устройство отображения является компонентом ввода/вывода. Кроме того, в обрабатывающих устройствах есть запоминающее устройство. Авторы настоящего изобретения осознают, что такова природа данной области техники, и напоминают, что схема на Фиг.1 является лишь изображением иллюстративного вычислительного устройства, которое может использоваться применительно к одному или более вариантам осуществления настоящего изобретения. Не проводится различий между такими категориями как "рабочая станция", "обслуживающий узел", "портативный компьютер", "карманное устройство", и т.д., поскольку все они предусматриваются в рамках Фиг.1 и именуются "компьютер" или "вычислительное устройство".

Вычислительное устройство 100, как правило, включает в себя разнообразные считываемые с помощью компьютера носители. В качестве примера, но не ограничения, считываемые с помощью компьютера носители могут содержать Оперативное Запоминающее Устройство (ОЗУ); Постоянное Запоминающее Устройство (ПЗУ);

Электрически Стираемое Программируемое Постоянное Запоминающее Устройство (ЭСППЗУ); запоминающее устройство с групповой перезаписью или запоминающее устройство, выполненное по другой технологии; CDROM, цифровые универсальные диски (DVD) или другие оптические или голографические носители; магнитные кассеты, магнитную ленту, хранилище на магнитных дисках или другие магнитные устройства хранения, или любой другой носитель, который может использоваться для кодирования необходимой информации и может быть доступен со стороны вычислительного устройства 100.

Запоминающее устройство 112 включает в себя носители для хранения информации на компьютере в форме энергозависимого и/или энергонезависимого запоминающего устройства. Запоминающее устройство может быть съемным, стационарным, или комбинацией таковых. Иллюстративные аппаратные устройства включают в себя твердотельное запоминающее устройство, накопители на жестких дисках, накопители на оптических дисках и т.д. Вычислительное устройство 100 включает в себя одно или более обрабатывающих устройств, которые считывают данные из различных модулей, таких как запоминающее устройство 112 или компоненты 120 ввода/вывода. Компонент(ы) 116 представления представляют отражения данных для пользователя или другого устройства. Иллюстративные компоненты представления включают в себя устройство отображения, громкоговоритель, печатающий компонент, вибрирующий компонент, и т.д. Порты 118 ввода/вывода позволяют вычислительному устройству 100 логически соединяться с другими устройствами, в том числе с компонентами 120 ввода/вывода, причем некоторые из них могут быть встроенными. Иллюстративные компоненты включают в себя микрофон, координатную ручку, игровой манипулятор, антенну спутниковой связи, сканирующее устройство, печатающее устройство, беспроводное устройство и т.д.

Обратимся теперь к Фиг.2, показана структурная схема, демонстрирующая распределенную вычислительную среду 200, пригодную для использования при реализации вариантов осуществления настоящего изобретения. В большинстве случаев, распределенная вычислительная среда 200 выполняется с возможностью привязки реализованного контракта 235 к целевой службе 205 и привязки контракта, привязанного к целевой службе 205, к клиентской службе, как показано на Фиг.3. Распределенная вычислительная среда 200 включает в себя центр 210 хранения и обработки данных, выполненный с возможностью обеспечения и поддержания работы составляющих программ, или вариантов А 261 и В 262 ролей, целевой службы 205 согласно модели 250 обслуживания. Специалистам в данной области техники будет понятно и должно приниматься ими во внимание, что центр 210 хранения и обработки данных, продемонстрированный на Фиг.2, является просто одним примером, подходящим для обеспечения одного или более служебных приложений (например, целевой службы 205), и не предполагает внесения какого-либо ограничения относительно области применения или функциональных возможностей вариантов осуществления настоящего изобретения. Также центр 210 хранения и обработки данных не должен интерпретироваться как обладающий какой-либо зависимостью или требованием, связанным с каким-то отдельным узлом, сочетанием узлов (например, узлов I 221, II 222 и III 223), ресурсами (не показано), или набором API для организации доступа к ресурсам (не показано). Дополнительно, хотя различные блоки на Фиг.2 показаны как обведенные линиями ради ясности, в действительности, разграничение различных компонентов не настолько явное, и, образно, было бы точнее сделать линии серыми и нечеткими.

Центр 210 хранения и обработки данных включает в себя различные узлы (например, узлы I 221, II 222 и III 223), операционную систему, запущенную на каждом из этих узлов, ролевые варианты А 261 и В 262, интерфейсы (например, интерфейс 220), а часто и контроллер 215 системы коммутации, который может включать в себя агенты системы коммутации (не показано), локально инсталлированные на узлах I 221, II 222 и III 223. Агенты системы коммутации выступают в качестве расширения контроллера 215 системы коммутации и выполняют совместные функции для инсталляции и организации целевой службы 205, наряду с прочим. Помимо этого ролевые варианты А 261 и В 262 могут взаимно соединяться друг с другом через входные оконечные точки (например, входную оконечную точку 255), от которых подаются вызовы, и выходные оконечные точки, на которые принимаются вызовы. В одном варианте, одно или более из этих взаимных соединений может устанавливаться через сетевое облако (не показано). Сетевое облако соединяет между собой перечисленные выше объекты таким образом, что ролевые варианты А 261 и В 262 и интерфейс 220, который может быть с возможностью распределенного размещения на различных физических ресурсах, могут распознавать местоположение друг друга для того, чтобы устанавливать связь между собой. Помимо этого сетевое облако облегчает эту связь по каналам 290 связи, оперативно соединяющим интерфейс 220 с входной оконечной точкой 255 варианта 261 роли А. В качестве примера, сетевое облако может включать в себя, без ограничения, одну или более локальных вычислительных сетей (ЛВС) и/или глобальных вычислительных сетей (ГВС). Такие сетевые среды являются обычным явлением в учрежденческих, корпоративных компьютерных сетях, внутрикорпоративных сетях на базе технологии Интернет и в сети Интернет. Соответственно, эта сеть не описывается дополнительно в данном документе.

Дополнительно, следует отметить, что варианты осуществления настоящего изобретения не ограничиваются реализацией на таких физических ресурсах, как показанные на Фиг.2, а могут быть реализованы на любых из множества различных типов вычислительных устройств, оборудования, и составляющих программ в рамках вариантов осуществления из данного документа. Другими словами, показанные узлы I 221, II 222 и III 223 центра 210 хранения и обработки данных изображают лишь иллюстративную конфигурацию, которая предназначена исключительно для обсуждения; соответственно, любая подходящая компоновка узлов, и размещенных на них ролевых вариантов, известная в компьютерной отрасли, может использоваться и предусматриваться в соответствии с настоящим изобретением.

Эти иллюстративные узлы I 221, II 222 и III 223 и ролевые варианты А 261 и В 262 центра 210 хранения и обработки данных служат, чтобы ввести понятие реализации служебного контракта и привязки реализованного контракта 235 к целевой службе 205, что будет обсуждаться далее. Прежде всего, идентифицируется служебный контракт. В одном варианте, контракт идентифицируется для раскрытия обобщения функциональных возможностей 260 варианта 261 роли А, которые соответствуют ожидаемой зависимости, записанной для клиентской службы (см. позиционное обозначение 305 на Фиг.3). Идентифицированный контракт, как правило, определяет совокупность интерфейсов и поддерживает набор свойств 240, каждое из которых связывается с одним или более интерфейсами. В процессе работы набор свойств 240 полезен для инсталляции и подгонки конфигурации каждого из интерфейсов.

Идентифицированный служебный контракт может быть реализован для установки интерфейса 220 из совокупности интерфейсов в пределах вычислительного устройства (например, узла I 221) распределенной вычислительной среды 200. Как обсуждалось более подробно выше, реализованный контракт выступает в качестве транспортного средства для клиентской службы, чтобы получать доступ к функциональным возможностям 260 целевой службы 205. Процесс реализации может включать в себя параметризацию установленного интерфейса 220 со значениями 230, полученными из набора свойств 240, связанных с установленным интерфейсом 220. В одном варианте, параметризация может включать в себя управление значениями 230 для параметров 270, которые неявно присутствуют в пределах интерфейса 200.

Процесс реализации также может включать в себя инсталляцию ограничивающих условий 295 в отношении интерфейса 220. Прежде всего, набор свойств 240, связанных с интерфейсом 220, может задавать ограничивающие условия 295, которые частично регулируют работу установленного интерфейса 220. Дополнительно, параметризация установленного интерфейса 220 со значениями 230, полученными из набора свойств 240, обеспечивает выполнение ограничивающих условий 295 в пределах распределенной вычислительной среды 200. В силу этого, ограничивающие условия 295 служат руководством для определения того, как интерфейс 220 подключается (например, определяя, какие внешние порты обслуживающего узла могут принимать вызов 225 от удаленного приложения обслуживающего узла сети Интернет) и, отчасти, как конфигурируется интерфейс 220. В качестве примера, когда свойства 240 задают конкретные ограничивающие условия 295, такие как конкретные номера портов, контроллер 215 системы коммутации назначает их в пределах центра 210 хранения и обработки данных и настраивает их как целевые при подаче вызова 225. Соответственно, интерфейс 220 ограничивается использованием этих назначенных номеров портов при попытке получить доступ к функциональным возможностям 260 целевой службы 210.

Ограничивающие условия 295 могут оказывать содействие при конфигурировании интерфейса 220. В одном примере, ограничивающие условия 295 могут заставить интерфейс 220 фильтровать тех, кто предпринимает попытку доступа к функциональным возможностям 260, тем самым ограничивая поток информационного обмена на целевую службу 205. В другом примере, ограничивающие условия 295 могут заставить интерфейс 220 позволять клиентским службам, удостоверенным конкретным идентифицирующим органом, получать доступ к функциональным возможностям 260. Еще в одном примере, ограничивающие условия 295 могут заставить интерфейс 220 или целевую службу 205 посредством интерфейса 220, закрывать соединения с функциональными возможностями 260 по истечении предварительно заданного периода времени, тем самым, предотвращая несанкционированную обработку.

После реализации реализованный контракт 235 может быть привязан к целевой службе 205 при помощи контроллера 215 системы коммутации. Процесс привязки реализованного контракта 235 к целевой службе 205 может включать в себя автоматическое связывание установленного интерфейса 220 и вариантов 261 роли А по каналам 290 связи. Как обсуждается более подробно ниже со ссылкой на Фиг.4 и 5, канал 290 связи может принимать любую из множества форм. Как правило, каналы 290 связи оперативно соединяют интерфейс 220 с функциональными возможностями 260 целевой службы 205 через входную оконечную точку 255. Входные оконечные точки 255 и/или каналы 290 связи могут сопоставляться для использования в дальнейшей работе. В качестве примера, контроллер 215 система коммутации может отвечать за назначение подходящих каналов 290 связи в хранилище 210 данных для использования интерфейсом 220.

В вариантах осуществления, интерфейс 220, после привязки реализованного контракта 235 к целевой службе 205, связывается с входными оконечными точками 255 вариантов 261 роли А. Связывание способствует организации доступа к нескольким адресам целевой службы 205, которая предоставляет функциональные возможности 260. Другими словами, интерфейс 220 формирует осведомленность обо всех связанных вариантах 261 роли А, которые предоставляют желаемые функциональные возможности 260.

Процесс привязки дополнительно содержит автоматическое конфигурирование вариантов 261 роли А на основании заданных ограничивающих условий 295, выполнение которых обеспечивается установленным интерфейсом 220. Процесс конфигурирования проиллюстрирован позиционным обозначением 275. В вариантах осуществления, ограничивающие условия 295, заключенные в интерфейсе 220, предписывают контроллеру 215 системы коммутации, как настроить ограничения в пределах целевой службы 205. В одном примере, ограничивающие условия 295 могут предписывать, что имеется ограничение на то, кто может обращаться к вариантам 261 роли А, например только клиентские службы, расположенные в Северной Америке. В другом примере, ограничивающие условия 295, которые задают конфигурацию интерфейса 220 как интерфейса с возможностью защиты, могут в свою очередь задавать конфигурацию целевой службы 205 для анализа поступающих вызовов 225 касательно сертификата(ов) подлинности. Как правило, в модели 250 обслуживания предусматриваются ограничивающие условия 295, или она может обращаться к ним, чтобы должным образом задавать конфигурацию входных оконечных точек 255 на новых ролевых вариантах при увеличении количества вариантов целевой службы 205 в пределах центра 210 хранения и обработки данных.

Процесс привязки дополнительно еще включает в себя идентификацию и связывание с подходящими входными оконечными точками 255 вариантов 261 роли А, которые обеспечивают функциональные возможности 260. В большинстве случаев, под "входными оконечными точками", в широком смысле, понимается порт, на котором роль ожидает вызов 225 для ввода, тем самым, позволяя другим объектам контактировать с ролью А. Помимо этого порт может использоваться для ответа на запрос, вложенный в вызов 225. Этот ответ, или "отклик", может отправляться обратно клиентской службе, предоставившей запрос на функциональные возможности 260, по тому же каналу 295 связи. Поскольку целевая служба 205 и клиентская служба конфигурируются так, чтобы быть совместимыми в процессе согласования (например, с применением ограничивающих условий 295 из реализованного контракта 235), вызов 225 и отклик понятны (например, аналогичный протокол или язык) и целевой службе 205 и клиентской службе.

Дополнительно, после связывания с входными оконечными точками 255, сетевой адрес 265 (например, IP-адрес) входных оконечных точек 255 в пределах центра 210 хранения и обработки данных может транслироваться в контроллер 215 системы коммутации для определения местоположения вариантов 261 роли А, которые связаны с интерфейсом 220. Эти сетевые адреса 265 отображают местоположение функциональных возможностей 260, раскрываемых реализованным контрактом 235, и, в зависимости от функциональных возможностей 260, дают клиентским службам возможность обращаться к соответствующим позициям, или ролевым вариантам 261. Помимо этого, сетевые адреса 265 помогают объектам за пределами центра 210 хранения и обработки данных контактировать с интерфейсом 220. Вообще говоря, контроллер 215 системы коммутации отвечает за приобретение и поддержание списка сетевых адресов 265 входных оконечных точек 255 после связывания интерфейса 220 с ними в процессе привязки.

В одном варианте, этот сетевой адрес 265 может быть скрыт от клиентской службы. Соответственно, контроллер 215 системы коммутации автоматически устанавливает статическую магистраль, по которой маршрутизируются вызовы 225 от служебного приложения на соответствующую входную оконечную точку 255. В другом варианте, этот сетевой адрес 265 может быть видимым для клиентской службы. В этом варианте, клиентская служба может быть унаследованным приложением, которому требуется знание контактного адреса, чтобы отправить вызов 225. Соответственно, контроллер 215 системы коммутации может опубликовать сетевой адрес 265 для клиентской службы. Еще в одном варианте, этот сетевой адрес 265 может быть доступен для клиентской службы. Соответственно, клиентская служба может находить сетевой адрес 265 для обращения к входной оконечной точке при динамическом обновлении канала 290 связи.

После приема вызова 255 на целевой службе 205 может запрашиваться идентифицирующая информация клиентской службы, предоставившей вызов 225, для проверки подлинности вызова 225. В одном варианте, идентифицирующая информация клиентской службы записывается контроллером 215 системы коммутации. Запись может проводиться после развертывания клиентской службы, после привязки клиентской службы к реализованному контракту 235, или в любое время после этого. При ретрансляции подаваемого вызова 225 к вариантам 261 роли А, подаваемый вызов 225 может быть дополнен требованием 281. Требование 281 может генерироваться путем доступа к идентификационной информации клиентской службы, чтобы проверить, что вызов 225 подали составляющие программы клиентской службы, и объединяя определяемую идентификационную информацию, а также другие характеристики клиентской службы, в требовании 281.

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

В одном варианте осуществления, свойства клиентской службы в требовании 281 могут включать в себя любую информацию о клиентском устройстве, которую контроллер 215 системы коммутации может распространять. В одном варианте, в содержании требования 281 может предусматриваться географическое местоположение клиентской службы. В ответ целевая служба 205 может принять на обработку вызов 225 или перенаправить его на более близкий узел. Или, целевая служба 205 может модулировать отклик на вызов 225 на основании географического местоположения. Например, если географическое местоположение указывает, что вызов 225 исходит из Франции, целевая служба 205 может подготовить отклик на французском языке. В другом варианте, в содержание требования 281 может вноситься перечень прав на функциональные возможности 260. В ответ целевая служба 205 может ограничить доступ клиентской службы к ресурсам, которыми она управляет, в соответствии с правами, принадлежащими клиентской службе.

В другом варианте осуществления, целевая служба 205 может проверять идентификационную информацию и права клиентской службы, запрашивая программный интерфейс 201 приложения (API -application programming interface) для проверки. API 201 для проверки может предоставлять данные о вызове 225, который был принят, так как контроллеру 215 системы коммутации известен источник вызова 225. Соответственно, целевая служба 205 может заранее определять, исполнять ли вызов 225 (например, предоставлять функциональные возможности 260), если требование 281 является неполным или недействительным.

Обратимся теперь к Фиг.3, демонстрируется структурная схема, показывающая иллюстративную распределенную вычислительную среду 200, пригодную для использования при реализации вариантов осуществления настоящего изобретения, которая выполнена с возможностью привязки контракта, привязанного к целевой службе, к клиентской службе. Прежде всего, распределенная вычислительная среда 200 включает в себя клиентскую службу 305, как обсуждалось выше, для организации доступа к целевой службе. Клиентская служба 305 может представлять собой какое-либо служебное приложение, которое выполнено с возможностью запуска в пределах центра 210 хранения и обработки данных, запуска вне центра 210 хранения и обработки данных с удаленным подключением к нему, или частичного нахождения в центре 210 хранения и обработки данных. Клиентская служба 305 может включать в себя составляющие программы (например, составляющие программы А 361 и В 362), которые могут быть распределены по отдельным узлам (например, по узлам IV 224 и V 225) центра 210 хранения и обработки данных. В вариантах осуществления, в которых клиентская служба 305 обеспечивается центром 210 хранения и обработки данных, контроллер 215 системы коммутации может отвечать за развертывание составляющих программ А 361 и В 362, с учетом технических характеристик развертывания, поддерживаемых в модели 350 обслуживания, и за организацию исполнения клиентской службы 305.

В иллюстративном варианте осуществления, одна или более составляющих программ А 361 и В 362 пишутся разработчиком с использованием зависимости 360. В большинстве случаев, надлежащее исполнение клиентской службы 305 обусловливается соответствием зависимостям 360 с подходящими функциональными возможностями (например, функциональными возможностями 260 целевой службы 205 на Фиг.2). В процессе работы клиентская служба 305 может распространять указание на соответствие этой зависимости 360. В ответ, контроллер 215 системы коммутации может рассматривать зависимость 360 и назначать контракт, раскрывающий обобщение функциональных возможностей, которые удовлетворяют зависимости 360. Как обсуждалось выше, контракт, который удовлетворяет зависимости 360, может реализовываться заранее в пределах распределенной вычислительной среды 200. Помимо этого реализованный контракт может заранее привязываться к целевой службе, которая производит функциональные возможности, раскрываемые этим контрактом.

После назначения удовлетворительного контракта контроллер 215 системы коммутации может привязать этот назначенный и предварительно привязанный контракт 335 к клиентской службе 305. В вариантах осуществления, процесс привязки клиентской службы 305 может происходить в ходе первоначального развертывания составляющих программ А 361 и В 362 клиентской службы 305 для инициализации их работы. В большинстве случаев, процесс развертывания включает в себя автоматическое связывание составляющих программ А 361 и В 362 с интерфейсом 220, определяемым назначенным привязанным контрактом 335. При этом привязанный контракт 335 задает конфигурацию интерфейса 220 с ограничивающими условиями 295, полученными из набора свойств 240. В одном варианте осуществления, интерфейс 220 устанавливается в пределах распределенной вычислительной среды 200 после реализации назначенного привязанного контракта 335.

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

В иллюстративном варианте осуществления, процесс автоматического связывания составляющих программ А 361 и В 362 с интерфейсом 220 может включать в себя идентификацию выходных оконечных точек 375, размещенных в составляющей программе В 362, причем составляющая программа В 362 демонстрирует зависимость 360. Вообще говоря, выходные оконечные точки 375 могут представлять собой порт, который составляющая программа В 362 использует для инициализации запросов на что-либо со стороны. Процесс автоматического связывания может переходить к назначению каналов 390 связи в пределах распределенной вычислительной среды 200 для оперативного соединения установленного интерфейса 220 с выходными оконечными точками 375. Каналы 390 связи, как правило, служат для передачи вызова 225, подаваемого от выходных оконечных точек 375 клиентской службы 305. Как правило, вызов 225 включает в себя запрос составляющей программой В 362 на соответствие записанной зависимости 360. В вариантах осуществления, зависимость 360 может включать в себя внешнюю обработку или поиск данных, которые не выполняются в клиентской службе 305, но совершаются благодаря функциональным возможностям, связанным через интерфейс 220.

После завершения процесса привязки привязанный контракт 335 привязывается и к клиентской службе 305 и к дополняющей целевой службе. В вариантах осуществления, клиентская служба 305 может запросить ограничивающие условия 295 интерфейса 220, чтобы принять решение, может ли интерфейс 220 обеспечить функциональные аспекты, задаваемые моделью 350 обслуживания клиентской службы 305. Если нет, клиентская служба 305 может быть заново привязана контроллером 215 системы коммутации к другому контракту, который заменяет привязанный интерфейс и целевую службу, но сохраняет функциональные возможности, которые отвечают зависимости 360. Повторная привязка также может происходить, когда привязанная целевая служба падает с отключением от сети.

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

В другом варианте осуществления, задействуются стандартные контракты. Вообще говоря, стандартные контракты могут привязываться двумя разными способами. Согласно одному иллюстративному способу, каждая целевая служба снабжается уникальным именем. Тогда контроллер 215 системы коммутации может контролировать обоснованность соотнесения клиентской службы 305 и целевой службы, используя это уникальное имя, при помощи проверки того, что привязанная целевая служба действительно реализует привязанный контракт 335. После этого от входных оконечных точек целевой службы получается сетевой адрес (например, сетевой адрес 265). Согласно другому способу, информация о выходной оконечной точке 375 внешней клиентской службы 305, которая не размещается в центре 210 хранения и обработки данных, и/или о входной оконечной точке целевой службы (например, IP-адрес/Доменное_Имя:Порт) поступает в контроллер 215 системы коммутации. Для интерфейса 220 выявляется спецификация IP:порт. Соответственно, контроллер 215 системы коммутации задает конфигурацию выходных оконечных точек 375 составляющей программы В 362, связанной с интерфейсом 220. При этом не выполняется никакой проверки, что упомянутая целевая служба удовлетворяет привязанному контракту 335.

Еще в одном иллюстративном варианте осуществления задействуются внешние контракты, как правило, когда клиентская служба 305 находится вне центра 210 хранения и обработки данных. Вообще говоря, внешние контракты включают в себя выделение низкоуровневых обобщений, что позволяет клиентской службе 305 контактировать с любым публичным IP-адресом в пределах, устанавливаемых при развертывании клиентской службы 305. Фактически, никакая привязка не выполняется, и предполагается, что клиентская служба 305 предоставляет сетевой адрес 265 целевой службы для организации доступа к ее функциональным возможностям. В связи с этим сетевой адрес 265 связанной входной оконечной точки используется для задания конфигурации и прокладывания маршрута канала 390 связи.

Как обсуждалось выше, привязанный контракт 335 может поддерживать набор свойств 240, связанных с установленным интерфейсом 220. В процессе работы ограничивающие условия 295 могут применяться к установленному интерфейсу 220 посредством параметризации установленного интерфейса 220 со значениями, полученными из связанного набора свойств 240. Эти применяемые ограничивающие условия 295 могут публиковаться для клиентской службы 305, чтобы конфигурировать составляющие программы А 361 и В 362. Процесс конфигурирования клиентской службы 305 иллюстрируется позиционным обозначением 388. Вообще говоря, процесс конфигурирования 388 составляющих программ А 361 и В 362, вместе с выходными оконечными точками 375, содержит извлечение инструкций из ограничивающих условий 295, применяемых к интерфейсу 220. Эти инструкции могут использоваться для любого числа конфигураций аспектов клиентской службы 305, а также и обеспечиваемой ей передачи данных. Например, инструкции могут задействоваться для форматирования вызова 225, подаваемого от выходных оконечных точек 375. Благодаря использованию инструкций для задания конфигурации формата вызова 225, среди прочего, вызов 225 может быть совместим с базисным протоколом ролевых вариантов целевой программы, которые реализуют нужные функциональные возможности.

После задания конфигурации клиентская служба 305 может подавать вызов 225, при этом должно выполняться соответствие зависимости 360. В вариантах осуществления, вызов 225 может подаваться от выходных оконечных точек 375 составляющей программы В 362, которая реализует зависимость 360. Затем вызов 225 маршрутизируется по назначенным каналам 390 связи распределенной вычислительной среды 200 на установленный интерфейс 220. Как более полно обсуждалось выше, установленный интерфейс 220 может быть параметризован, чтобы ретранслировать подаваемый вызов 225 на целевую службу или отфильтровывать подаваемый вызов 225. Это решение интерфейса 220 может основываться на ограничивающих условиях 295, применяемых к нему, в сочетании с идентификационной информацией клиентской службы 305.

Эта иллюстративная распределенная вычислительная среда 220 является лишь одним примером пригодной среды, которая может быть реализована для осуществления аспектов настоящего изобретения, и не предполагает внесения какого-либо ограничения относительно области применения или функциональных возможностей настоящего изобретения. Ни одна из показанных иллюстративных системных архитектур распределенной вычислительной среды 220 не должна интерпретироваться как обладающая какой-либо зависимостью или требованием, связанным с каким-то одним или комбинацией из показанных компонентов 215, 220, 221, 225, 305, 335, 350, 360, 361 и 362. В некоторых вариантах осуществления, один или более из компонентов 215, 220, 221, 224, 225, 305, 335, 350, 360, 361 и 362 могут быть реализованы как автономные устройства. В других вариантах осуществления, один или более из компонентов 215, 220, 221, 225, 305, 335, 350, 360, 361 и 362 могут быть встроены непосредственно в центр 210 хранения и обработки данных или в контроллер 215 системы коммутации. Специалистам в данной области техники будет понятно, что компоненты 215, 220, 221, 225, 305, 335, 350, 360, 361 и 362, показанные на Фиг.3, являются иллюстративными по сущности и по количеству и не должны истолковываться как ограничение.

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

Обратимся теперь к Фиг.4, демонстрируется графическое представление иллюстративного контроллера 215 системы коммутации для использования каналов 410 с балансировкой нагрузки (LB), чтобы маршрутизировать передачу данных (например, вызовы 225 и отклики) между служебными приложениями (например, клиентской службой 305 и целевой службой 205), в соответствии с вариантом осуществления настоящего изобретения. Прежде всего предусматриваются определения 450 соединений, к которым может обращаться контроллер 215 системы коммутации. Эти определения 450 соединений содействуют инструктированию механизма 420 LB в отношении прокладывания маршрута связи до одного выбранного из числа ролевых вариантов 411, 412 и 413 целевой службы 205. Ролевой вариант, выбранный для приема вызова, может выбираться на основании любого числа показателей, включающих в себя соизмеримость с ролью (например, с ролями 421, 422 и 423) клиентской службы 305, подающей вызов 225, близость к роли (например, к ролям 421, 422 и 423), доступность и тому подобное.

После выбора вызов передается выбранной роли целевой службы 205 через каналы 410 с балансировкой нагрузки (LB), которые связывают установленный интерфейс 220 с входными оконечными точками ролей (например, ролей 411, 412 и 413) целевой службы 205. В одном варианте, передача может охватывать прием вызова 225 от клиентской службы 305 на установленном интерфейсе 220 и активизацию механизма 420 LB для распределения вызова 225 в доступный канал связи из числа каналов 410 LB. В этой связи только один сетевой адрес предоставляется клиентской службе 305 для отправки ей вызовов 225. Контроллер 215 системы коммутации отвечает за реализацию схемы балансировки нагрузки, с учетом определений 450 соединений, гарантируя, что распределение вызовов 225 на интерфейс 220 распределяется между ролями (например, ролями 411, 412 и 413) целевой службы 205. В иллюстративном варианте осуществления, сетевым адресом является виртуальный IP для интерфейса 220 и/или механизма 420 LB. Затем механизм 420 LB может перевести виртуальный IP в конкретные IP, каждый из которых связан со своей ролью.

Что касается Фиг.5, демонстрируется графическое представление иллюстративного контроллера системы коммутации для использования каналов без сохранения состояния переключения (SLS) (например, каналов 510, 511 и 512), чтобы маршрутизировать передачу данных (например, вызовы 521, 522 и 523, и отклики в ответ на них) между служебными приложениями (например, клиентской службой 305 и целевой службой 205) в соответствии с вариантом осуществления настоящего изобретения. Вообще говоря, назначенные каналы связи (см. позиционное обозначение 290 на Фиг.2), могут содержать каналы 510, 511 и 512 SLS, которые связывают установленный интерфейс 220 с входными оконечными точками ролей (например, ролей 411, 412 и 413) целевой службы 205. Эти каналы 510, 511 и 512 SLS могут сохраняться с помощью определений 450 соединений и поддерживаться контроллером 215 системы коммутации.

В процессе работы, после приема вызова (например, вызовов 521, 522 и 523), контроллер 215 системы коммутации идентифицирует сетевой адрес, связанный с вызовом. Сетевой адрес может предоставляться ролью (например, ролью 421) клиентской службы 305, предоставившей вызов (например, вызов 521), или поставляться определениями 450 соединений на основании источника вызова. На основании сетевого адреса вызов 225 маршрутизируется по каналу связи (например, 510), из числа каналов SLS, выделенному для связывания установленного интерфейса 220 с входной оконечной точкой подходящего ролевого варианта (например, роли 411) целевой службы 205. Соответственно, контроллер 215 системы коммутации гарантирует, что имеется столько достижимых извне адресуемых входных оконечных точек, сколько есть составляющих программ, или ролей, клиентской службы, связанных с интерфейсом 220. Таким образом, каждая выходная оконечная точка соответствует единственной входной оконечной точке, тем самым выделяя единственный канал SLS и единственный сетевой адрес для маршрутизации вызова.

Что касается Фиг.6, показана блок-схема последовательности операций, которая демонстрирует полный способ 600 для автоматической реализации контракта и привязки реализованного контракта к целевой службе, в соответствии с вариантом осуществления настоящего изобретения. В дополнение, хотя термины "этап" и/или "блок" могут использоваться в данном документе для обозначения разных элементов применяемых способов, эти термины не должны интерпретироваться как подразумевающие какой-то конкретный порядок между различными раскрытыми в данном документе этапами, разве только за исключением случаев, когда порядок отдельных этапов описывается явно. Прежде всего, как изображено в блоке 605, идентифицируется контракт, который определяет совокупность интерфейсов. Дополнительно, контракт поддерживает набор свойств для инсталляции каждого из интерфейсов. Как изображено в блоке 610, идентифицированный контракт реализуется для установки интерфейса из совокупности интерфейсов в пределах распределенной вычислительной среды. Как правило, реализованный контракт представляет транспортное средство для клиентской службы для получения доступа к части целевой службы. Как изображено в блоке 615, реализованный контракт привязывается к целевой службе путем параметризации установленного интерфейса со значениями, полученными из набора свойств, связанных с установленным интерфейсом. В вариантах осуществления, процесс параметризации включает в себя автоматическое связывание установленного интерфейса и одного или более ролевых вариантов (см. блок 620), и сопоставление связей посредством контроллера системы коммутации, отвечающего за организацию исполнения целевой службы (см. блок 625). В порядке пояснения, ролевые варианты заключают в себе дублирования, по меньшей мере, одной роли, которая представляет тип составляющей программы, которая, при исполнении, предоставляет функциональные возможности целевой службе.

Обратимся теперь к Фиг.7, показана блок-схема последовательности операций, которая демонстрирует полный способ 700 для автоматического назначения реализованного контракта на основании зависимостей клиентской службы, и привязки к ней назначенного контракта, в соответствии с вариантом осуществления настоящего изобретения. Прежде всего, как изображено в блоке 705, от клиентской службы принимается указание на соответствие зависимости. Как обсуждалось выше, клиентская служба содержит одну или более составляющих программ. Как изображено в блоке 710, назначается контракт, раскрывающий обобщение функциональных возможностей, которые удовлетворяют зависимости составляющих программ клиентской службы. Как правило, контракт реализуется в пределах распределенной вычислительной среды и привязывается к целевой службе, которая производит функциональные возможности. Как указано в блоке 715, развертывается клиентская служба для инициализации ее работы. В вариантах осуществления, развертывание влечет автоматическое связывание составляющих программ с интерфейсом, определяемым назначенным привязанным контрактом (см. блок 720), и запись описания связей в контроллер системы коммутации, отвечающего за организацию исполнения целевой службы (см. блок 725). Вообще говоря, интерфейс устанавливается в пределах распределенной вычислительной среды после реализации назначенного привязанного контракта.

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

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

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

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