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

Чертежи

Описание

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

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

Для иллюстративного варианта осуществления, показанного на Фиг. 3, инфраструктура спроектирована для поддержки любой модели программирования, которая реализует прямое отображение из типов портов WSDL в типы классов управляемого кода во время выполнения инфраструктуры. Одна иллюстративная модель программирования использует атрибуты управляемого кода для установления ассоциативной связи между типами WSDL и типами управляемого кода. Модели программирования этого типа представляют собой классы управляемого кода, имеющие атрибуты, которые описывают взаимосвязь между классами управляемого кода и контрактом (набором четко определенных условий, регулирующих отношения между классом-сервером и его клиентами) WSDL типа порта, который они реализуют. Средства, которые реализуют модель программирования, способны либо генерировать WSDL из классов управляемого кода и интерфейсов, имеющих соответствующие атрибуты, либо генерировать классы управляемого кода и интерфейсы, имеющие соответствующие атрибуты из WSDL. Другие модели программирования могут включать в себя модели удаленных объектов, модели для описания логической последовательности бизнес-процессов и т. п. Таким образом, термин “служба” следует интерпретировать в более широком смысле для охвата этих и других моделей программирования.

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

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

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

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

На Фиг. 4А-4В показаны иллюстративные действия и этапы для способов абстрактного представления уровней обработки в инфраструктуре обмена сообщениями согласно настоящему изобретению. Этап (420) абстрактного представления одной или нескольких реализаций транспортировки сообщений на уровне сообщения может включать в себя действие (410) определения интерфейса уровня сообщения, который осуществляет абстракцию реализаций транспортировки сообщений. Примеры транспортировки сообщений включают в себя TCP 411, HTTP 413, SMTP 415 и другие виды 417 транспортировки. Порт 412 является примером абстракции транспортировки, которая обеспечивает состоящую из множества отдельных элементов абстракцию действия “послать сообщение/принять сообщение” для уровня канала.

Этап (440) абстрактного представления одной или более реализаций обмена сообщениями на уровне канала может включать в себя действие (430) определения интерфейса уровня канала, который осуществляет абстрактное представление одной или более реализаций обмена сообщениями. Примеры реализаций обмена сообщениями включают в себя дейтаграммы 431, диалоги 433, монологи 435, очереди 437 и другие реализации 439 обмена сообщениям. Реализация 430 обмена сообщениями или реализация канала являются примером абстракции обмена сообщениями.

Этап (490) абстрактного представления одной или более реализаций связывания на уровне службы может включать в себя действие (450) определения интерфейса уровня службы, который осуществляет абстракцию одной или нескольких реализаций связывания, которые связывают одну или несколько реализаций обмена сообщениями с пользовательским кодом или реализациями обработки сообщений. Пользовательский код 454, написанный в соответствии с моделями 451 программирования, оперирует экземплярами 452 обработки сообщений. Модель программирования А, модель программирования В, модель программирования С и т. д. являются примерами моделей 451 программирования, в соответствии с которыми соответствующие пользовательский код А1, пользовательский код А2, пользовательский код В1, пользовательский код В2, пользовательский код С1, пользовательский код С2 должны выполняться в качестве экземпляров 452 обработки сообщений. Этап (490) абстрактного представления одной или более реализаций связывания может дополнительно включать в себя: отображение (460) типов уровня сообщения в типы уровня службы (например, WSDL в типы управляемого кода), связывание (470) экземпляров обработки сообщений с экземплярами обмена сообщениями (например, экземпляры служб с экземплярами каналов) и управление (480) физическим временем существования экземпляров обработки сообщений (например, посредством хранилища службы).

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

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

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

Согласно фиг.5, иллюстративная система для реализации изобретения включает в себя вычислительное устройство общего назначения в виде обычного компьютера 520, содержащего процессор 521, системную память 522 и системную шину 523, которая подключает различные компоненты системы, включая системную память 522, к процессору 521. Системная шина может относиться к любой из нескольких шинных структур, включая шину памяти или контроллер памяти, периферийную шину и локальную шину, использующие любую из множества шинных архитектур. Системная память 522 включает в себя постоянную память (ПЗУ) 524 и оперативную память (ОЗУ) 525. Базовая система 526 ввода/вывода (BIOS), содержащая основные процедуры, помогающие переносить информацию между элементами персонального компьютера 520, например, при запуске, хранится в ПЗУ 524.

Компьютер 520 может также содержать накопитель 527 на жестких магнитных дисках для считывания с магнитного жесткого диска 539 и записи на него, привод 528 магнитного диска для чтения со сменного магнитного диска 529 или записи на него, и привод 530 оптического диска для чтения со сменного оптического диска 531, такого как CD-ROM или другой оптический носитель, или чтения или записи на него. Накопитель 527 на жестких магнитных дисках, привод 528 магнитного диска и привод 530 оптического диска подключены к системной шине 523 посредством интерфейса 532 накопителя на жестких магнитных дисках, интерфейса 533 привода магнитного диска и интерфейса 534 привода оптического диска, соответственно. Приводы и соответствующие им машиночитаемые носители обеспечивают энергонезависимые запоминающие устройства компьютера 520 для хранения машиноисполняемых инструкций, структур данных, программных модулей и других данных. Хотя в описанном предпочтительном варианте осуществления используется магнитный жесткий диск 539, сменный магнитный диск 529 и сменный оптический диск 531, можно использовать и другие типы машиночитаемых носителей, например магнитные кассеты, карты флэш-памяти, универсальные цифровые диски, картриджи Бернулли, ОЗУ, ПЗУ и т.п.

Средства программного кода, включающие в себя один или несколько программных модулей, могут храниться на жестком диск 539, магнитном диске 529, оптическом диске 531, в ПЗУ 524 или ОЗУ 525, включая операционную систему 535, одну или несколько прикладных программ 536, другие программные модули 537 и данные 538 программ. Пользователь может вводить команды и информацию в персональный компьютер 520 через клавиатуру 540, указательное устройство 542 или другие устройства ввода (не показаны), такие как микрофон, джойстик, игровая панель, спутниковая антенна, сканер и т.п. Для подключения этих и других устройств ввода к процессору 521 обычно используется интерфейс 546 последовательного порта, подключенный к системной шине 523. В качестве альтернативы, устройства ввода могут быть подключены через другие интерфейсы, такие как параллельный порт, игровой порт или универсальная последовательная шина (USB). Монитор 547 или устройство отображения другого типа также подключен к системной шине 523 через интерфейс, например видеоадаптер 548. Помимо монитора персональные компьютеры обычно включают в себя другие периферийные устройства вывода (не показаны), например громкоговорители или принтеры.

Компьютер 520 может работать в сетевой среде, используя логические соединения с одним или несколькими удаленными компьютерами, например, удаленными компьютерами 549а и 549b. Каждый из удаленных компьютеров 549а и 549b может представлять собой другой персональный компьютер, сервер, маршрутизатор, сетевой персональный компьютер, одноранговое устройство или другое общее сетевое устройство и обычно включает в себя многие или все элементы, описанные применительно к персональному компьютеру 520, хотя на Фиг. 5 изображены только запоминающие устройства 550а и 550b и ассоциированные с ними прикладные программы 536а и 536b. Логические соединения, показанные на Фиг. 5, включают в себя локальную сеть (ЛС) 551 и глобальную сеть (ГС) 552. Такие сетевые среды обычно имеют место в учреждениях, компьютерных сетях предприятия, интрасетях и сети Интернет.

При использовании сетевой среды ЛС персональный компьютер 520 подключен к ЛС 551 через сетевой интерфейс 553. При использовании в сетевой среде ГС персональный компьютер 520 обычно содержит модем 554 или иное средство установления связи через ГС 552, например Интернет. Модем 554, который может быть внутренним или внешним, подключен к системной шине 523 через интерфейс 546 последовательного порта. В сетевой среде программные модули, указанные применительно к компьютеру 520, или некоторые из них, могут храниться в удаленном запоминающем устройстве. Следует понимать, что показанные сетевые соединения носят иллюстративный характер, и что можно использовать другие средства установления линий связи через глобальную сеть 552.

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

Реферат

Изобретение относится к инфраструктуре обмена сообщениями. Абстрактное представление реализации транспортировки сообщений осуществляют на уровне сообщения, что позволяет другим уровням инфраструктуры обмена сообщениями взаимодействовать с сообщениями в более обобщенной форме, в основном независимо от транспортировки сообщений. Примеры транспортировки сообщений включают в себя именованные каналы, протокол управления передачей (TCP), протокол передачи гипертекста (HTTP), простой протокол передачи сообщений электронной почты (SMTP) и т.п. Уровень канала, расположенный над уровнем сообщения, осуществляет абстрактное представление реализации обмена сообщениями, что позволяет другим уровням инфраструктуры обмена сообщениями посылать и принимать сообщения в более обобщенной форме, в основном независимо от семантики обмена сообщениями конкретной реализации. Примеры обмена сообщениями включают в себя дейтаграммы, диалоги, монологи, очереди и т.п. Уровень службы, расположенный над уровнем канала и уровнем сообщения, осуществляет абстрактное представление реализации связывания, которые связывают реализации обмена сообщениями с реализациями пользовательского кода. 5 н. и 44 з.п. ф-лы, 7 ил.

Формула