Поиск

Полнотекстовый поиск:
Где искать:
везде
только в названии
только в тексте
Выводить:
описание
слова в тексте
только заголовок

Рекомендуем ознакомиться

'Программа'
1. Важнейшие изменения в налоговом законодательстве и их влияние на налогообложение НДС и налогом на прибыль ВЭД. Как правильно рассчитать налогооблож...полностью>>
'Решение'
ДОПОЛНИТЕЛЬНОГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ «ПРЕДАТТЕСТАЦИОННАЯ ПОДГОТОВКА СПЕЦИАЛИСТОВ ЭКСПЕРТНЫХ ОРГАНИЗАЦИЙ (ЭКСПЕРТОВ) ПО НЕЗАВИСИМОЙ ОЦЕНКЕ РИ...полностью>>
'Методические рекомендации'
Современные подходы в инженерном образовании базируются на идее интегрированного обучения научным дисциплинам и инженерным навыкам, что в совокупност...полностью>>
'Закон'
Актуальність теми дослідження. На сучасному етапі розвитку система професійно-технічної освіти (ПТО) займається пошуками шляхів розв’язання основної ...полностью>>

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

Главная > Лекция
Сохрани ссылку в одной из сетей:

Технологии программирования. Компонентный подход

В. В. Кулямин

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

Общие принципы построения распределенных систем

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

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

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

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

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

    • Децентрализация служб, состоящая в использовании нескольких машин для обработки поступающих запросов.

    • Децентрализация данных, состоящая в использовании нескольких хранилищ данных или нескольких копий одного хранилища.

    • Децентрализация алгоритмов, состоящая в использовании для обработки и перенаправления запросов алгоритмов, не требующих полной информации о состоянии системы, не разрушающихся при сбое одного из ресурсов системы и не предполагающих единого хода времени на всех машинах, входящих в систему.

    • Использование, где это возможно, асинхронной связи в виде передачи сообщений без приостановки работы до прихода ответа.

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

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

    • Сохранность и целостность данных.
      При обеспечении групповой работы многих пользователей с одними и теми же данными нужно обеспечивать их сохранность, т.е. предотвращать исчезновение данных, введенных одним из пользователей, и в тоже время целостность, т.е. непротиворечивость, выполнение всех присущих данным ограничений.
      Это непростая задача, не имеющая полного решения, удовлетворяющего все стороны во всех ситуациях — при одновременном изменении одного и того же элемента данных разными пользователями итоговый результат должен быть непротиворечив, и поэтому часто может совпадать только с вводом одного из них. Как будет обработана такая ситуация и возможно ли ее возникновение вообще, зависит от дополнительных требований к системе, от принятых протоколов работы, от того, какие риски — потерять данные одного из пользователей или значительно усложнить методы работы пользователей с системой — будут сочтены более важными.

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

    • Отказоустойчивость и способность к восстановлению после ошибок.
      Одним из достоинств распределенных систем является возможность построения более надежно работающей системы из не вполне надежных компонентов. Однако для того, чтобы это достоинство стало реальным, необходимо тщательное проектирование систем для избежания зависимости работоспособности системы от ее отдельных компонентов — иначе достоинство превращается в недостаток, поскольку в распределенной системе элементов больше и выше вероятность того, что хотя бы один элемент выйдет из строя и хотя бы один ресурс окажется недоступным.
      Еще важнее для распределенных систем уметь восстанавливаться после сбоев. Уровни этого восстановления могут быть различными — так, обычно, данные одного сеанса работы считается возможным не восстанавливать, поскольку такие данные часто мало значимы или легко восстанавливаются (если это не так — стоит серьезно рассмотреть необходимость восстановления сеансов), но так называемые постоянно хранимые (persistent) данные обычно требуется восстанавливать до последнего непротиворечивого их состояния.

Ниже перечислены основные аспекты, которые рассматривают при разработке и анализе распределенных систем.

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

  • Организация работ в рамках процессов и потоков.
    В рамках данного аспекта рассматривается разделение работ в вистеме на отдельные процессы, определение ролей процессов (пример — клиентские и серверные), вопросы организации исполняемых агентов, способных мигрировать между отдельными машинами.

  • Именование и поддержка поиска отдельных ресурсов внутри системы.
    К этому аспекту относятся вопросы, связанные с присвоением имен и идентификаторов различных ресурсов, с поиском ресурсов в системе по именам и атрибутам, с размещением и поиском мобильных ресурсов, изменяющих в ходе работы свое физическое положение.
    Сюда же относят и организацию и поддержку сложных ссылочных структур вообще — например, вопросы удаления ставших никому не доступными ресурсов.

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

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

  • Организация отказоустойчивой работы.
    К этому аспекту относятся вопросы обеспечения отказоустойчивости процессов, обеспечения надежной связи, протоколы подтверждения, используемые для реализации надежной двусторонней связи или надежных групповых рассылок, протоколы записей промежуточных состояний и восстановления после сбоя.

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

Архитектура распределенных приложений на платформе 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. Основные классы, его реализующие — itialContext, itialDirContext, itialLdapContext. Основные методы этого интерфейса перечислены ниже.

  • void bind(String, Object) — связать данное имя с данным объектом

  • Object lookup (String) — найти объект с данным именем

  • void rebind(String, Object) — связать данное имя с данным объектом, даже если оно уже имеется в этом контексте

  • void rename(String, String) — связать с объектом, связанным с первым именем, второе

  • void unbind(String) — удалить связку объека с данным именем

  • NamingEnumeration<Binding> listBinding(String) — возвращает список связок имя-объект для подконтекста с указанным именем

  • Context createSubcontext(String) — создать подконтекст с данным именем

  • void destroySubcontext(String) — удалить подконтекст с данным именем

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

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

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

    • itial (соответствует константе ITIAL_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 (http://java.sun.com/products/jndi/serviceproviders.html).

package ru.msu.cmc.prtech.examples;

import java.util.Properties;

import javax.naming.Binding;

import javax.naming.Context;

import itialContext;

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(ITIAL_CONTEXT_FACTORY, "n.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 компонентов (см. далее).



Скачать документ

Похожие документы:

  1. Лекция Язык программирования Java и технологии Java

    Лекция
    Одним из наиболее распространенных подходов к созданию систем, решающих бизнес-задачи общего характера (хранение и обработка данных о клиентах, заказах, поставщиках, имеющихся на складе товарах, поставках и пр), является компонентная разработка.
  2. Мирончик Игорь Янович ClipperIgor@gmail com (496)573-34-22 курс лекций (7)

    Курс лекций
    Аудитория: Администраторы сервера приложений (iAS 10g), разработчики корпоративного портала, администраторы Web приложений, курс также может быть полезен для разработчиков SQL и Java, руководителей IT подразделений, ориентируемых
  3. Рис Физический и логический обмен данными по сети 21 Рис Ахитектура процессов в распределенных системах

    Документ
    Этот курс имеет, в первую очередь, обзорный характер. Его основное назначение - сориентировать слушателей в становящейся все более актуальной (в последнее десятилетие) тематике разработки и практического использования различных технологий
  4. Лекция 2 Технические средства поддержки систем обработки документов. Обработка распределенной информации

    Лекция
    Содержание темы: Документ как универсальный предмет обработки. Безбумажная технология подготовки документов. Форматы представления документов. Задачи информационных технологий: создание, редактирование (обновление) и выпуск документов;
  5. Каталог элективных дисциплин по специальности (1)

    Документ
    Арупов А.А., Тусупова Л.А., Гаитов А.А., Маргацкая Г.С., Тусупова С.А., Успанова М.У., Доскеева Г.Ж., Иванюк Т.Н., Бабланов Т.К., Селезнева И.В., Торпакова И.

Другие похожие документы..