Особенности модели распределенных объектов. Модель RPC.

Особенности модели распределенных объектов. Модель RPC.

Идея вызова удаленных процедур (RemoteProcedureCall - RPC) состоит в расширении известного механизма передачи управления и данных внутри программы, выполняющейся на одной машине, на передачу управления и данных через сеть.

Цель RPC - сделать вызов удаленной процедуры внешне аналогичным вызову локальной процедуры, т.е., сделать RPC прозрачным: вызывающей процедуре не требуется знать, что вызываемая процедура находится на другой машине, и наоборот.

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

1.Поскольку вызывающая и вызываемая процедуры выполняются на разных машинах, то они имеют разные адресные пространства, и это создает проблемы при передаче параметров и результатов.

2.Так как RPC не может рассчитывать на разделяемую память, значения параметров должны копироваться с одного компьютера на другой.

3.RPC – вызов использует нижележащую систему связи, однако это не должно быть явно видно ни в определении процедур, ни в самих процедурах. Удаленность вносит проблемы.

4.В отл-е от выполнения вызывающей программы и вызываемой локальной процедуры на одной машине в реализации RPC участвуют как минимум два процесса - по одному на каждой машине.

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

Архитектура механизмов RMI.

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

Реализация RMI, по существу, состоит из трех абстрактных уровней:

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

Уровень удаленных ссылок

Этот уровень понимает, как интерпретировать и управлять ссылками на удаленные объекты служб. Уровни удаленных ссылок определяют и поддерживают семантику вызовов соединения RMI. Этот уровень предоставляет объект RemoteRef, который обеспечивает соединение с объектами, реализующими удаленные службы.

Реализация RMI в JDK 1.1 обеспечивает только один способ соединения клиентов с реализациями удаленных служб: однонаправленное соединение типа точка -точка. Перед тем, как клиент сможет использовать удаленную службу, экземпляр объекта, реализующего ее, должен быть создан на сервере и экспортирован в систему RMI.

Реализация RMI в Java 2 SDK добавляет новую семантику для соединения клиент - сервер. В этой версии RMI поддерживает способные к активизации удаленные объекты. Когда производится вызов метода прокси для такого объекта, RMI определяет, находится ли объект, реализующий удаленную службу, в пассивном состоянии. Если да, то RMI создаст экземпляр объекта и восстановит его состояние из дискового файла. Как только объект активизируется в памяти, он начинает вести себя так же, как и объект, реализующий удаленную службу JDK 1.1.

Транспортный уровень: прииспользовании уровневой архитектуры каждый из уровней может быть изменен или заменен без воздействия на остальную систему. Например, транспортный уровень может быть заменен протоколом UDP/IP без изменения остальных уровней.

Транспортный уровень осуществляет соединение между различными JVM. Все соединения представляют собой основанные на потоках сетевые соединения, использующие TCP/IP. Даже если две JVM работают на одном и том же физическом компьютере, они соединяются через стек сетевых протоколов TCP/IP.Этот соединение основано на адресе IP и номере порта.

На вершине TCP/IP RMI использует протокол уровня соединения, называемый JavaRemoteMethodProtocol (JRMP). JRMP является частным, основанным на потоках, протоколом.

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

Разработка RMI-приложений. Примеры. Соглашения о передаче данных.

Определим удаленный интерфейс:Он расширяет java.rmi.Remote и объявляет набор удаленных методов. Каждый удаленный метод должен выбрасывать java.rmi.RemoteException (или его суперкласс).

Реализуем сервер. Класс сервера в данном контексте – это класс, который имеет метод main(), который создает экземпляр реализации удаленного объекта, экспортирует удаленный объект, а затем привязывает этот экземпляр имени в JavaRMI регистраторе. Далее создаем и экспортируем удаленный объект. Регистрируем удаленный объект в RMI-регистраторе под именем.

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

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

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

Статический метод LocateRegistry.getRegistry(), который не принимает никаких аргументов, возвращает стаб, который реализует удаленный интерфейс java.rmi.registry.Registry и отправляет вызовы нарегистратор на хост сервера по порту по умолчанию 1099. При этом регистратор должен быть запущен. Метод bind() затем вызывает стаб регистратора для связи стаба удаленного объекта с именем «Hello» в регистраторе.

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

получаем стаб удаленного объекта от регистратора сервера.

Далее необходимо скомпилировать классы, и, наконец, запустить RMI регистратор, сервер и клиент.

Архитектура управления объектами.(OMA)

OMA состоит из четырех частей:

• фундаментальный компонент, называемый Брокер Объектных Запросов (ObjectRequestBroker),

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

• общие сервисы, используемые многими различными приложениями, и

• распределенные приложения как таковые.

ORB - аббревиатура от “Брокер Объектных Запросов”, предусматривает фундаментальные и основные действия с распределенными объектами и с управлением ими. Стандартом, который был принят для реализации этих целей, явился CORBA (Единая архитектура программы-брокера объектных запросов).

Сервисы, используемые для разработки распределенных объектов, называются CORBA-сервисами. Поначалу они назывались общие объектные сервисы, поскольку не было уверенности, что всем распределенным объектам эти сервисы будут действительно необходимы.

Эти сервисы предназначались для использования, в первую очередь, объектами распределенных приложений и назывались Общими Объектными Средствами Обслуживания. Это связано с тем, что средства обслуживания расценивались как каркас, составленный из многих сервисов, которые, в свою очередь, представлялись еще более “гранулированными” сервисами. Сейчас они поменяли свое название на средства обслуживания CORBA.

Приложения, составленные из таких “строительных блоков” являются объектными приложениями.

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

 

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

 

 

23 Основные сервисы Corba, модель организация приложений CORBA, примеры.

CORBA-cервисы, представляют собой набор служб системного уровня, упакованных вместе с интерфейсами IDL. Их можно рассматривать как расширение функциональности ORB. Они используются для создания компонент, их именования и внедрения в среду.

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

Сервис событий (Eventservice) обеспечивает поддержку асинхронного взаимодействия приложений.

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

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

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

Сервис управления разделяемыми ресурсами (Concurrencycontrol) service позволяет клиентам координировать свои действия при исп-нии разделяемых ресурсов. Управление разделяемыми ресурсами осущ-ся с пом. блокировок. Каждая блокировка ассоциируется с единственным ресурсом и единственным клиентом. Сервис определяет также несколько режимов блокировок, которые соответствуют различным способам доступа.

Сервис внешнего представления (Externalizationservice) формирует копию CORBA-объекта в виде некоторого внешнего представления — файла, элемента базы данных и т.д.

В адресном пространстве клиента функционирует специальный объект, называемый заглушкой (stub). Поучив запрос от клиента, он упаковывает параметры запроса в специальный формат и передает его серверу, а точнее скелету.

Скелет (skeleton) — объект, работающий в адресном пространстве сервера. Получив запрос от клиента, он распаковывает его и передает серверу. Также скелет преобразует ответы сервера и передает их клиенту (заглушке).

Создание CORBA приложения на Java начинается с написания интерфейса для удаленного объекта, используя язык описания интерфейсов (InterfaceDefinitionLanguage, IDL).

Создадимфайл test.idl

module testApp {

interface test

{

long count(in string msg);

};

};

Серверная часть приложения.

Первое что мы делаем, создаем ORB. Затем создаем экземпляр класса удаленного объекта (testServant) и регистрируем его в ORB. Дальше вызываем специальную службу имен (NameService) и регистрируем в ней имя удаленного объекта, чтобы клиент смог его найти

После того как сервер обработает запрос от клиента и выполнит метод count он снова перейдет в состояние ожидания.

ORB orb = ORB.init(args, null);

testServanttestRef = new testServant();

orb.connect(testRef);

org.omg.CORBA.ObjectobjRef =

orb.resolve_initial_references("NameService");

NamingContextncRef =

NamingContextHelper.narrow(objRef);

Код клиента. Основные шаги написания клиентского приложения

· Создание и инициализация ORB

· Получение контекста службы имен (NamingContext)

· Нахождение удаленного объекта

· Вызов метода count.

Третий пункт. Создается объект NameComponent. Вызывается метод resolve(NameComponent[] path), который отыскивает по имени удаленный объект (стандартный CORBA-объект). При помощи метода narrow(org.omg.CORBA.Objectobj) класса testHelper (сгенерированного idltojava компилятором) получаем объектную ссылку на интерфейс test.

NameComponentnc = new NameComponent("test", "");

NameComponent path[] = {nc};

org.omg.CORBA.Objectobj= ncRef.resolve(path);

test testRef = testHelper.narrow(obj);

Теперьможновызыватьметод count

String msg = "try to count";

int count = testRef.count(msg);

 

24. ORB, понятие, назначение, основные функции

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

Вызов ORB

1. Клиент вызывает метод посредством “заглушки”.

2. ORB передает вызов ВОА, который активизирует реализацию.

3. Реализация запрашивает у ВОА, является ли последний по-прежнему активным и доступным.

4. ВОА передает запрос через “заготовку” реализации метода.

5.Реализация через ORB возвр-ет результат (или исключение).

Клиент может запрашивать выполнение операций с помощью ORB несколькими способами. Вызов операций разделяемого объекта-сервера может быть статическим, через IDL-суррогат, или динамическим (DynamicInvocationInterface). В случае статического вызова описания интерфейсов на IDL отображаются в программный код на языках С, С++, Smalltalk и др. При использовании динамического интерфейса запросы формируются специальным образом, без отображения интерфейса объекта в исходный код разрабатываемого приложения.

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

Объектный брокер запросов (ORB)

Спецификация CORBA разработана для обеспечения возможности интеграции разных объектных систем

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

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

Клиент может запрашивать выполнение операций с помощью ORB несколькими способами. Вызов операций разделяемого объекта-сервера может быть статическим, через IDL-суррогат, или динамическим (DynamicInvocationInterface). В случае статического вызова описания интерфейсов на IDL отображаются в программный код на языках С, С++, Smalltalk и др. При использовании динамического интерфейса запросы формируются специальным образом, без отображения интерфейса объекта в исходный код разрабатываемого приложения.

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

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

 

Для связи между брокерами был разработан протокол GeneralInter ORB Protocol (GIOP), стандартизующий низкоуровневое представление данных и множество форматов сообщений.

InternetInter ORB Protocol (IIOP) определяет обмен сообщениями в формате GIOP через TCP/IP-соединения. IIOP становится признанным стандартом для вызова удаленных объектов в Интернет. Такая комбинация GIOP и IIOP необходима для поддержки внешнего взаимодействия. Все поставщики ORB обеспечивают внешнюю совместимость этого протокола.

 

Связь CORBA и RMI

Слияние RMI и IIOP является ключевым в поддержке CORBA из среды Java. Используя стандарт отображения Java в IDL, клиенты и серверы Java могут взаимодействовать с CORBA-совместимыми серверами вне зависимости от языка программирования такого сервера. CORBA в соединении с Java позволит достичь еще большей гибкости в создании распределенных систем.

Одна из важнейших составляющих спецификации CORBA - это протокол InternetInter-ORB Protocol (IIOP), являющийся частью уровня ORB. Все основные поставщики CORBA заявили о своей поддержке IIOP, благодаря которому объекты или клиенты одного поставщика ORB могут вызывать методы других поставщиков ORB. Это гарантирует совместимость и взаимодействие различных реализаций CORBA.

CORBA поддерживает многие языки, в том числе C, C++, SmallTalk и объектно-ориентированный COBOL.

JavaSoft планирует выпустить вариант RMI, выполненный на основе упоминавшегося выше протокола IIOP. Это позволит RMI-клиенту взаимодействовать с Corba-объектами.

 

Общие принципы развертывания сеансовых компонентов EJB. Пример текста дескриптора поставки.

 

Delpoyer отвечает за присутствие всей необходимой информации в Дескрипторе Поставки и за ее корректность. Его не интересует код компонентов - его задача обеспечить их функционирование в данной операционной среде, определить права доступа к Компонентам и правила выполнения транзакций (кроме случая, когда компоненты сами управляют транзакциями), обеспечить взаимодействие с конкретными СУБД, разместить компоненты в нужные Контейнера. Вообще, под процессом развертывания приложения понимается совокупность всех действий по настройке системы в конкретной операционной среде, после которых клиент может приступить к работе с ней.

Дескриптор развертывания (Deploymentdescriptor)

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

Спецификация EJB 1.1 требует, чтобы Дескриптор Развертывания имел XML-формат. Поскольку XML является метаязыком, то для описания каждого конкретного класса документов нужно создать свой язык - в частности, определить набор используемых тегов и правила взаимоотношений между ними. Такой язык называется DocumentTypeDefinition (DTD).

Дескриптор Развертывания соответствует DTD, разработанному фирмой SunMicrosystems. Он содержит набор свойств, который описывает, как Контейнер будет выполнять процесс развертывания Компонента или приложения, и включает набор тегов и атрибутов, чьи значения определяют состояние свойств Компонента. В качестве примера приведем несколько тегов:

<session> - говорит о том, что Компонент является session-Компонентом (тег <entity> используется для обозначения Entity-Компонентов).

Внутри области тега <session> могут использоваться другие теги:

<ejb-class> - имя класса реализации.

<home> - имя home-интерфейса.

<remote> - имя remote-интерфейса.

<session-type> - показывает, является ли session-Компонент stateful- или stateless-Компонентом.

<transaction-type> - показывает, используется ли для Компонента CMT или BMT.

 

<?xml version="1.0" encoding="Cp1252"?>

<ejb-jar>

<description>Example</description>

<display-name></display-name>

<small-icon></small-icon>

<large-icon></large-icon>

<enterprise-beans>

<session>

<ejb-name>Sample</ejb-name>

<home>SampleHome</home>

<remote> Sample </remote>

<ejb-class>SampleBean</ejb-class>

<session-type>Stateless</session-type>

<transaction-type>Container</transaction-type>

</session>

</enterprise-beans>

<ejb-client-jar></ejb-client-jar>

</ejb-jar>

 

 

Реализация бина.

Рассмотрим Entity-бин BookEJB. Он реализует набор пар get/set, которые получают значения его полей. Также реализованы методы управления персистентностью:

а) ejbCreate(BookPKBookPK,:) Создание экземпляра бина в базе.

б) ejbRemove() Удаление экземпляра бина из базы по первич. ключу.

в) Методы ejbLoad() и ejbStore(). Им соответствуют методы selectRow и updateRow соответственно в классе BookDAO. При указании типа транзакции required над бизнес-методомбина, перед заданием переменной и после её получения контейнер автоматически вызывает эти методы для чтения и сохранения состояния бина из базы.

г) BookPKBookPKejbFindByPrimaryKey(BookPKBookPK) Нахождение экземпляра бина в базе.

д) getDBConnectionПолуч. соединения к СУБД из пула соед-й EJB-конт-ра.

Базовым классом для класса entity-компонента является класс javax.ejb.EntityBean .

Кроме вышеперечисленный, интерфейс EntityBeanсодержит следующие методы:

setEntityContext() – устанавливает контекст компонента. Контейнер использует этот метод для передачи ссылки на интерфейс EntityContextэкземпляру компонента. Этот интерфейс содержит методы, которые позволяют получить доступ к свойствам среды исполнения компонента;

unsetEntityContext() – вызывается контейнером перед тем, как происходит уничтожение текущего экземпляра entity-компонента;

ejbActivate() – уведомляет компонент о том, что он только что был активизирован;

ejbPassivate() – уведомляет компонент о том, что готовится его деактивация, то есть экземпляр будет отсоединен от конкретного entity-объекта (от конкретных данных в базе данных) и возвращен в пул доступных экземпляров;

 

Итого: каждый entity-бин должен обладать следующими характеристиками:

К еntity-бинам может обращаться одновременно большое количество пользователей.

Entity-бины могут участвовать в транзакциях.

Entity-бины представляют данные в структуре домена.

Entity-бины перманентны. Они существуют до тех пор, пока существуют данные в структуре домена.

Entity-бины не подвергаются влиянию системных сбоев. Клиент не теряет данные в результате сбоя или отключения сервера EJB.

Entity-бины имеют постоянные объектные ссылки, которые содержат неизменяемый ключ данногобина.

 

Дескриптор поставки, структура и общие принципы организации кода. Пример описания на XML.

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

Описатель развертываия является XML файлом, который содержит информацию относительно вашего EJB. Исползование XML позволяет установщику легко менять атрибуты вашего EJB. Конфигурационные атрибуты, определеные в описателе развертывания, включают:

· Имена Домашнего и Удаленного интерфейса, которые требуются для вашего EJB

· Имя для публикации в JNDI для вашего Домашнего интерфейса EJB

· Транзакционные атрибуты для каждого метода вашего EJB

· Контрольный Список Доступа для авторизации

Спецификация EJB 1.1 требует, чтобы Дескриптор Развертывания имел XML-формат. Поскольку XML является метаязыком, то для описания каждого конкретного класса документов нужно создать свой язык - в частности, определить набор используемых тегов и правила взаимоотношений между ними. Такой язык называется DocumentTypeDefinition (DTD).

Дескриптор Развертывания соответствует DTD, разработанному фирмой SunMicrosystems. Он содержит набор свойств, который описывает, как Контейнер будет выполнять процесс развертывания Компонента или приложения, и включает набор тегов и атрибутов, чьи значения определяют состояние свойств Компонента. В качестве примера приведем несколько тегов:

<session> - говорит о том, что Компонент является session-Компонентом (тег <entity> используется для обозначения Entity-Компонентов).

Внутри области тега <session> могут использоваться другие теги:

<ejb-class> - имя класса реализации.

<home> - имя home-интерфейса.

<remote> - имя remote-интерфейса.

<session-type> - показывает, является ли session-Компонент stateful- или stateless-Компонентом.

<transaction-type> - показывает, используется ли для Компонента CMT или BMT.

<trans-attribute> - задает значение атрибутов транзакции для каждого метода.

<timeout> - значение тайм-аута для session-Компонента.

 

В качестве примера приведем фрагмент Дескриптора Развертывания для компонента Cart, поставляемого в качестве примера с InpriseApplicationServer 4.0:

<ejb jar>

<enterprise beans>

<session>

<description>

XML deployment descriptor created from file:

D:\Kodiak\kodiak04\ejb_ea_0_4\examples\cart\cart.ser

</description>

<ejb-name>cart</ejb-name>

<home>CartHome</home>

<remote>Cart</remote>

<ejb-class>CartBean</ejb-class>

<session-type>Stateful</session-type>

<transaction-type>Container</transaction-type>

</session>

</enterprise-beans>

<assembly-descriptor>

<container-transaction>

<method>

<ejb-name>cart</ejb-name>

<method-name>*</method-name>

</method>

<trans-attribute>NotSupported</trans-attribute>

</container-transaction>

<container-transaction>

<method>

<ejb-name>cart</ejb-name>

<method-name>purchase</method-name>

</method>

<trans-attribute>Required</trans-attribute>

</container-transaction>

</assembly-descriptor>

</ejb-jar>

 

 

Особенности модели распределенных объектов. Модель RPC.

Идея вызова удаленных процедур (RemoteProcedureCall - RPC) состоит в расширении известного механизма передачи управления и данных внутри программы, выполняющейся на одной машине, на передачу управления и данных через сеть.

Цель RPC - сделать вызов удаленной процедуры внешне аналогичным вызову локальной процедуры, т.е., сделать RPC прозрачным: вызывающей процедуре не требуется знать, что вызываемая процедура находится на другой машине, и наоборот.

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

1.Поскольку вызывающая и вызываемая процедуры выполняются на разных машинах, то они имеют разные адресные пространства, и это создает проблемы при передаче параметров и результатов.

2.Так как RPC не может рассчитывать на разделяемую память, значения параметров должны копироваться с одного компьютера на другой.

3.RPC – вызов использует нижележащую систему связи, однако это не должно быть явно видно ни в определении процедур, ни в самих процедурах. Удаленность вносит проблемы.

4.В отл-е от выполнения вызывающей программы и вызываемой локальной процедуры на одной машине в реализации RPC участвуют как минимум два процесса - по одному на каждой машине.

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

Архитектура механизмов RMI.

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

Реализация RMI, по существу, состоит из трех абстрактных уровней:

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

Уровень удаленных ссылок

Этот уровень понимает, как интерпретировать и управлять ссылками на удаленные объекты служб. Уровни удаленных ссылок определяют и поддерживают семантику вызовов соединения RMI. Этот уровень предоставляет объект RemoteRef, который обеспечивает соединение с объектами, реализующими удаленные службы.

Реализация RMI в JDK 1.1 обеспечивает только один способ соединения клиентов с реализациями удаленных служб: однонаправленное соединение типа точка -точка. Перед тем, как клиент сможет использовать удаленную службу, экземпляр объекта, реализующего ее, должен быть создан на сервере и экспортирован в систему RMI.

Реализация RMI в Java 2 SDK добавляет новую семантику для соединения клиент - сервер. В этой версии RMI поддерживает способные к активизации удаленные объекты. Когда производится вызов метода прокси для такого объекта, RMI определяет, находится ли объект, реализующий удаленную службу, в пассивном состоянии. Если да, то RMI создаст экземпляр объекта и восстановит его состояние из дискового файла. Как только объект активизируется в памяти, он начинает вести себя так же, как и объект, реализующий удаленную службу JDK 1.1.

Транспортный уровень: прииспользовании уровневой архитектуры каждый из уровней может быть изменен или заменен без воздействия на остальную систему. Например, транспортный уровень может быть заменен протоколом UDP/IP без изменения остальных уровней.

Транспортный уровень осуществляет соединение между различными JVM. Все соединения представляют собой основанные на потоках сетевые соединения, использующие TCP/IP. Даже если две JVM работают на одном и том же физическом компьютере, они соединяются через стек сетевых протоколов TCP/IP.Этот соединение основано на адресе IP и номере порта.

На вершине TCP/IP RMI использует протокол уровня соединения, называемый JavaRemoteMethodProtocol (JRMP). JRMP является частным, основанным на потоках, протоколом.

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