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

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

Иллюстрации

Показать все

Реферат

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

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

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

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

Фиг. 1А иллюстрирует пример соответствующей предшествующему уровню техники инфраструктуры 100А обмена сообщениями с непосредственными связями, основывающейся на распределенной модели компонентных объектов (DCOM). DCOM является расширением модели компонентных объектов (COM), которое позволяет компонентам обмениваться данными как в пределах сети, так и через границы сети, - СОМ ограничивала межпроцессный обмен данными пределами отдельной машины. Разработчик, намеревающийся использовать DCOM, принимает в связке модель 130А программирования DCOM, семантику 120А обмена сообщениями удаленного вызова процедур (RPC) и соответствующие сетевые коннектоиды (именованные соединения) 110А RPC.

Фиг. 1В иллюстрирует другой пример соответствующей предшествующему уровню техники инфраструктуры 100В обмена сообщениями с непосредственными связями. Подобно инфраструктуре DCOM, показанной на Фиг. 1А, эта отличающаяся инфраструктура 100В обмена сообщениями включает в себя другую модель 130В программирования, другую семантику 120В обмена сообщениями и другие сетевые коннектоиды 110В. Следует отметить, что взаимно сцепленные части 121В другой модели 130В программирования, другой семантики 120В обмена сообщениями и других сетевых коннектоидов 110В отличаются от взаимно сцепленных частей 121А модели 130А программирования DCOM, семантики 120А обмена сообщениями RPC и сетевых коннектоидов 110А RPC. Отличия между взаимно сцепленными частями 121А и 121В иллюстрируют характерное для предшествующего уровня техники отсутствие гибкости при выборе из разнообразия существующих и новых опций для разработки распределенных приложений. Выбрав DCOM или какую-либо другую технологию и ее соответствующую инфраструктуру, использование функциональных возможностей других технологий, не жертвуя при этом уже выполненным объемом работ по разработке существующих приложений, становится трудной задачей. Зачастую такие изменения или усовершенствования технологии требуют того, что работу приходится выполнять заново, по существу с нуля.

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

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

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

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

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

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

Перечень фигур чертежей

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

фиг. 1А-1В - примеры соответствующих предшествующему уровню техники инфраструктур с непосредственными связями;

фиг. 2 - высокоуровневое представление инфраструктуры обмена сообщениями согласно настоящему изобретению;

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

фиг. 4А-4В - иллюстративные действия и этапы для способов абстрактного представления уровней обработки инфраструктуры обмена сообщениями согласно настоящему изобретению;

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

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

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

Фиг. 2 иллюстрирует высокоуровневое представление иллюстративной инфраструктуры 200 обмена сообщениями согласно настоящему изобретению. Более детальное описание иллюстративной реализации инфраструктуры обмена сообщениями приведено ниже со ссылкой на Фиг. 3. Инфраструктура 200 поддерживает распределенное программирование посредством многоуровневой архитектуры (например, эту инфраструктуру можно рассматривать как упорядоченный набор подсистем, в котором каждая подсистема зависит от подсистем, предшествующих ей в этом наборе). Например, в инфраструктуре 200 обмена сообщениями основные уровни включают в себя уровень 210 сообщения, уровень 240 канала и уровень 270 службы.

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

Самый нижний уровень, уровень 210 сообщения, обеспечивает передачу или транспортировку сообщений от конечной точки к конечной точке. Уровень 210 передачи сообщений поддерживает возможность расширения транспортировки таким образом, что при реализации новой транспортировки сообщений ее смогут использовать другие уровни инфраструктуры. Например, уровень 210 сообщения осуществляет абстрактное представление реализаций транспортных протоколов, таких как именованные каналы, протокол управления передачей (ТСР), протокол передачи гипертекста (НТТР), простой протокол передачи сообщений электронной почты (SMTP) и т. п. Попросту говоря, уровень 210 сообщения обеспечивает состоящее из множества отдельных элементов абстрактное представление действия “послать сообщение/принять сообщение” для остальных уровней инфраструктуры так, чтобы эти остальные уровни могли обрабатывать сообщения в некоторой степени независимо от конкретного транспортного протокола, используемого для посылки и приема сообщений.

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

Уровень 240 канала обеспечивает абстрактные представления обмена сообщениями поверх абстрактных представлений транспортировки, обеспечиваемых уровнем 210 сообщения. Каналы представляют поведения, реализуемые между конечными точками, и объектную модель, которая осуществляет абстрактное представление реализуемых поведений. Примеры обычных каналов включают в себя каналы дейтаграмм для однонаправленной некоррелированной передачи сообщений, диалоговые каналы для двунаправленного коррелированного обмена сообщениями, монологовые каналы для публикации/подписки или однонаправленной широковещательной рассылки сообщений и каналы с очередью для однонаправленной передачи с организацией очереди. Приложение или пользовательский код использует каналы посредством создания экземпляров канала (например, экземпляра объекта “канал внутри памяти” (in-memory channel)) в конечной точке и посылки сообщений этим экземплярам. Когда сообщение достигает другой конечной точки, приложение или пользовательский код распознает канал, созданный на стороне отправителя канала и создает экземпляр канала для участия в разговоре (последовательности связанных информационных обменов в процессе выполнения).

Уровень 270 службы обеспечивает модели программирования поверх уровня 240 канала и уровня 210 сообщения. Разработчики прикладного программного обеспечения обычно будут использовать инфраструктуру 200 обмена сообщениями на уровне службы. Модели программирования уровня службы отличаются друг от друга механизмами диспетчеризации сообщений, тем, как посылаются сообщения (например, структуры по отношению к вызовам методов с проверкой типа) и системами типов. Уровень 270 службы обеспечивает общий механизм для связывания экземпляров модели программирования с вышеописанными экземплярами канала. Уровень 270 службы также обеспечивает те функциональные возможности, которые выбираются моделями программирования для предоставления разработчикам, такие как управление состоянием и временем существования, управление службой, перехват вызова и синхронизированная диспетчеризация сообщений. Для уровня службы можно разработать как простые, так и сложные модели программирования. Для содействия надлежащему связыванию и возможности взаимодействия модели программирования в общем случае определяют фиксированную взаимосвязь между типами транспортировки уровня сообщения и типами, определяемыми и управляемыми в самой инфраструктуре, в особенности типами, соответствующими объектам приложения или пользовательского кода на уровне 270 службы.

Фиг. 3 - блок-схема, показывающая иллюстративный вариант осуществления инфраструктуры 300 передачи сообщений согласно настоящему изобретению. В общем случае, инфраструктура 300 обмена сообщениями скомпонована из модулей, предназначенных для связывания экземпляров канала (например, объектов абстракции канала внутри памяти) с экземплярами кода, реализованного посредством поддерживаемых моделей программирования. Подобно описанию, приведенному выше в отношении Фиг. 2, Фиг. 3 включает в себя уровень 310 сообщения, уровень 340 канала и уровень 370 службы. Описание Фиг. 3 можно разделить на две общие категории: сама инфраструктура обмена сообщениями и модели программирования, которые поддерживает эта инфраструктура обмена сообщениями. Нижеследующее изложение начинается с описания инфраструктуры обмена сообщениями, а затем переходит к описанию иллюстративной модели программирования. Хотя ссылки на компоненты, показанные на Фиг. 3, могут быть в единственном числе, следует понимать, что множество экземпляров каждого компонента может присутствовать и зачастую присутствует в одной инфраструктуре.

Три средства управления, по одному на каждый уровень, реализуют большую часть базовых функциональных возможностей, обеспечиваемых инфраструктурой 300: порт 300 на уровне 310 сообщения, средство 342 управления каналом на уровне 340 канала и средство 382 управления службой на уровне 370 службы. Соответственно, описание по Фиг. 3 изначально сфокусировано на общем рассмотрении этих трех средств управления, а затем обращается к более детальному изложению этих трех средств управления и других проиллюстрированных компонентов. Первое из этих средств управления, порт 312, функционирует в качестве посредника между реализациями транспортировки и остальной частью инфраструктуры. Попросту говоря, порт 312 и уровень 310 сообщения обеспечивают состоящую из множества отдельных элементов абстракцию действия “послать сообщение/принять сообщение” для инфраструктуры 300 обмена сообщениями. Как было отмечено ранее, эта абстракция освобождает остальные уровни от необходимости понимания деталей, ассоциированных с отдельными реализациями транспортировки. Напротив, остальные уровни взаимодействуют с абстракцией сообщения и обходят детали того, как сообщения транспортируются на уровень 310 сообщения и порт 312.

Второе из трех средств управления, средство 342 управления каналом на уровне 340 канала, собирает и соотносит сообщения, возможно сохраняет и/или упорядочивает их и представляет высокоуровневую абстракцию канала уровню 370 службы в общем и средству 382 управления службой и средству 372 связывания службы в частности. Подобно абстракции сообщения, обеспечиваемой уровнем 310 сообщения, в данном контексте аналогично абстракция, обеспеченная уровнем канала и средством 342 управления каналом, освобождает остальные уровни от необходимости понимания деталей, ассоциированных с конкретной семантикой обмена сообщениями. Другие уровни просто взаимодействуют с абстракцией канала и обходят детали того, как осуществляется обмен сообщениями (например, посредством дейтаграмм, диалога и т. п.) с уровнем 340 канала.

Третье из трех средств управления, средство 382 управления службой, отвечает за соединение экземпляров 376 службы (экземпляров класса, реализованного в соответствии с одной из моделей программирования) с экземплярами 344 канала, созданными средством 342 управления каналом, которые предоставляют экземпляр абстракции канала соответствующим экземплярам службы. Средство 382 управления службой соединяет экземпляры 376 службы с экземплярами 344 канала с помощью средства 372 связывания службы, которое понимает детали как конкретного канала, так и конкретной модели программирования.

Средство 382 управления службой и средство 372 связывания службы связывают экземпляры 376 службы с экземплярами 344 канала, используя посредника 374 службы, который также описан ниже более подробно. После того, как экземпляры созданы, хранилище 378 службы осуществляет абстрактное представление их долговечности (например, времени существования и т. п.) и местоположения относительно остальной части инфраструктуры. Сообщения и вызовы, приходящие в экземпляры службы, могут быть перехвачены посредством кода, обеспечиваемого расширениями 392 службы, зарегистрированными средством 382 управления службой. Экземпляры службы обмениваются данными с инфраструктурой через интерфейс на экземплярах службы, называемый сайтом службы, который реализует функции, используемые экземпляром в общем случае. Сайт службы экземпляра инициализируется, когда хранилище службы создает этот экземпляр.

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

Средство 372 связывания службы отвечает за управление взаимосвязями между экземплярами 344 канала, экземплярами 376 службы и хранилищами 378 службы. Соответственно, средство 372 связывания службы обычно обладает специфическим знанием о каждом доступном канале и модели программирования. Каналы реализуют характерные события и интерфейсы, которые средство 372 связывания службы использует для перемещения сообщений на уровень 340 канала и за его пределы. Модели программирования определяют отображение между типами, которые средство связывания службы использует для подачи сообщений к методам, и преобразования вызовов методов в сообщения. Поскольку каждая пара из канала и модели программирования отличаются от других, средство связывания службы обычно поддерживает один элемент пары. Соответственно, выполняющийся порт ассоциирован с одним или более средств связывания службы для каждой поддерживаемой пары канал/модель программирования.

Иллюстративная модель программирования может выполнять отображение между типом порта языка определения Web-служб (WSDL) и управляемым типом во время выполнения инфраструктуры. WSDL представляет собой формат XML (расширяемая спецификация языка разметки), который описывает сетевые службы в качестве набора конечных точек, которые могут обмениваться сообщениями. Он обеспечивает относительно простой механизм определения базового формата запросов, независимого от нижерасположенного протокола (простого протокола доступа к объектам (SOAP), HTTP GET/POST и т. п.) или кодировки (многоцелевых расширений электронной почты в сети Internet (MIME) и т. п.). Абстрактные операции и сообщения связываются с конкретными сетевыми протоколами и форматами сообщений для определения конечной точки. Соответственно, службы WSDL представляют собой совокупности конечных точек, также известных как порты. В случае WSDL типы портов описывают совокупности операций. Следует оценить тот факт, что на Фиг. 3 показан иллюстративный вариант осуществления настоящего изобретения, в котором инфраструктура включает в себя типы управляемого кода/данных, которые отображаются в WSDL. Однако настоящее изобретение можно реализовать на практике в разнообразных вариантах осуществления, и оно не ограничено вариантами осуществления с типами управляемого кода/данных или типами портов WSDL.

В соответствии с вышесказанным средства 372 связывания службы регистрируются средством 382 управления службой во время создания порта. Средства связывания службы ассоциированы с набором типов портов/служб. Уникальность типов по всем средствам связывания службы основывается на управляемых типах во время выполнения инфраструктуры, которые реализуют службу, наследуемую от типов интерфейса, которые являются уникальными для средства связывания службы. Для иллюстративной инфраструктуры 300 процесс, который открывает порт, также открывает и средство 382 управления службой и все средства 372 связывания службы, доступные в этом порте. После открытия, средства связывания службы соединяются с соответствующими им средствами 342 управления каналом.

Когда пользовательский код выполняет вызов в средство 382 управления службой для создания канала, средство управления службой выполняет цикл по набору зарегистрированных средств связывания службы и предоставляет каждому из них возможность взаимодействовать с заданным типом. Затем средство управления службой использует средство связывания службы, которое распознает заданный тип с целью создания экземпляра 376 службы, регистрации его хранилищем 378 службы и связывания этого экземпляра службы с экземпляром 344 канала с помощью посредника 374 службы. Аналогично, когда сообщение поступает в канал, который не ассоциирован с существующим экземпляром службы, набор средств связывания службы, присоединенных к каналу, опрашивается на предмет того, распознают ли они тип входящего порта/службы. Средство 372 связывания службы, которое распознает упомянутый тип, используется для создания экземпляра службы, связывания его с экземпляром канала с помощью посредника службы и затем для направления потока входящих сообщений через упомянутые экземпляры и посредника к пользовательскому коду.

Для выдачи запроса на новый экземпляр средство связывания службы создает экземпляр 376 службы, регистрирует его хранилищем 378 службы, создает посредника 374 службы, соединяет экземпляр 344 канала и посредника 374 службы с пользовательским кодом и запускает прохождение первого сообщения по каналу. Затем сообщения проходят от экземпляра канала к посреднику 374 службы, который преобразует их в стеки вызовов и отправляет их к соответствующему экземпляру службы. Аналогично, вызовы проходят от экземпляра 376 службы к посреднику 374 службы, который преобразует их в сообщения и посылает их через экземпляр канала в их пункт назначения.

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

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

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

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

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

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

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

В дополнение к портам 312, средства 342 управления каналом, средство 382 управления службой и другие средства управления могут существовать в инфраструктуре 300. Эти средства управления реализуют поведения на некоторых или на всех уровнях инфраструктуры, включая фильтрацию и маршрутизацию сообщений, замену и применение политик, безопасность, ведение журнала регистрации и службы на основе транзакций. Каждое средство управления, которое обеспечивает возможность расширения, определяет интерфейс расширения для разрешения другим средствам управления реализовать эту возможность расширения. Например, порт 312 на уровне 310 сообщения поддерживает расширение порта, позволяющее средствам управления добавлять средства обработки к потоку сообщений конвейеров, проходящему на этом уровне. Аналогично, отдельные средства управления каналом реализуют расширения, позволяющие модулям, таким как средство управления службой, перехватывать сообщения с целью создания экземпляров канала из канала.

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

Экземпляр 376 службы - это экземпляр типа управляемого кода службы, который реализует интерфейс, ассоциированный с типом порта/службы, возможно, посредством упаковщика (программного средства создания системной оболочки для стандартизации внешних обращений и изменения функциональной ориентации действующей системы), определенного как часть модели программирования. В общем случае, как описывается более подробно ниже, один из аспектов, которым отличаются модели программирования, состоит в способе, которым разговор ассоциирован с интерфейсами и методами типа службы. Для иллюстративного варианта осуществления, показанного на Фиг. 3, типы служб, написанные в отношении адекватных моделей программирования, имеют прямые соответствия между разговорами, операциями и сообщениями WSDL и управляемыми во время выполнения инфраструктуры интерфейсами, методами и типами аргументов в виде кода. Инфраструктуры также могут поддерживать типы служб, созданные с использованием других моделей программирования, которые могут выглядеть совсем иначе. В дополнение к интерфейсам, используемым ассоциированным посредником службы, типы служб могут реализов