Целостность

Целостность и непротиворечивость данных при работе J2EE-приложений поддерживается с помощью механизма распределенных транзакций. Управление такими транзакциями может быть возложено на EJB-контейнер, что делается с помощью определения политик участия методов EJB-компонентов в транзакциях в их дескрипторах развертывания, или может осуществляться вручную. В обоих случаях используются механизмы, реализующие интерфейсы управления транзакциями Java (Java Transaction API, JTA).

Базовые интерфейсы JTA находятся в пакетах javax.transaction. и javax.transaction.xa. Это, прежде всего, интерфейсы менеджера транзакций TransactionManager, самих транзакций Transaction и UserTransaction и интерфейс синхронизации Synchronization, позволяющий получать уведомление о начале завершения и конце завершения транзакций.

Методы интерфейса TransactionManager позволяют запустить транзакцию, завершить ее успешно или откатить, а также получить объект, представляющий текущую транзакцию и имеющий тип Transaction. Методы интерфейса Transaction позволяют завершить или откатить транзакцию, представляемую объектом такого интерфейса, зарегистрировать объекты для синхронизации при завершении транзакции, а также добавить некоторые ресурсы в число участников данной транзакции или удалить их из этого списка. Такие ресурсы представляются в виде объектов интерфейса javax.transaction.xa.XAResource. Интерфейс UserTransaction предназначен для управления пользовательскими транзакциями — он предоставляет немного меньше возможностей, чем TransactionManager.

В том случае, если управление транзакциями целиком поручается EJB-контейнеру (это так называемые транзакции, управляемые контейнером, container managed transactions), влиять на их ход можно, указывая в дескрипторах развертывания EJB-компонентов различные транзакционные атрибуты (transaction attributes) для их методов. Транзакционный атрибут может принимать одно из следующих значений.

Required

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

Этот атрибут используется наиболее часто.

RequiresNew

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

Mandatory

Метод, имеющий такой атрибут, должен вызываться только из транзакции, в контексте которой он и продолжит работать. При вызове такого метода извне транзакции будет создана исключительная ситуация типа TransactionRequiredException.

NotSupported

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

Supports

Такой метод работает внутри транзакции, если его вызвали из ее контекста; если же он был вызван вне транзакции, новая транзакция не запускается.

Never

При вызове такого метода из транзакции создается исключительная ситуация типа RemoteException. Он может работать, только будучи вызван извне транзакции.



Откатить автоматически управляемую транзакцию можно, создав исключительную ситуацию типа javax.ejb.EJBException или вызвав метод setRollbackOnly() интерфейса javax.ejb.EJBContext.

Именование

Поиск ресурсов по именам или идентификаторам и набору их свойств в рамках J2EE и J2SE осуществляется при помощи интерфейса JNDI (Java Naming and Directory Interface, Java-интерфейс служб имен и каталогов) [12].

Интерфейсы и классы 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), void rebind(String, Object) — связать данное имя с данным объектом, даже если оно уже имеется в этом контексте), поиска объекта по имени (Object lookup (String)), разрыва связи между именем и объектом (void unbind(String)) и пр.

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

Класс InitialLdapContext реализует общий протокол работы со службами каталогов — простой протокол доступа к службам каталогов (Lightweight Directory Access Protocol, LDAP).

При загрузке виртуальной машины механизм инициализации 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 [13].

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

package examples.jndi;

import java.util.Properties;

import javax.naming.Binding; import javax.naming.Context; import javax.naming.InitialContext; import javax.naming.NamingEnumeration; import javax.naming.NamingException;

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(); } } }

Пример 13.2.

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

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

Платформа Java 2 Enterprise Edition

Платформа J2EE предназначена в первую очередь для разработки распределенных Web-приложений и поддерживает следующие 4 вида компонентов [8]:

Enterprise JavaBeans (EJB).

Компоненты EJB предназначены для реализации на их основе бизнес-логики приложения и операций над данными. Любые компоненты, разработанные на Java, принято называть бинами (bean, боб или фасолина, в разговорном языке имеет также значения головы и монеты). Компоненты Enterprise JavaBean отличаются от "обычных" тем, что работают в рамках EJB-контейнера, который является для них компонентной средой. Он поддерживает следующие базовые службы при работе с компонентами EJB:

Автоматическую поддержку обращений к компонентам, размещенным на разных машинах.Автоматическую поддержку транзакций.Автоматическую синхронизацию состояния баз данных и соответствующих компонентов EJB в обе стороны.Автоматическую поддержку защищенности за счет аутентификации пользователей, проверки прав пользователей или компонентов на выполнение выполняемых ими операций и авторизации производимых действий.Автоматическое управление жизненным циклом компонента (последовательностью переходов между состояниями типа "отсутствует"–"инициализирован"–"активен") и набором компонентов как ресурсами: удаление компонентов, ставших ненужными; загрузку новых компонентов; балансировку нагрузки между имеющимися компонентами; использование пула готовых к работе, но не инициализированных компонентов, чтобы не тратить время на их удаление и создание, и пр.

В целом EJB-контейнер представляет собой пример объектного монитора транзакций (object transaction monitor) — ПО промежуточного уровня, поддерживающего в рамках объектно-ориентированной парадигмы удаленные вызовы методов и распределенные транзакции.

Web-компоненты (Web-components).

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

В группу Web-компонентов входят фильтры (filters), обработчики Web-событий (web event listeners), сервлеты (servlets) и серверные страницы Java (JavaServer Pages, JSP).

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

Обычные приложения на Java.

J2EE является расширением J2SE и поэтому все Java приложения могут работать и в этой среде. Однако, в дополнение к обычным возможностям J2SE, эти приложения могут использовать в своей работе Web-компоненты и EJB, как напрямую, так и удаленно, связываясь с ними по HTTP.

Аплеты (applets).

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



Компонент любого из этих видов оформляется как небольшой набор классов и интерфейсов на Java, а также имеет дескриптор развертывания (deployment descriptor) — описание в определенном формате на основе XML конфигурации компонента в рамках контейнера, в который он помещается. Приложение в целом также имеет дескриптор развертывания. Дескрипторы развертывания играют важную роль, позволяя менять некоторые параметры функционирования компонента и привязывать их к параметрам среды, в рамках которой компонент работает, не затрагивая его код.

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

Платформа .NET

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

В рамках .NET имеются аналоги основных видов компонентов J2EE. Web-компонентам соответствуют компоненты, построенные по технологии ASP.NET, а компонентам EJB, связывающим приложение с СУБД, — компоненты ADO.NET. Компонентная среда .NET обычно рассматриваются как однородная. Однако существующие небольшие отличия в правилах, управляющих созданием и работой компонентов ASP.NET и остальных, позволяют предположить, что в рамках .NET присутствует аналог Web-контейнера, отдельная компонентная среда для ASP.NET, и отдельная — для остальных видов компонентов. Тем не менее, даже если это так, эти среды тесно связаны и, как и контейнеры J2EE, позволяют взаимодействовать компонентам, размещенным в разных средах. Компонентная среда для ASP.NET, в отличие от Web-контейнера в J2EE, поддерживает автоматические распределенные транзакции.

Тем самым, типовая архитектура Web-приложений на основе .NET может быть изображена так, как это сделано на рис. 13.2.

увеличить изображение
Рис. 13.2.  Типовая архитектура Web-приложения на основе .NET

В целом, Web-приложения на основе .NET используют тот же набор архитектурных стилей, что и аналогичные J2EE-приложения.

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

public class HelloImpl extends UnicastRemoteObject

package examples.rmi; import java.rmi.registry.LocateRegistry; import java.rmi.registry.Registry; import java.rmi.server.UnicastRemoteObject; public class HelloImpl extends UnicastRemoteObject implements Hello { public static final String ServerHost = "hostname"; public static final String ServerURL = "rmi://" + ServerHost + ":2001/SERVER"; public static final int RegistryPort = 2000; public HelloImpl () throws java.rmi.RemoteException { } public String hello () throws java.rmi.RemoteException { return "Hello!"; } public static void main (String[] args) { try { Hello stub = new HelloImpl(); Registry registry = LocateRegistry.getRegistry(RegistryPort); registry.rebind(ServerURL, stub); } catch (Exception e) { System.out.println("server creation exception"); e.printStackTrace(); } } }

Пример 13.1.

Закрыть окно

package examples.rmi;
import java.rmi.registry.LocateRegistry;
import java.rmi.registry.Registry;
import java.rmi.server.UnicastRemoteObject;
public class HelloImpl extends UnicastRemoteObject implements Hello
{
public static final String ServerHost = "hostname";
public static final String ServerURL = "rmi://" + ServerHost + ":2001/SERVER";
public static final int RegistryPort = 2000;
public HelloImpl () throws java.rmi.RemoteException { }
public String hello () throws java.rmi.RemoteException
{ return "Hello!"; }
public static void main (String[] args)
{
try
{
Hello stub = new HelloImpl();
Registry registry = LocateRegistry.getRegistry(RegistryPort);
registry.rebind(ServerURL, stub);
}
catch (Exception e)
{
System.out.println("server creation exception");
e.printStackTrace();
}
}
}

public static void main

package examples.jndi; import java.util.Properties; import javax.naming.Binding; import javax.naming.Context; import javax.naming.InitialContext; import javax.naming.NamingEnumeration; import javax.naming.NamingException; 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(); } } }

Пример 13.2.

Закрыть окно

package examples.jndi;
import java.util.Properties;
import javax.naming.Binding;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingEnumeration;
import javax.naming.NamingException;
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(); }
}
}

Конфигурационный файл клиента.

<?xml version="1.0" encoding="utf-8" ?> <configuration> <system.runtime.remoting> <application> <service> <wellknown mode = "Singleton" type = "Examples.Remoting.Hello, Hello" objectUri = "MessageServer" /> </service> <channels> <channel ref = "http" port = "8989" /> </channels> </application> </system.runtime.remoting> </configuration> Конфигурационный файл клиента. <?xml version="1.0" encoding="utf-8" ?> <configuration> <system.runtime.remoting> <application> <client> <wellknown type = "Examples.Remoting.Hello, Hello" url = "http://hostname:8989/MessageServer" /> </client> </application> </system.runtime.remoting> </configuration>

Пример 13.3.

Закрыть окно

Процессы и синхронизация

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

Все методы вспомогательных классов, которые используются Web-компонентами или компонентами EJB, нужно объявлять синхронизированными (synchronized).

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

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

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

Помимо автоматически создаваемых потоков и зон приложений, разработчик может создавать свои собственные потоки и зоны приложений. Вопросы синхронизации потоков и передачи данных между зонами приложений в Web-приложениях могут решаться при помощи стандартных механизмов .NET — конструкций и библиотек синхронизационных примитивов, а также библиотечного класса System.AppDomain, чьи методы позволяют выполнять различные операции с зонами приложений.

Работа с XML

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

Библиотеки для работы с XML-документами находятся в пакетах javax.xml , org.w3c.dom и org.xml.sax, a также во вложенных в них пакетах. В этих пакетах определяются следующие интерфейсы.

Общий интерфейс обработчиков XML находится в пакете javax.xml.parsers. Такие обработчики могут быть основаны на простом интерфейсе работы с XML (Simple API for XML, SAX) [15] или на объектной модели документов (Document Object Model, DOM) [16]. Оба этих подхода основаны на стандартах W3C.Простой интерфейс для работы с XML (SAX) [15] определяется в пакете org.xml.sax. Это интерфейс, основанный на событиях, — XML-парсер, реализующий его, последовательно разбирает XML-данные и генерирует очередное событие в зависимости от вида обнаруженной конструкции. Для работы с XML-документами необходимо написать ряд обработчиков таких событий, являющихся реализациями интерфейса org.xml.sax.ContentHandler.Объектная модель документов (DOM) [16] представляет собой интерфейс работы с XML-документом, представленным в виде дерева его элементов. Java-представление этого интерфейса описано в пакете org.w3c.dom. Одной из его реализаций является JDOM [17], а dom4j [18] предоставляет несколько упрощенную и более удобную с точки зрения Java, но не вполне соответствующую стандарту DOM реализацию.Обработка XML-документов может быть построена на базе расширяемого языка трансформаций на основе таблиц стилей (Extensible Stylesheet Language Transformations, XLST) [19]. При этом процесс обработки документов описывается в виде XSLT-программы, которая затем подается на вход интерпретатору XSLT (XSLT-процессору) вместе с обрабатываемым XML-документом. Интерфейсы для работы с XSLT определены в пакете javax.xml.transform. Широко используемыми XSLT-процессорами являются Saxon [20] и Xalan [21].В новую версию J2EE 5.0, ожидаемую в 2006 году, должны войти интерфейсы для потоковой обработки XML-документов (Streaming API for XML, StAX). В этом подходе XML-документ рассматривается как поток различных конструкций, которые становятся доступными по запросу (pull-модель), в отличие от работы на основе событий в SAX, когда каждая конструкция порождает событие, которое нужно обработать (push-модель). Обработка XML-документов в стиле StAX гораздо более гибкая, чем в SAX, и вполне сравнима с ней по удобству. В настоящее время уже доступны спецификации интерфейсов StAX [22] и несколько их реализаций.

В целом техника работы с XML-документами в .NET опирается на реализацию объектной модели документов XML (DOM) и на механизм разбора, аналогичный StAX, реализуемый классом System.Xml.XmlReader. Классы, реализующие различные парсеры XML, различные варианты представления XML-документов, а также их трансформацию на основе XSLT-описаний, находятся в пространстве имен System.Xml, разбросанном по сборкам System.Data, System.Data.SqlXml и System.Xml.

Одной из особенностей работы с XML в .NET является встроенная возможность работы с XML-данными в рамках механизмов ADO.NET (в основном предназначенных для работы с реляционными СУБД) с помощью класса System.Xml.XmlDataDocument.