Базовые компоненты JE
2.2.1.1. Документы клиента
Один из основных элементов Web-системы – это документы, которыми обмениваются клиент и сервер. На начальном уровне это означает Web-страницы (HTML). Тем не менее появление беспроводных устройств, которые поддерживают другие языки разметки, означает, что формат документа ни в коем случае не ограничивается HTML. Использование таблицы стилей для обработки клиентом или оконечным устройством означает, что документом клиента для сервера Web-приложений может быть и XML-документ.
2.2.1.2. JavaBeans
JavaBeans – это идеальный инструмент для создания многократно используемых компонентов Web-яруса, которые могут быть задействованы в связке с JSP. Они могут быть использованы для извлечения данных из JSPs или как средство связи между сервлетом и постпроцессором JSP. JavaBeans позволяет специфицировать линию поведения в файле характеристик вне Bean-логики. Это дает возможность разработчикам, использующим инструментарий разработки приложений (application development – AD), менять линию поведения Bean-компонента как части общего приложения.
2.2.1.3. Апплеты
Эти загружаемые Java-приложения подвергаются обработке в среде браузера виртуальной машины Java (Java Virtual Machine – JVM). Апплеты – это мини-приложения, которые загружаются в браузер и исполняются. Они позволяют создавать машинонезависимые функциональные возможности клиентского приложения, которые увеличивают возможности пользователя. Интерфейс апплета ограничен, предотвращая, таким образом, нежелательное разрушение системы, вызванное загрузкой апплета. Апплеты не имеют доступа к системным ресурсам клиента, что предотвращает вирусоподобное повреждение компьютеров.
2.2.1.4. Сервлеты
Компонент сервлет – это Java-эквивалент унаследованного интерфейса CGI. Идентифицированный в URL, конкретный сервлет принимает входящий Web-запрос. Сервлет обрабатывает входящий запрос, возможно взаимодействуя с J2EE EJB-компонентами или СУРБД, через JDBC, затем возвращает результаты в формате HTML запросившему клиенту. Сервлет имеет доступ к HTTP-запросу и сессии пользователя, через объекты Java, подготовленные вызовом. Сервлеты могут запускаться усовершенствованными способами. Например, сервлет перенаправления, или сервлет связывания, позволяет связывать многочисленные сервлеты для обработки единичного запроса пользователя. Несмотря на то, что сервлеты могут создавать HTML напрямую, практика диктует возвращение к JavaBean, который может быть использован JSP для подготовки документа, сцепляясь, таким образом, с шаблонами контроллера вида модели.
Сервлеты создаются, по мере надобности, контейнером сервлетов и остаются обслуживать многочисленные запросы от любого клиента. Когда сервлет запускается первый раз, срабатывает метод инициализации сервлетов, чтобы выполнить все инициализации, требующиеся при запуске. Для первой и всех последующих активизаций сервлетов запускается метод doGet (или метод doPost).
2.2.1.5. Серверные страницы Java (JavaSewer Pages)
Серверные страницы Java (JSP) образуют мост между управлением содержимым HTML и вызовом компонента Java. Разработчики JSP могут вставлять коды HTML и Java в JSP, чтобы добавить динамические функциональные возможности
2.2.1.6. Enterprise JavaBeans
Про Enterprise JavaBeans (EJB) часто думают, что это JavaBeans на стероидах. Несмотря на то, что эта концепция передает мощные функциональные возможности структуры EJB, EJB – это полностью отличающиеся от JavaBeans «животные». EJB обеспечивают структуру для построения усовершенствованных прикладных программ для деловой сферы со сложными компонентами (см. рис. 2.2). Инфраструктура EJB обеспечивает среду, в которой могут быть развернуты компоненты, могут быть использованы сервисы: распределенные транзакции, безопасность и управление жизненным циклом. EJB – это ответ Java на традиционные бизнес-подсистемы, такие, как IBM CICS и IBM IMS.
EJBs имеют три разновидности: сессионные Bean-компоненты (session beans), которые подвергают обработке бизнес-логику и могут быть использованы для управления технологическим процессом обработки; стабильные Bean-компоненты (entity beans), которые инкапсулируют данные, используемые бизнес-логикой; управляемые сообщением Bean-компоненты (message-driven beans), которые подвергают обработке управляемую событиями программную модель. Рассмотрим простой пример – банковское приложение, которое переводит средства с одного счета на другой. Стабильные Bean-компоненты могут использоваться для управления хранилищем данных, содержащим информацию о счете, тогда как сессионные Bean-компоненты позволяют бизнес-логике выполнить транзакцию дебетования одного счета и кредитования другого.
Сессионные Bean- компоненты могут быть либо имеющими состояние (stateful), либо не имеющими состояния (stateless). Имеющие состояние сессионные Bean-компоненты не помнят ничего из предыдущих вызовов (например, URL-запросов). Они оперируют информацией о среде клиента, возвращенной через cookies в браузере, в виде порожденного сервлетом сессионного объекта. Имеющие состояние сессионные Bean-компоненты могут запоминать среду клиента в течение сессии пользователя, но это имеет свою цену. Имеющий состояние сессионный Bean-компонент назначен для одного пользователя в течение сессии пользователя.
Стабильные Bean-компоненты обеспечивают инкапсуляцию данных. Подобно сессионным Bean-компонентам, стабильные Bean-компоненты также имеют две разновидности: с живучестью, управляемой контейнером (container-managed persistence – CMP), и с живучестью, управляемой Bean-компонентом (bean-managed persistence – BMP). В большинстве случаев СМР используется, чтобы инструктировать сервер Web-приложений о порядке управления, хранения и извлечения данных из базы данных. Это освобождает разработчика Bean-компонентов от беспокойства по поводу представления данных и их обработки, дает возможность заниматься интерфейсами баз данных и управлением транзакциями. Тем не менее BMP, которые отдают управление взаимодействием с базой данных в руки разработчика Bean-компонентов, требуются, когда структура данных нетиповая.
В вычислительной архитектуре EJB сервер J2EE управляет одним или несколькими контейнерами. Контейнеры EJB обеспечивают сервисы комплекту экземпляров Bean-компонентов Enterprise. EJB-контейнер отвечает за жизненный цикл EJB, доступ пользователя к EJB-ресурсам, живучесть, через СМР, и за вызов удаленного клиента. Контейнеры прозрачны для клиентских программ. Контейнер заботится об обеспечении уровня запрошенного сервиса во время развертывания, выступая посредником для каждого доступа к EJB. Например, он запускает транзакцию перед вызовом метода, если вы указали в дескрипторе развертывания, что этот метод должен выполняться в контексте транзакции.
Каждый экземпляр EJB должен иметь уникальный идентификатор. Идентификация сессионных Bean-компонентов не предназначена для общего пользования. Объекты создаются и ассоциируются с конкретными клиентами, но их существование без взаимосвязи с клиентом несущественно. Стабильные Bean-компоненты используются совместно и поэтому должны иметь явное местоположение. Возьмем пример операции обновления учетной записи. Сессионный Bean-компонент реализует операцию учетной записи, где стабильный Bean-компонент представляет учетную запись. Если оба, работодатель и служащий, пытаются обновить учетную запись в одно и то же время, в этом случае могут существовать два сессионных Bean-компонента, представляющие сессии работодателя и служащего, но только один стабильный Bean-компонент представляет учетную запись. Стабильный Bean-компонент делает единственный выбор основного ключа для доступа к объекту стабильного Bean-компонента и поддерживает этот основной ключ в домашнем интерфейсе.
Клиент использует домашний интерфейс для обнаружения, создания и удаленного запуска копий EJB (см. рис. 2.3). Каждая копия EJB содержит домашний интерфейс, который вместе со службой имен позволяет клиентскому приложению обнаружить отдельный экземпляр EJB. Когда новый EJB развернут, контейнер EJB регистрирует его подпись в службе имен. Используя интерфейс службы имен и каталогов Java (Java Naming and Directory Interface -JNDI), клиентская программа определяет местонахождение этого домашнего интерфейса. J2EE – это распределенная среда программирования, это означает, что домашний интерфейс может находиться в любом месте домена J2EE. После обнаружения домашнего интерфейса клиент активизирует метод поиска в EJB для обнаружения экземпляра EJB. Если экземпляр существует, то возвращается ссылка на него. Если он еще не существует, то сначала он создается, затем возвращается объектная ссылка. Контейнер отвечает за создание объекта – это часть поискового процесса домашнего интерфейса.
Интерфейс поиска может иметь многочисленные сигнатуры для размещения объекта. Например, вы можете найти учетную запись объекта клиента как ACCOUNTID или как комбинацию полей клиента NAME и HOME_TELEPHONE_NUMBER (если он забудет номер учетной записи).
Чтобы этого достичь, разработчик Bean-компонентов реализует многочисленные методы ejbFind(), с различной сигнатурой для каждого. Контейнер обрабатывает вызов корректного метода ejbFind(), основываясь на параметрах, полученных от вызывающего клиента. Контейнер и Bean-компонент работают в союзе для поддержки интерфейса поиска. Код Bean-компонента запускается из контейнера для определения места расположения экземпляра.
Контейнер поддерживает жизненный цикл каждого EJB. Он реализует производственный интерфейс для каждого класса Bean-компонента, созданного методами createQ, для различных сигнатур активизации объекта. Жизненный цикл также включает инициируемый клиентом вызов removeQ, чтобы удалить этот экземпляр. Так как EJB могут хранить важные ресурсы, есть два других метода жизненного цикла – ejbPassivateQ и ejbActivateQ. Это позволяет контейнеру уведомлять Bean-компонент о завершении жизненного цикла и, таким образом, освобождать ресурсы.
J2EE обеспечивает распределенную среду транзакций. Эта среда позволяет транзакциям координировать обновления многочисленных объектов EJB на многочисленных серверах J2EE, взаимодействуя с менеджерами различных ресурсов (например, баз данных). Преимущество использования EJB над другими методами обработки транзакций в том, что управление транзакциями не привязано жестко к приложениям. Он может быть сконфигурирован во время развертывания через дескрипторы развертывания.
Контейнер управляет контекстом транзакции, основываясь на ценности атрибута транзакции. Каждый EJB будет иметь одну из следующих установок транзакции либо для целого Bean-компонента, либо для конкретных методов:
• TX_NOT_SUPPORTED – нет транзакции поддерживающей вызов;
• TX_BEAN_MANAGED – разграничение транзакции обрабатывается Bean-компонентом;
• TXREQUIRED – этот EJB требует, чтобы всегда применялись управляемые контейнером транзакции;
• TX_SUPPORTS – этот Bean-компонент может запускаться любым способом;
• TX_REQUIRES NEW – этот EJB должен запускаться с новым контекстом транзакции;
• TX_MANDATORY – эта установка подобна TX_REQUIRED, за исключением того, что если клиент не имеет контекста транзакции, то новый контекст не создается, а выдаются сведения об ошибке.
Разграничение транзакции индицирует границы транзакции для стадий двухфазной фиксации: начало, подготовка, фиксация и откат. Имеются два метода для этой обработки. Первый метод – это когда клиент (который может быть сервлетом или EJB, активизированным другим EJB) может явно устанавливать разграничение. Контейнер понимает это разграничение, и если здесь нет конфликта с атрибутами транзакции участвующих EJB, то он проводит двухфазную фиксацию, как инициировано клиентом. Второй метод использует контейнер, который управляет разграничением. Клиент свободно запускает EJB-методы, не заботясь об инициации транзакций. Основываясь на дескрипторах развертывания, контейнер обнаружит, когда потребуется новый бизнес-контекст транзакции, и определит область действия контекста транзакции среди участвующих ресурсов.
• характеристики Bean-компонента (Bean characteristics) – имя Bean-компонента, класс, домашний интерфейс, удаленный интерфейс и тип (объект или сессия);
• класс «первичный ключ» (Primary key class) – идентифицирует класс «первичный ключ» для Bean-компонента;
• управление живучестью (Persistence management) – показывает, чем управляется живучесть: либо Bean-компонентом, либо контейнером;
• управляемые контейнером поля (Container-managed fields) – постоянные поля в классе Bean-компонента, которые контейнер должен синхронизировать с полями в соответствующем источнике данных, для проверки, что эти данные стабильны (persistent) и совместимы (consistent);
• реентерабельность (Reentrance – повторное использование) – определяет, может ли EJB активизировать методы сам, или он должен запросить другой Bean-компонент, чтобы активизировать метод; только стабильные Bean-компоненты можно использовать повторно;
• управление состоянием (State management) – определяет диалоговое состояние сессионного Bean-компонента; этот атрибут должен быть установлен либо на STATEFUL (имеющий состояние), либо STATELESS (не имеющий состояния);
• время ожидания (Timeout) – определяет значение времени ожидания в секундах, ассоциированное с этим сессионным Bean-компонентом.
Дескриптор развертывания содержит следующую информацию по сборке приложения:
• имя дисплея и иконки (Display name and icons) – идентифицируют модуль;
расположение файлов классов (Location of class files) – это обеспечивает клиентской программе доступ к Bean-компонентам в модуле;
• роли в системе безопасности (Security roles) – определяют логическое группирование процессов и пользователей; доступ к операциям (таким, как EJB-методы) контролируется с учетом ролевого имени;
• уровень прав для методов (Method permissions) – определяет соответствие между ролями в системе безопасности и методами, дозволенными для доступа пользователям с этими ролевыми именами;
•транзакция (Transaction) – определяет способ транзакции, в которой контейнер активизирует метод для Enterprise Bean-компонентов, что требует управляемого контейнером разграничения транзакции;
• уровень изоляции транзакции (Transaction isolation level) – определяет степень изоляции транзакций между собой, осуществляемую контейнером;
• RunAsMode/RunAsIdentity – определяет идентичность, используемую для запуска метода.
J2EE предлагает мощный набор сервисов, которые могут использоваться для построения многоярусных приложений Enterprise. Эти сервисы выходят далеко за пределы простой возможности применения баз данных в Web, обеспечивая безопасную, устойчивую инфраструктуру для компонентов и собираемых приложений.
