Описание интерфейса программной компоненты

3.1. Сервисы и интерфейс программной компоненты

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

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

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

Если компонента системы передачи сообщений посылает сообщения ответы клиенту, то можно считать, что сервис такой компоненты имеет два адреса – один для очереди запросов и второй для очереди ответов (имя очереди ответов может быть задано и в сообщении запросе).

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

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

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

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

• полным адресом сервиса;
• единственной спецификацией принимаемых сервисом сообщений (запросов);
• единственной спецификацией принимаемых от сервиса сообщений (ответов).

Совокупность спецификаций всех сервисов программной компоненты образует ее интерфейс (рис. 3.1).

Рис. 3.1. Интерфейс компоненты распределенной системы

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

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

Языки описания интерфейса и спецификаций сообщений часто представлены на практике одним языком.

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