1. 1Место технологий рвс 5 icon

1. 1Место технологий рвс 5


Смотрите также:
1   2   3   4   5
вернуться в начало

^ Жизненный цикл объектов.

Разработка

Проектирование (интерфейсов). Сравнить IDL и WSDL.

Принятие решения о выборе между статическими или динамическими режимами вызовов методов (на клиентской стороне) и обработки вызовов на серверной стороне (универсальность<>производительности, зависит от возможностей ППО).

Генерация стандартизованных стабов/скелетонов (исходных кодов на выбранных языках высокого уровня); специальные средства (предкомпиляторы).

Реализация серверных фрагментов.

^ Регистрация типов интерфейсов

Функционирование

Серверная часть

Запуск «серверного» процесса (с черными кружочками).

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

Обработка заявок.

Остановка, возможно, с сохранением состояния.

^ Клиентская часть.

Обеспечение клиентской программы «адресом» нужного ей объекта (объектная ссылка); в виде файла или «имени» (идентификатора) на службе регистрации.

Вызов удаленного объекта.

  1. Этапы разработки РВС (CORBA)

Существует большой выбор комплектов разработчика систем на базе CORBA от различных поставщиков и ориентированных на разные языки программирования. Но везде присутствуют следующие необходимые элементы:

  • предкомпилятор языка IDL;

  • набор файлов на языке IDL, содержащих описание стандартных интерфейсов и служб (согласно стандартам OMG);

  • набор готовых компонентов - реализация ядра ORB и некоторого подмножества стандартных служб CORBA (в минимальной конфигурации - служба наименований и репозиторий интерфейсов).




  1. Проектирование интерфейсов на языке IDL;

  2. Использование предкомпилятора IDL;

  3. Реализация серванта и клиентской части приложения на уровне исходных кодов

  4. Компиляция исходных кодов




    1. Проектирование интерфейсов на языке IDL.

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


module Our_System {

interface Summator {

attribute string name;

long getSum();

long addValue( in long increment );

};

};

  1. Пример описания интерфейса на языке IDL.

Интерфейс на Summator имеет один текстовый атрибут name, который мы будем интерпретировать как «имя» объекта, и два метода:

  1. getSum() - метод без параметров возвращающий текущее значение счетчика в виде целого числа;

  2. addValue( in long increment ) - метод с одним передаваемым (на это указывает ключевой слово in ) целочисленным параметром (возможно - отрицательным), который следует прибавить к текущему значению счетчика; метод возвращает новое значение счетчика.

Следует сказать, что отличие атрибута от метода достаточно условно и, как мы увидим, на уровне реализации практически ничем не отличается.

      1. ^ Использование предкомпилятора IDL

Обязательным элементом любого комплекта разработчика является специальная программа, т.н. предкомпилятор с языка IDL.

Назначение этой утилиты - по имеющимся файлам IDL сгенерировать стандартные фрагменты кода для стабов и скелетонов на соответствующем языке программирования.

Например, если воспользоваться JavaIDL - простейшим комплектом разработки CORBA приложений на языке Java, то следует отдать команду

idlj -fserver -fclient Sum.idl,

где Sum.idl - файл, содержащий текст, приведенный на .

В результате будут созданы несколько файлов на языке Java, назначение которых комментируется в следующей таблице:

Имя файла (все с расширением .java)

Назначение

В каком фрагменте кода понадобится

серверный

клиентский

Summator

Базовый класс для объектов типа "сумматор".

x

x

SummatorOperations

Абстрактный класс (в Java - типа interface) содержащий отображение методов и атрибутов интерфейса на язык Java, но без реализации.

x

x

_SummatorImplBase

Фрагмент кода, содержащий скелетон интерфейса.

x




_SummatorStub

Фрагмент кода, содержащий представитель (стаб) интерфейса.




x

SummatorHelper

Специальный вспомогательный класс, содержащий набор методов, необходимых клиентской стороне (обычно - для манипуляций с объектными ссылками)




x

  1. ^ Результат работы предкомпилятора JavaIDL


Чтобы понять каким образом произошло "языковое связывание" в данном случае, приведем содержание файла

SummatorOperations.java:


SummatorOperations.java:


package Our_System;

public interface SummatorOperations

{

String name ();

void name (String newName);

int getSum ();

int addValue (int increment);

}

  1. Пример отображения интерфейса IDL на язык Java.


Таким образом (см. ):

  • имя модуля превратилось в название пакета Java;

  • наличие атрибута name привело к появлению двух методов - для чтения текущего значения атрибута (String name()) и для задания нового значения (void name (String newName));

  • методы getSum и addValue превратились в "обычные" методы, причем IDL тип данных long преобразовался в тип int.


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


класс (интерфейс) CORBA объекта Summator в файле Summator.java:

public interface Summator extends SummatorOperations, org.omg.CORBA.Object, org.omg.CORBA.portable.IDLEntity

класс _SummatorImplBase скелетона в файле _SummatorImplBase.java:

public abstract class _SummatorImplBase extends org.omg.CORBA.portable.ObjectImpl implements Our_System.Summator, org.omg.CORBA.portable.InvokeHandler

класс _SummatorStub стаба в файле _SummatorStub.java:

public class _SummatorStub extends org.omg.CORBA.portable.ObjectImpl implements Our_System.Summator



      1. ^ Реализация серванта и клиентской части приложения на уровне исходных кодов

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

Для реализации серванта можно создать класс SummatorServant, наследуя готовый класс _SummatorImplBase:


public class SummatorServant extends _SummatorImplBase,

в котором придется определить поведение всех функций, объявленных в интерфейсе SummatorOperations (см. ).

Для создания экземпляра CORBA объекта типа Summator, (а фактически - для создания реализации CORBA объекта) достаточно объявить переменную этого класса (в языке Java это будет объектная ссылка) и воспользоваться оператором new для создания экземпляра объекта заданного типа (стандартная схема создания экземпляров объектов в Java):


^ Our_System.Summator theFirstCounter = new SummatorServant();

При необходимости можно создать несколько экземпляров таких объектов.


Мы пропустили несколько технических деталей: подключение к ядру ORB; активация и подключение к Объектному Адаптеру; регистрация на нем созданного объекта; "опубликование" его объектной ссылки, чтобы сделать объект доступным для клиентских частей системы.


В клиентской программе, необходимо предусмотреть механизм получения объектной ссылки на нужный экземпляр CORBA объекта. Для этого удобнее всего воспользоваться CORBA службой Именований (Naming Service), о которой мы поговорим позднее.

Когда объектная ссылка получена (в Java она является ссылкой на объект класса org.omg.CORBA.Object), ее необходимо преобразовать к типу Summator. Для этого и нужен класс SummatorHelper (см. ). Соответствующие фрагменты кода имеют вид:


org.omg.CORBA.Object ior; //ссылка на нетипизированный объект

// присваивание нужного значения ссылке ior

...

//Объявление переменной типа Summator и приведение ior

//к нужному типу при помощи специального метода narrow

//класса Helper

Our_System.Summator theProxyForTheFirstCounter = Our_System.SummatorHelper.narrow (ior)

  1. Простейший пример фрагмента клиентского кода


Теперь можно использовать объект theProxyForTheFirstCounter для вызова методов объекта theFirstCounter из серверной части кода.


      1. ^ Компиляция исходных кодов

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

Результат компиляции естественно зависит от используемого языка. Например, в при использовании Java, распределенное приложение будет представлять собой набор файлов *.class (возможно - упакованных в архивы *.jar). И для их запуска нужно использовать среду исполнения Java. Если часть распределенного приложения представляет собой Java апплет, то для запуска понадобится браузер.

В случае использования языка C (C++) результатом работы этого этапа будут либо исполняемые файлы *.exe, либо библиотеки динамической компиляции *.dll (на платформе Microsoft) или *.so (на платформе Unix, Linux).




^ Общий вид распределенной системы с использованием стандартных служб.

Стандартные службы CORBA

^ Название службы

Краткая характеристика

Naming Service (Служба именования)

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

Trading Object Service (Объектный трейдер)

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

Query Service (Сервис запросов)

Результат инициативы Sybase, IBM, SunSoft и Taligent - основных разработчиков систем управления объектными базами данных. Позволяет находить объекты, удовлетворяющие определенным критериям. Использует специальный язык запросов типа SQL.

Collections Service (Сервис контейнеров объектов)

Позволяет управлять группами объектов, объединяя их в контейнеры: очереди, списки, массивы, деревья и т.д.

Relationship Service (Сервис сообщений)

Позволяет устанавливать и управлять отношениями между объектами. Например, владения, содержания (включения), ссылки.

Life Cycle Service (Сервис жизненного цикла объекта)

Помогает управлять созданием, копированием, перемещением и удалением объектов. В случае связанных между собой объектов использует интерфейсы Relationship Service.

Time Service (Сервис времени)

Помогает синхронизировать время в распределенных системах. Необходим в задачах "реального времени". Использует стандарт UTC (Universal Time Coordinated) и совместим с существующим системами, например, X/Open DCE Time Service

Event Service (Сервис событий)

Представляет собой пример MOM (Message Oriented Middleware) Позволяет организовать взаимодействие компонентов распределенной системы посредством асинхронного обмена сообщениями.

Notification Service (Расширенный сервис событий)

Расширяет Event Service, добавляя новые возможности. Например, поддержку "типизированных" событий, имеющих внутреннюю структуру; фильтрацию рассылаемых сообщений и возможность управлять этими фильтрами.

Object Transaction Service (OTS) (Сервис объектных транзакций)

Позволяет множеству распределенных объектов взаимодействовать в рамках "неделимых транзакций", даже при наличии серьезных аппаратных или программных сбоев. Чрезвычайно полезен для работы с базами данных. Поддерживает "вложенные" транзакции.

Concurrency Service (Сервис контроля совместного доступа)

Позволяет объектам координировать обращения к совместно используемым ресурсам посредством механизма блокировок.

Persistent Object Service (Сервис долговременного хранения)

Предназначена для сохранения и восстановления состояния объекта, в ситуации временного отключения серверного процесса. Появился по инициативе IBM и SunSoft. Существующие реализации тесно связаны с реляционными базами данных.

Externalization Service (Сервис внешнего представления)

Принцип работы напоминает механизм сериализации (serialization) объектов в языке Java, когда текущее состояние "бинарное" объекта записывается в потоковый файл или, наоборот, восстанавливается из файла.



Кроме этого, крупные фирмы-разработчики постоянно предлагают свои специализированные службы, например Telecom Log Service.


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


^ Event & Notification Services




  1. Схема работы CORBA Event Service



- The OrbZone - http://www.orbzone.org -

What is the difference between the CORBA Notification Service and the CORBA Event Service?

Posted By sylvia On 14th November 2005 @ 16:02 In Recent Articles | No Comments

The Notification Service can be considered to be a mature extension of the Event Service. The Event Service provided a model to support decoupled communication, it was and is quite simplistic. It provides two models for supplying events, push and pull, and the event data can either be typed or untyped. The event server itself provides no quality of service or persistence.

So what makes the Notification Service a more mature version of this?

The Notification Service could be looked upon as a much more powerful version of the Event Service. It keeps everything that the Event Service has, but provides many additional and powerful features which enable you to implement sophisticated, intelligent event-based communication.

As well as typed and untyped data events, there is also the new native "structured" event. This allows the transmission of a well-defined data structure in addition to the untyped Any. Due to the well-defined message structure extra information can be associated with the event such as filtering and quality of service (QoS) details.

The Notification Service supports content based filtering on event data. Consumers can indicate what types of events they want to receive by providing a filter constraint. Filter objects can be associated with each proxy and/or with the administration object. Filtering is defined using an extension of the Trading constraint language.

The Notification Service introduces quality of service (QoS). This allows QoS to be assigned at different levels of granularity. For example, QoS can be assigned on an event level using the structured event, or QoS can be assigned on a notification channel basis. QoS properties such as reliability and priority can be used to indicate the delivery characteristics of events.

Notification channel persistence can be obtained using the EventReliability and ConnectionReliability QoS. If these properties are set to persistent then the Notification channel will store all event information and all connection information. On a restart, the channel will use this information to restore itself to its previous consistent state.

Consumers can use the mapping filter to assign priorities to events. Depending on the QoS OrderPolicy this may affect the order in which events are delivered to the consumer.

Using the NotifyPublish interface it is possible to prevent unwanted events being put on the network. Suppliers can determine what types of events are being listened on. If no consumers are interested in receiving a particular event type then the supplier will not send the event to notification channel. New consumers can also use the NotifyPublish interface to find out which types of events are currently available.

From The OrbZone: http://www.orbzone.org URL to article: http://www.orbzone.org/?p=85




Структура "сообщения" Notification Service




Фильтры в Notification Service



Получение ссылки через Implementation Repository (Orbacus)




Автоматический запуск серверных процессов посредством

Implementation Repository (Orbacus)


"Домены" серверов IMR



Каждый IMR управляет своим доменом "хостов"


Web-сервисы




Пример архитектуры одной из систем на основе Web-сервисов (WASP Architecture)

^ Oracle snaps up Collaxa


By Martin LaMonica


Oracle on Tuesday (~June 29, 2004) announced the acquisition of Collaxa and plans to incorporate the company's business process automation software into Oracle's Java server software line.


Privately held Collaxa, which was founded in 2000, sells a business process management "engine," or software that collects data from different applications to complete a particular business process, such as handling insurance claims. Collaxa was one of the first companies to build its product around the Business Process Execution Language (BPEL), a Web services specification under development. BPEL is designed to be an XML-based industry standard for business process management.


Thomas Kurian, Oracle's senior vice president for Oracle Application Server and application development tools, is expected to announce the Collaxa deal at a keynote speech Tuesday afternoon at the JavaOne conference in San Francisco. Kurian also plans to say that Oracle will release MacOS X versions of its Oracle Application Server 10G and JDeveloper Java programming tools this fall.


Oracle has already renamed the Collaxa software Oracle BPEL Process Manager and has made it available for download for free evaluation. It can be purchased as an add-on option to Oracle Application Server Enterprise Edition for $10,000 or as a standalone product for $30,000. The BPEL Process Manager software can run on any Java 2 Enterprise Edition (J2EE) application server.


The field of business process management has drawn increasing attention from large companies, such as Microsoft, IBM, Oracle and BEA Systems, as well as dozens of specialized start-up companies.


Analysts say process workflow tools that use Web services are a central component to creating a service-oriented architecture, a modular system design for exhanging data between systems cost-effectively and reusing software components across many applications.


Oracle said the software will fill out its Java server line and provide tools for more rapidly building applications that automate business processes.


"Oracle made this acquisition to complete our services oriented architecture and integration technology stack," said Cheng. "We already have the infrastructure from our core application server based on Java. This adds a piece for orchestrating Web services."


On top of running business process workflow applications, the BPEL Process Manager software provides so-called business activity monitoring tools to report on the progress of a process that is under way. The software also includes "adapters" that transport data between packaged applications, such as SAP's R/3 and Siebel, Oracle said.

Лекция ##

^ Web-сервисы и связанные с этим тенденции развития технологий РВС


До сих пор обсуждались CORBA, COM – являющиеся развитием ОО модели программирования

Та группа технологий, что обычно подразумевается под термином WS, основана на другой модели программирования.

SOA - Service Oriented Architecture. Я считаю термин «сервис» неудачным, поскольку он требует доп. разъяснений (ООП – содержит разъяснение «в себе», если, конечно, быть знакомым с современными языками ОО программирования).

Лучше говорить – о модели программирования, основанной на обмене структурами данных (часто еще называют «документами»). Заметьте, что RPC, очевидно будет частным случаем, такой модели:

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

• SOA Service Oriented Architecture

• UDDI Universal Definition, Discovery and Integration

(of Web Services)

• W3C World Wide Web Consortium

• WS Web Service

• WSDL Web Service Description Language

• WS-I Web Services Interoperability organization

• WSID Web Services Interoperability Demonstration

• XML Extensible Markup Language

• XSLT XML Stylesheet Language (Transform)

Чтобы не рассуждать абстрактно, я хочу рассмотреть стремительно развивающуюся (буквально за последние год-два) технологию AJAX (Asynch. JavaScript API for XML).

Google Map, Mail, ???

Нарисовать примерную архитектуру AJAX:

источник данных в формате XML

асинхронные обращения к источнику (XmlHttpRequest)

преобразование (XML-parsers, XSLT) и кэширование преобразованных данных,

GUI и «локальное» использование полученных данных


^ Обмен документами XML, в том числе асинхронный, поверх сложившейся транспортной сетевой инфраструктуры.

WS часто заменяют гораздо более узким понятием SOAP

Идея SOAP – зачем использовать спец. протоколы GIOP/IIOP если весь мир покрыт средой HTTP/SMTP/POP/FTP.

^ SOAP ~ XML-RPC ~ XML + HTTP POST

Напомнить HTTP POST, XML сообщение в кач-ве «полезной нагрузки».








Simple Object Access Protocol (SOAP) – основанный на XML протокол, предназначенный для обмена информацией в распределенных системах. SOAP устанавливает стандарт взаимодействия клиент-сервер и регламентирует, как должен осуществляться вызов, передаваться параметры и возвращаемые значения. Для представления любой информации, передаваемой от клиента к серверу и наоборот, используется XML.


ПРИМЕЧАНИЕ


SOAP не накладывает ограничений на используемый транспорт. Для передачи сообщений могут использоваться любые протоколы и продукты, например, протоколы HTTP, HTTPS, SMTP. Данные могут передаваться через Microsoft Message Queueing, IBM MQ Series и т.д. Однако чаще всего используется протокол HTTP. Microsoft SOAP Toolkit включает в себя только поддержку HTTP.


WSDL




Замечание насчет binding style rpc|document (в выданном мною примере WSDL этот элемент отсутствует)





В распределенных системах SOAP используется для обеспечения взаимодействия разных уровней. На сегодняшний день существует множество технологий и протоколов, позволяющих без труда соединять элементы распределенных систем между собой. Одна из наиболее известных технологий – DCOM, позволяющая эффективно осуществлять RPC-вызовы, передавать и принимать данные, распределять нагрузку между несколькими back-end серверами. Однако у систем, построенных на DCOM, есть очень важный недостаток, затрудняющий взаимодействие уровня представления и уровня бизнес-логики через Internet. Хотя DCOM-приложения могут использовать TCP/IP для передачи вызовов RPC, большинство современных сетевых экранов будут запрещать передачу таких пакетов из соображений безопасности. Конечно, с помощью утилиты DCOMCNFG можно настроить DCOM на использование любого порта в диапазоне от 1024 до 65535. Но при изменении настроек одного из промежуточных файрволлов DCOM может перестать работать. Можно сказать, что DCOM является доминирующей технологией для обмена информацией и передачи вызовов в пределах корпоративной локальной сети, но при выходе за ее пределы DCOM приносит большое количество хлопот, связанных с настройкой портов, файрволлов и т.д.


ПРИМЕЧАНИЕ


Чтобы расширить сферу применения DCOM, Microsoft выпустила COM Internet Services (CIS). CIS использует специальный “туннельный” TCP-протокол, позволяющий DCOM-приложениям осуществлять RPC-вызовы через порт 80. На стороне сервера находится ISAPI-расширение, перехватывающее запросы, идущие на порт 80, и перенаправляющее их дальше для обработки с помощью обычного RPC. Особенностью CIS является то, что только начальное “рукопожатие” клиента с сервером происходит в соответствии с протоколом HTTP, остальной трафик не является HTTP (сделано это, видимо, из соображений эффективности). Поэтому, несмотря на использование 80-го порта, CIS не устраняет проблему сетевых экранов, которые могут запретить передачу “подозрительных” пакетов.


Альтернативой DCOM при построении распределенных систем может служить использование Web-интерфейса на основе ASP. В таких системах от клиента ничего не требуется, кроме наличия браузера, способного соединиться с корпоративным Web-сервером. Для передачи запроса от клиента к серверу можно применить, например, метод POST для HTML-формы, а обработка запроса будет происходить уже на серверной стороне. Несмотря на популярность такого подхода, у него есть недостатки – состав передаваемой информации, а главное, способ ее передачи в методе POST специфичны для конкретного приложения. А если на уровне представления необходим полноценный пользовательский интерфейс Windows-приложения, не миновать проблем.


Как в этом случае может быть построено взаимодействие клиента с сервером? И, наконец, как быть, если необходимо обеспечить поддержку не только HTTP, но, например, SMTP или MSMQ (для асинхронного взаимодействия)? Эти задачи можно решить следующим образом:


* Преобразовать вызов в текстовое представление с сохранением информации обо всех параметрах и их значениях.

* Передать текст на сервер по HTTP, SMTP и т.д.

* Интерпретировать текстовое сообщение на сервере и осуществить вызов некоторого метода.

* Преобразовать out-параметры или информацию об ошибке, возвращаемые методом, в текстовое представление.

* Передать текст клиенту по HTTP, SMTP и т.д.

* Интерпретировать результат.


Реализуя описанный сценарий, можно спроектировать свой собственный формат передачи параметров и информации о вызове, или использовать SOAP, тем самым снижая затраты на разработку, документирование и сопровождение системы.


Необходимо упомянуть о еще одном достоинстве протокола SOAP – он нейтрален к платформе, т.е. не накладывает ограничений на платформы, которые используются клиентом и сервером. Запрос клиента, работающего под управлением Windows 98, может быть обработан сервером под управлением Unix.


Наконец, Веб-сервисы !!!




Web Services Protocol Stack

The following sections aim at more detailed descriptions of the protocols shown in and explained in its role above.




XML messaging using SOAP

      1. In Figure 4, at (1) a service requestor’s application creates a SOAP message. This SOAP message is the request that invokes the Web service operation provided by the service provider. The XML document in the body of the message can be a SOAP RPC request or a document-centric message as indicated in the service description. The service requestor presents this message together with the network address of the service provider to the SOAP infrastructure (for example, a SOAP client runtime). The SOAP client runtime interacts with an underlying network protocol (for example HTTP) to send the SOAP message out over the network.

      2. At (2) the network infrastructure delivers the message to the service provider’s SOAP runtime (for example a SOAP server). The SOAP server routes the request message to the service provider's Web service. The SOAP runtime is responsible for converting the XML message into programming language-specific objects if required by the application. This conversion is governed by the encoding schemes found within the message.

      3. The Web service is responsible for processing the request message and formulating a response. The response is also a SOAP message. At (3) the response SOAP message is presented to the SOAP runtime with the service requestor as the destination. In the case of synchronous request/response over HTTP, the underlying request/response nature of the networking protocol is used to implement the request/response nature of the messaging. The SOAP runtime sends the SOAP message response to the service requestor over the network.

      4. At (4) the response message is received by the networking infrastructure on the service requestor’s node. The message is routed through the SOAP infrastructure; potentially converting the XML message into objects in a target programming language. The response message is then presented to the application.

Network Layer

The base layer of the Web Services stack is the network. This layer can be implemented using any number of existing network protocols such as SMTP, FTP, HTTP, RMI, IIOP or others. Despite a wide choice of network protocols that can be used, most Web Service applications rely on HTTP. HTTP is widely deployed and is very likely the ideal choice for Internet based applications. For applications with limited audience for example within an Intranet or specific requirements including security, performance and reliability other protocols could be a better choice.

One of the major advantages of the Web Service architecture is that the service developers do not need to care about this underlying network protocol, as it is completely transparent to the upper layers.

HTTP (Hypertext Transfer Protocol)

Запрос GET может содержать данные, передаваемые клиентом серверу. они передаются непосредственно через URL адрес по CGI протоколу. Так например для входа в чат браузер может передавать серверу следующий запрос:


GET http://chat.ru/?login=Basil&pass=Pupkin HTTP/1.0

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, */*

Accept-Language: ru

Cookie: yandexuid=2464977781018373381

User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)

Host: yandex.ru

Referer: narod.ru

Proxy-Connection: Keep-Alive


Кака мы видим строка запроса содержит логин и пароль пользователя, переданые через строку URL. Такой тип передачи данных серверу удобен, однако имеет ограничения на объем. Слишком большие массивы данных передавать через URL нельзя. Для таких целей существует другой тип зпросов: запрос POST. Запрос POST очень похож на GET, с той лишь разницей что данные в запросе POST передаются отдельно от самого собственно заголовка запроса. Так приведенный выше пример в варианте POST имеет вид:


POST http://chat.ru/ HTTP/1.0

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, */*

Accept-Language: ru

Cookie: yandexuid=2464977781018373381

User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)

Host: yandex.ru

Referer: narod.ru

Proxy-Connection: Keep-Alive


login=Basil&pass=Pupkin


Поэтому для SOAP используется POST форма HTTP запросов, позволяющая не перемешивать URL и содержание сообщения.


The HTTP header consists of plain text. The payload is of the type specified in the Content-Type section of the header. In the example the payload is also of the format plain text. A potential answer must start with a return code indicating the type of result and optionally additional information.



HTTP Success Response

As shown in a potential Response of the server in case of success could be organized. A response contains also a header and optionally a content body. A Response starts with a status code indicating the type of response and a descriptive text for this kind of answer. Other examples for HTTP responses are shown in and .




HTTP Error Response



HTTP Redirect Response

XML Protocol Layer (SOAP)

This layer is responsible for the transport of method calls, its parameters and also the results of operations. This layer is in most implementations of a Web Service stack realised using the Simple Object Access Protocol (SOAP). The SOAP Protocol is expressed using XML and defines within its specification also how SOAP messages are supposed to be transported using HTTP and SMTP. Other mappings will be defined in the future.

SOAP offers different kind of communication types between service requestor and service provider. Beside a synchronous or asynchronous request/response oriented client server relation publish/subscribe models, one-way messaging (with no response) and notification (push-style response) are possible.



SOAP Communication Types

A SOAP message is built from several logical components. The Object Endpoint ID uniquely identifies the destination of the request. The interface and method identifier describe the method that should be called. The Extension Headers are headers of the SOAP message and the Parameter DATA is the Body of the SOAP message. In the mapping from logical components to a SOAP message transported via HTTP is shown.



Logical Components of a SOAP message

Как это выглядит изнутри (пример echoFloatArray)

Исходный Java код метода:

public float[] echoFloatArray(float[] inputFloatArray) throws java.rmi.RemoteException {

return inputFloatArray;

}

Благодаря использованию вспомогательных средств пакетов разработки WS, формирование SOAP вызовов и декодирование результатов происходит скрытым от программиста образом.

Если запустить какой-нибудь TCP sniffer, то можно увидеть чем на самом деле обмениваются клиенты и WS.

Вызов метода

POST /axis/servlet/AxisServlet HTTP/1.0

Content-Type: text/xml; charset=utf-8

Accept: application/soap+xml, application/dime, multipart/related, text/*

User-Agent: Axis/1.0

Host: vvv

Cache-Control: no-cache

Pragma: no-cache

Connection: Keep-Alive (чтобы не тратить время на установление соединений при следующих вызовах)

SOAPAction: http://soapinterop.org/ (опциональное значение, может быть «»)


Content-Length: 656












3.7

7.0









Возврат результата

^ HTTP/1.0 200 OK

Content-Type: text/xml; charset=utf-8

Set-Cookie: 5

Set-Cookie2: 5












3.7

7.0










Можно сказать, что WS обобщают обычные средства HTTP (метод POST) на случай сколь угодно сложных SOAP запросов.


Средства разработки и доки:

XMLSpy,

NetBeans IDE, Sun ONE

Eclipse (XML Buddy)


The concept of WS container (HTTP server)

Средой обитания WS является WEB-server. Обычно, для НЕ MS реализаций таковым является Apache TomCat, снабженный всевозможными утилитами для манипуляций с WSDL и WSDD файлами.

Для MS WS – IIS (Visual Studio.NET)

Однако существуют и специальные «легкие» реализации AxisServer, gSOAP. Играющие роль аналогичную CORBA Object Adaptor.


CELL

http://en.wikipedia.org/wiki/CELL

Cell is a microprocessor architecture jointly developed by a Sony, Toshiba, and IBM alliance known as STI. The architectural design and first implementation were carried out at the STI Design Center over a four-year period beginning March 2001 on a budget reported by IBM as approaching $400 million.


Cell is a shorthand for Cell Broadband Engine Architecture, commonly abbreviated CBEA in full or Cell BE in part. Cell combines a general-purpose POWER-architecture core of modest performance with streamlined coprocessing elements which greatly accelerate multimedia and vector processing applications, as well as many other forms of dedicated computation.






оставить комментарий
страница5/5
Дата10.10.2011
Размер0,93 Mb.
ТипДокументы, Образовательные материалы
Добавить документ в свой блог или на сайт
1   2   3   4   5
Ваша оценка этого документа будет первой.
Ваша оценка:
Разместите кнопку на своём сайте или блоге:
rudocs.exdat.com


База данных защищена авторским правом ©exdat 2000-2014
При копировании материала укажите ссылку
обратиться к администрации
Документы

Рейтинг@Mail.ru
наверх