Лекция Архитектура распределенных приложений J2EE

Вид материала

Архитектура распределенных приложений на платформе J2EE
Рисунок 1. Типовая архитектура J2EE приложения.
Рисунок 2. Схема работы по протоколу RMI.
Процессы и потоки.
Синхронизация Синхронизация работы потоков, как и само разбиение работ на потоки, выполняется автоматически. Целостность и непро

Подобный материал:

1 2 3

Архитектура распределенных приложений на платформе J2EE

В рамках технологии J2EE большая часть вопросов подобного рода решается за счет предоставления стандартных интерфейсов к механизмам, реализованных как часть функций серверов J2EE, web-серверов и серверов хранения данных, а также, за счет использования библиотек, входящих в состав J2EE,

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

Аспект данных представляется сервером данных (СУБД) и набором компонентов EJB, чья связь с сервером данных обеспечивается EJB-контейнером. Компоненты EJB реализуют значимые для предметной области данного приложения операции над данными — то, что называется бизнес-логикой. При этом EJB-контейнер отвечает за поддержку взаимодействия распределенных объектов, поддержку транзакций, поддержку связи компонентов с СУБД, обеспечение защищенности и безопасности, поддержку параллелизма и управление ресурсами.
Аспект представления реализуется Web-браузером на машине клиента, с помощью которого можно просматривать результаты обращений к системе в виде HTML страниц. Сами эти страницы чаще всего динамически генерируются по запросам клиента с помощью набора серверных страниц Java (Java Server Pages, JSP). Иногда в HTML страницы включают Java-апплеты, работающие на машине клиента и предоставляющие интерфейс, который тяжело или невозможно сделать с помощью HTML. Связь между этими апплетами и серверной частью системы тоже основывается на протоколе HTTP.
Аспект обработки реализуется при помощи набора сервлетов (servlets) или вспомогательных компонентов, из которых строятся сервлеты. Они предстают клиенту в виде элементов управления на HTML страницах.
И сервлеты, и JSP работают в рамках Web-контейнера, выполняющего для них те же функции, что EJB-контейнер для компонентов EJB и связывающего их с Web-сервером, который непосредственно получает и отсылает HTTP-сообщения.

Общая архитектура J2EE приложений выглядит следующим образом.

Рисунок 1. Типовая архитектура J2EE приложения.

Цветом выделены компоненты, которые надо разрабатывать, в отличии от предоставляемой платформой J2EE и поставщиками ПО поддержки инфраструктуры. Web-сервер, Web-контейнер, EJB-контейнер и хранилище данных могут быть размещены как на одной, так и на нескольких машинах, что позволяет строить более масштабируемые по производительности и, иногда, более надежные приложения.

В результате J2EE предоставляет возможность создавать приложения, пользуясь уже имеющимися реализациями механизмов решения почти всех вопросов, которые возникают при создании распределенных систем.

Связь

Основную часть функций по обеспечению связи между отдельными компонентами J2EE приложения эта платформа берет на себя. Обращение к EJB компонентам из компонентов внутри Web-контейнера оформляется прозрачно, как обращение к локальным объектам.
Передача данных между отдельными компонентами J2EE приложения организуется на основе одной из реализаций протокола дистанционного или удаленного вызова методов (Remote Method Invocation, RMI).

Этот протокол реализуется в виде набора классов, наследующих интерфейсы пакета java.rmi.

В целом работа этого протокола организована следующим образом.

Компоненты в приниципе равноправны, но в рамках одного обращения компонент, осуществляющий его, называется клиентом, а обрабатывающий — сервером. В рамках клиентского процесса, в котором работает клиент, находится заглушка (stub) серверного компонента, реализующего тот самый интерфейс, который серверный компонент предоставляет для дистанционных вызовов. В рамках того же процесса, что и серверный компонент, работает каркас (skeleton) серверного объекта.

Рисунок 2. Схема работы по протоколу RMI.

Вызов метода клиентским компонентом обрабатывается серверной заглушкой.

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

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

Серверный компонент выполняет вызванный метод и возвращает результат каркасу.

Каркас сериализует результат вызова и передает его в виде ответного сообщения заглушке.

Заглушка извлекает результат из сообщения и возвращает его вызвавшему метод клиентскому компоненту.

В качестве типов параметров и результатов методов, вызываемых удаленно, должны фигурировать только примитивные типы (boolean, char, byte, short, int, long, float, double), сериализуемые типы, реализующие интерфейс java.io.Serializable или типы самих объектов, способных быть вызванными удаленно, — все они реализуют интерфейс java.rmi.Remote.

Процессы и потоки.

Разбиение приложения на набор взаимодействующих процессов и потоков осуществляется автоматически Web- и EJB-контейнерами. Компоненты J2EE приложения, работающие в их рамках не должны реализовывать собственные отдельные потоки.

Именование.

Вопросы поддержки именования (т.е. поиска ресурсов по именам и идентификаторам) и службы каталогов (т.е. поддержки поиска ресурсов по набору значений их атрибутов) в рамках J2EE и J2SE решаются при помощи интерфейса JNDI (Java Naming and Directory Interface, Java интерфейс служб имен и каталогов).

Базовые интерфейсы и классы JNDI находятся в пакете javax.namimg и его подпакетах javax.naming.directory, javax.naming.event, javax.naming.ldap.

Основные сущности служб именования или каталогов, харанящие привязку ресурсов к именам и наборам атрибутов, называются контекстами.

Базовый интерфейс всех контекстов определяется интерфейсом javax.naming.Context. Основные классы, его реализующие — javax.naming.InitialContext, javax.naming.directory.InitialDirContext, javax.naming.ldap.InitialLdapContext. Основные методы этого интерфейса перечислены ниже.

void bind(String, Object) — связать данное имя с данным объектом
Object lookup (String) — найти объект с данным именем
void rebind(String, Object) — связать данное имя с данным объектом, даже если оно уже имеется в этом контексте
void rename(String, String) — связать с объектом, связанным с первым именем, второе
void unbind(String) — удалить связку объека с данным именем
NamingEnumeration listBinding(String) — возвращает список связок имя-объект для подконтекста с указанным именем
Context createSubcontext(String) — создать подконтекст с данным именем
void destroySubcontext(String) — удалить подконтекст с данным именем

В дополнение к этим методам классы InitialDirContext и InitialLdapContext реализуют интерфейс контекста службы каталогов DirContext, имеющий методы void bind(String, Object, Attributes) для привязки набора атрибутов к объекту, Attributes getAttributes(String) для получения набора атрибутов объекта по указанному имени и NamingEnumeration search(String, Attributes) для поиска объектов по указанному набору атрибутов в контексте с указанным именем.

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

Стандартный набор JNDI свойств, которые могут быть установлены для Java приложения или апплета, включает

java.naming.factory.initial (соответствует константе Context.INITIAL_CONTEXT_FACTORY) — имя класса фабрики для создания начальных контекстов, обязательно должно быть установлено
java.naming.provider.url (соответствует константе Context.PROVIDER_URL) — URL сервера каталогов или имен
java.naming.dns.url (соответствует константе Context.DNS_URL) — URL для определения DNS узла, используемого для получения адреса JNDI URL
java.naming.applet (соответствует константе Context.APPLET) — объект-апплет, используемый для получения JNDI свойств
java.naming.language (соответствует константе Context.LANGUAGE) — список, через запятую, предпочтительных языков для использования в данной службе (пример: en-US, fr, ja-JP-kanji). Языки описываются в соответствии с RFC 1766.

Пример использования JNDI для распечатки содержимого директории c:/tmp. Для работы с файловой системой через JNDI используется реализация службы именования на основе файловой системы от Sun (ссылка скрыта).

package ru.msu.cmc.prtech.examples;

import java.util.Properties;

import javax.naming.Binding;

import javax.naming.Context;

import javax.naming.InitialContext;

import javax.naming.NamingEnumeration;

import javax.naming.NamingException;

/**

* @author Victor Kuliamin

*/

public class JNDIExample

{

public static void main (String[] args)

{

Properties env = new Properties();

env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.fscontext.RefFSContextFactory");

env.put(Context.PROVIDER_URL, "file://c:/tmp");

try

{

Context cntx = new InitialContext(env);

NamingEnumeration list = cntx.listBindings("");

while(list.hasMore())

{

Binding bnd = (Binding)list.next();

System.out.println(bnd.getName());

}

}

catch (NamingException e)

{

e.printStackTrace();

}

}

}

Синхронизация

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

Целостность и непротиворечивость

Целостность и непротиворечивость данных при работе J2EE приложений поддерживается с помощью механизма транзакций. Построение транзакций определяется в декларативном стиле в дескрипторах развертывания EJB компонентов, определяющих действия с данными приложения. Методы работы с EJB компонентами могут иметь различные политики работы с транзакционными контекстами: не поддерживать работу в рамках транзакции, включаться в имеющуюся транзакцию, стартовать новую, вложенную транзакцию, и т.п (см. далее).

Отказоустойчивость

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

Защищенность

Защищенность J2EE приложения поддерживается механизмом определения ролей, доступности различных методов для ролей и политик переноса или создания ролей при совместной работе нескольких методов. Роли, политики их переноса и правила доступа различных ролдей к методам описываются в дескрипторах развертывания EJB компонентов (см. далее).

Blog