4.4 Поддержка средств распределенной разработки

В настоящий момент в Microsoft.NET Framework Class Library присутствует поддержка четырех промежуточных сред для построения распределенных систем:

– Среда Microsoft Message Queuing (MSMQ) поддерживает обмен сообщениями между программными компонентами на основе очередей.

– Среда Microsoft Enterprise Services основана на модели COM+, которая позволяет использовать удаленные объекты и распределенные транзакции в локальной сети.

– Среда ASP .NET Web Services позволяет организовать удаленный вызов на основе общепринятых стандартов, базирующихся на языке XML.

- Среда .NET Remoting была разработана как универсальная промежуточная среда для использования удаленных объектов.

В настоящее время ведутся работы по интеграции этих сред в единую универсальную среду распределенной разработки. Так, в версии .NET Framework 3.0 предполагается ввести технологию WCF (Windows Communication Foundation), объединяющую все упомянутые технологии построения распределенных систем. Кроме указанных технологий, приложения на .NET Framework могут использовать, например, удаленные вызовы на основе стандарта XML-RPC при подключении дополнительных библиотек.

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

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

– методы активируемого сервером объекта;

– активируемый клиентом объект вместе со своими полями, свойствами и методами;

– очередь с сообщениями-запросами, которые считываются программной компонентой.

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

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

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

– полным адресом сервиса;

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

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

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

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

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

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

– язык описания спецификаций сообщений, определяющий корректные сообщения для сервисов компоненты;

– язык описания интерфейса компоненты, определяющий набор ее сервисов.

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

Примечания

1. Процесс преобразования параметров для передачи их между процессами (или доменами приложения в случае использования .NET) при удаленном вызове называется маршализацией (marshaling).

2. Преобразование экземпляра какого-либо типа данных в пригодный для передачи за границы вызывающего процесса набор байт называется сериализацией.

3. Десериализация – процедура, обратная сериализации – заключается в создании копии сериализованного объекта на основе полученного набора байт.

Такой подход к передаче объекта между процессами путем создания его копий называется маршализацией по значению (marshal by value), в отличие от маршализации по ссылке.

Для систем удаленного вызова спецификацией интерфейса может являться описание класса .NET.

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

В качестве такого языка в РС все чаще применяется XML, в частности, такие его реализации как XSD, SOAP, WSDL.

Поскольку протокол HTTP был как наиболее распространенным, так и повсеместно разрешенным в межсетевых экранах протоколом, то он был выбран в качестве стандартного транспортного протокола для создания гетерогенных промежуточных сред. Поэтому использующая SOAP и WSDL промежуточная среда получила названия веб-служб (web services). Она использует два дополнительных языка – язык описания сообщения SOAP (пространство имен SOAP версии 1.1 – http://schemas.xmlsoap.org/soap/envelope/, версии 1.2 – http://schemas.xmlsoap.org/wsdl/soap12/) и язык описания сервисов и интерфейсов WSDL (пространство имен http://schemas.xmlsoap.org/wsdl/).

Рекомендация SOAP изначально разрабатывалась как спецификация для удаленного вызова методов и расшифровывалась как Simple Object Access Protocol. Сообщение SOAP представляет собой XML-документ, называемый конвертом или пакетом (envelope), содержащий заголовки с метаинформацией в элементе soap:Header и тело сообщения в элементе soap:Body. В заголовках пакета содержится дополнительная информация, которая может использоваться промежуточной средой.

В качестве примера рассмотрим простейшие сообщения SOAP версии 1.2 для сервиса, складывающего два числа. Сообщение-запрос использует пространство имен http://summa.test/webservices, которое описано в интерфейсе компоненты. В элементе message содержатся сами складываемые числа.

<?xml version="1.0" encoding="utf-8"?>

<soap12:Envelope xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">

<soap12:Body>

<Add xmlns="http://summa.test/webservices">

   <message>

       <a>1</a>

       <b>2</b>

   </message>

</Add>

</soap12:Body>

</soap12:Envelope>

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

<?xml version="1.0" encoding="utf-8"?>

<soap12:Envelope xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">

<soap12:Body>

 <AddResponse xmlns="http://summa.test/webservices">

      <AddResult>3</AddResult>

 </AddResponse>

</soap12:Body>

</soap12:Envelope>

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

Для описания интерфейса программной компоненты был разработан язык WSDL (Web Service Definition Language). Описание на языке WSDL включает в себя следующие семь составляющих.

1. Описание типов передаваемых данных. При использовании кодирования SOAP-Document оно состоит из схемы XML, определяющей корректные сообщения, получаемые программной компонентой в теле пакета SOAP.

2. Описание входящих и исходящих сообщений, которые связываются с описанными типами данных.

3. Описание операций (сервисов программной компоненты), с каждой из которых связывается входящее и исходящее сообщение.

4. Описание типов портов (идентификаторов программных компонент), с каждым из которых связывается некоторый набор операций.

5. Описание привязок (binding), связывающие типы портов и их сообщений с определенным типом кодирования тела пакета, а также с версией протокола SOAP.

6. Описание портов, связывающие типы портов и соответствующие им привязки с конкретными URL.

7. Общее описание службы (интерфейса программной компоненты) как совокупности портов.

Далее рассмотрено описание на языке WSDL интерфейса компоненты, которое содержит два сервиса – сложение двух чисел и сложение последовательности чисел. В корневом элементе указаны все используемые пространства имен, включая пространство протокола SOAP 1.2 – http://schemas.xmlsoap.org/wsdl/soap12/.

Начало описания XML-документа

<?xml version="1.0" encoding="utf-8"?>

<wsdl:definitions

    xmlns:tns="http://summa.test/webservices"

    xmlns:s="http://www.w3.org/2001/XMLSchema"

    xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"

    targetNamespace="http://summa.test/webservices"

    xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">

В элементе wsdl:types описываются все типы данных. Тип Add будет связан со входящим сообщением сервиса сложения двух чисел, а тип AddResponse – с его исходящим сообщением.

<wsdl:types>

   <s:schema elementFormDefault="qualified"

          targetNamespace="http://summa.test/webservices">

     <s:element name="Add">

        <s:complexType>

            <s:sequence>

                 <s:element minOccurs="1" maxOccurs="1" name="message"

                          type="tns:AddMessage" />

            </s:sequence>

            </s:complexType>

      </s:element>

      <s:complexType name="AddMessage">

          <s:sequence>

                <s:element minOccurs="1" maxOccurs="1" name="a" type="s:int" />

                <s:element minOccurs="1" maxOccurs="1" name="b" type="s:int" />

           </s:sequence>

          </s:complexType>

      <s:element name="AddResponse">

          <s:complexType>

             <s:sequence>

                   <s:element minOccurs="1" maxOccurs="1" name="AddResult" type="s:int" />

             </s:sequence>

          </s:complexType>

                        </s:element>

Типы SumList и SumListResponse предназначены для сообщений сервиса сложения списка чисел.

<s:element name="SumList">

  <s:complexType>

     <s:sequence>

         <s:element minOccurs="0" maxOccurs="1" name="list"

                  type="tns:ArrayOfInt" />

         </s:sequence>

  </s:complexType>

</s:element>

<s:complexType name="ArrayOfInt">

<s:sequence>

    <s:element minOccurs="0" maxOccurs="unbounded" name="int" type="s:int" />

</s:sequence>

</s:complexType>

   <s:element name="SumListResponse">

    <s:complexType>

        <s:sequence>

            <s:element minOccurs="1" maxOccurs="1" name="SumListResult"

                  type="s:int" />

        </s:sequence>

    </s:complexType>

   </s:element>

</s:schema>

</wsdl:types>

В элементах wsdl:message типы данных связываются с идентификаторами сообщений.

<wsdl:message name="AddSoapIn">

      <wsdl:part name="parameters" element="tns:Add" />

</wsdl:message>

       <wsdl:message name="AddSoapOut">

         <wsdl:part name="parameters" element="tns:AddResponse" />

</wsdl:message>

       <wsdl:message name="SumListSoapIn">

       <wsdl:part name="parameters" element="tns:SumList" />

</wsdl:message>

       <wsdl:message name="SumListSoapOut">

       <wsdl:part name="parameters" element="tns:SumListResponse" />

</wsdl:message>

В элементе wsdl:portType описываются абстрактные операции и используемые ими сообщения.

<wsdl:portType name="MathServiceSoap">

  <wsdl:operation name="Add">

      <wsdl:documentation xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">

              Операция Add складывает два числа

      </wsdl:documentation>

      <wsdl:input message="tns:AddSoapIn" />

      <wsdl:output message="tns:AddSoapOut" />

  </wsdl:operation>

  <wsdl:operation name="SumList">

           <wsdl:documentation xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">

                Операция SumList складывает несколько чисел

           </wsdl:documentation>

          <wsdl:input message="tns:SumListSoapIn" />

          <wsdl:output message="tns:SumListSoapOut" />

  </wsdl:operation>

</wsdl:portType>

В элементе wsdl:binding операции связываются с транспортным протоколом (HTTP),

версией протокола SOAP (1.2) и типом кодирования тела пакета (SOAP-Document).

<wsdl:binding name="MathServiceSoap12" type="tns:MathServiceSoap">

     <soap12:binding transport="http://schemas.xmlsoap.org/soap/http" />

        <wsdl:operation name="Add">

      <soap12:operation soapAction="http://summa.test/webservices/Add"

                style="document" />

      <wsdl:input>

           <soap12:body use="literal" />

      </wsdl:input>

      <wsdl:output>

           <soap12:body use="literal" />

      </wsdl:output>

      </wsdl:operation>

              <wsdl:operation name="SumList">

               <soap12:operation soapAction="http://summa.test/webservices/SumList"

                        style="document" />

               <wsdl:input>

                   <soap12:body use="literal" />

             </wsdl:input>

             <wsdl:output>

                   <soap12:body use="literal" />

              </wsdl:output>

             </wsdl:operation>

      </wsdl:binding>

В элементе wsdl:service интерфейс программной компоненты связывается с типом порта, с некоторой привязкой, а также с конкретным URL, используемым в дальнейшем для вызова веб-службы.

<wsdl:service name="MathService">

       <wsdl:port name="MathServiceSoap12" binding="tns:MathServiceSoap12">

                <soap12:address location="http://summa.test/webservices/summa.asmx" />

       </wsdl:port>

</wsdl:service>

</wsdl:definitions>

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

Для создания открытой распределенной системы необходимо использование общепринятых языков описания интерфейса программной компоненты. В настоящий момент существует ряд апробированных на практике стандартов для передачи данных в гетерогенных распределенных системах: XML, XSD, SOAP и WSDL. Их использование позволяет создавать системы, не привязанные жестко к какому-либо средству разработки программ или транспортному протоколу.