26. Понятие прозрачность, серванта, использование посредников proxies в corba. Name сервис

ORB может выступать в качестве посред­ника для межобъектных вызовов внутри единственного процесса, нескольких процессов, выполняющихся на одном компьютере, или множества процессов, выполняющихся в разных сетях под управле­нием разных операционных систем. Такой механизм полностью про­зрачен для ваших объектов. Обратите внимание, что ORB может выступать посредником как между "мелко-зернистыми" объектами — подобными классам C++, так и для более масштабных — "круп­но-зернистых" объектов. В общем случае, CORBA-программисту нет дела до транспортных протоколов, местоположения серверов, ак­тивации объектов, порядка следования байтов через различные плат­формы или целевых операционных систем — CORBA все это сделает прозрачным.

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

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

Служба Указания Имен (Naming Service), предназначена для выполнения преобразования (связывания) строки в объект и объекта в строку.

Когда клиент хочет создать серверный bean, он использует Java Naming and Directory Interface (JNDI) для нахождения home-интерфейса нужного класса bean. JNDI - стандартное расширение ядра Java которое обеспечивает глобальный сервис для любой Java-среды, позволяя Java-программам отыскивать и использовать ресурсы по имени, получать информацию об этих ресурсах, и отслеживать их структуру. Использование JNDI - пример совместимости EJB с другими Java API

Процесс преобразования объекта в строку называется привязыванием объекта (binding an object), а удаления преобразования называется отвязыванием (unbinding).

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

28. Платформа j2ee. Когда следует применять ejb. Типы ejb. Общая структура Beans.

Компоненты EJB выполняются внутри EJB-контейнера, который в свою очередь выполняется внутри EJB-сервера.

EJB-компонента представляет из себя Java-класс, который реализует некоторую бизнес-логику.

EJB-контейнер -- это то место, где ``живет'' EJB-компонент.

EJB-объекты и EJB-компоненты представляют собой разные классы, хотя ``снаружи'' (при взгляде на их интерфейсы), они выглядят одинаково. Это происходит потому, что они реализуют один и тот же интерфейс. Однако при этом они выполняют совершенно разные функции. EJB-компонента выполняется на сервере, внутри EJB-контейнера и реализует бизнес-логику, в то время как EJB-объект выполняется у клиента и удаленно (через remote interface) вызывает методы у EJB-компоненты.

Существует два различных типа ``бинов'': session и entity.

Session bean представляет собой EJB-компоненту, связанную с одним клиентом. ``Бины'' этого типа, как правило, имеют ограниченный срок жизни (хотя это и не обязательно), и редко участвуют в транзакциях. В частности, они обычно не восстанавливаются после сбоя сервера. Несмотря на то, что в процессе своей работы, session bean может сохранять некоторую информацию в базе данных, его предназачение заключается все-таки не в отображении состояния или в работе с ``вечными объектами'', а просто в выполнении некоторых функций на стороне сервера от имени одного клиента.

Entity bean, наоборот, представляет собой компоненту, работающую с постоянной (persistent) информацией, хранящейся, например, в базе данных. Entity beans ассоциируются с элементами баз данных и могут быть доступны одновременно нескольким пользователям. Так как информация в базе данных является постоянной, то и entity beans живут постоянно. Клиент создает на EJB-сервере объекты и работает с ними так же, как если бы это были локальные объекты. Это до предела упрощает разработку. Разработчик может легко создавать, использовать и уничтожать объекты, а эти объекты, в свою очередь, выполняются на сервере. Итак, session beans в большинстве своем работают с информацией, относящейся к ``диалогу'' между клиентом и сервером, в то время как entity beans представляют собой экземпляры данных и работают с ``постоянными'' данными из баз данных.

Каждый экземпляр ``бина'' имеет свой уникальный идентификатор. Для entity объектов уникальный идентификатор, как правило, совпадает с (или каким-либо образом получается из) уникального идентификатора данных (обычно, как первичный ключ сущности БД), которые он представляет. То есть в данном случае существует нечто вроде первичного ключа для всех entity beans. Идентификатор же session beans может быть практически любым -- например он может состоять из имени сервера и порта удаленного соединения, а может создаваться случайным образом.