Компонентные технологии разработки web-приложений

Связь

Связь между компонентами, работающими в разных процессах и на разных машинах, обеспечивается в J2EE, в основном, двумя способами: синхронная связь — с помощью реализации удаленного вызова методов на Java ( Java RMI ), асинхронная — с помощью службы сообщений Java (Java message service, JMS ).

Java RMI [10] является примером реализации общей техники удаленного вызова методов. Базовые интерфейсы для реализации удаленного вызова методов на Java находятся в пакете java.rmi стандартной библиотеки.

Набор методов некоторого класса, доступных для удаленных вызовов, выделяется в специальный интерфейс, называемый удаленным интерфейсом (remote interface) и наследующий java.rmi.Remote. Сам класс, методы объектов которого можно вызвать удаленно, должен реализовывать этот интерфейс. Этот же интерфейс реализуется автоматически создаваемой клиентской заглушкой. Поэтому объекты-клиенты работают только с объектом этого интерфейса, а не с объектом класса, реализующего декларированные в таком интерфейсе операции.

Кроме того, класс, реализующий удаленный интерфейс, должен наследовать класс java.rmi.server.RemoteObject. Этот класс содержит реализации методов hashCode(), equals() и toString(), которые учитывают возможность размещения его объектов в процессах, отличных от того, где они вызываются. Обычно наследуется не сам этот класс, а его подклассы java.rmi.server.UnicastRemoteObject или java.rmi.activation.Activatable. Первый реализует общую функциональность объектов, которые можно вызвать удаленно поверх транспортного протокола TCP, пока работает содержащий их процесс, включая занесение информации о таких объектах в реестр RMI (собственная служба именования в рамках Java RMI ). Второй класс служит для реализации активизируемых объектов (activatable objects), которые создаются системой "по требованию" — как только кто-нибудь вызывает в них какой-нибудь метод. Ссылки на такие объекты могут сохра няться, а обратиться к ним можно спустя долгое время, даже после перезагрузки системы.

Каждый удаленный метод (remote method), т.е. метод, который можно вызвать из другого процесса, должен декларировать в качестве класса возможных исключений java.rmi.RemoteException или его базовые типы java.io.IOException или java.lang.Exception. Этот класс сам служит базовым для классов исключений, представляющих ошибки связи, ошибки маршалинга параметров или результатов и ошибки протоколов, реализующих RMI.

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

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

Простой пример Java-классов, взаимодействующих по RMI, приведен ниже.

Код удаленного интерфейса:

package examples.rmi;

public interface Hello extends java.rmi.Remote
{
  public String hello() throws java.rmi.RemoteException;
}

Код реализации удаленного интерфейса.

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

Код класса-клиента.

package examples.rmi;

import java.rmi.registry.LocateRegistry;
import java.rmi.registry.Registry;

public class HelloClient
{
  public HelloClient () { }

  public static void main (String[] args)
  {
    try
    {
      Registry registry = LocateRegistry.getRegistry
                          (HelloImpl.ServerHost, HelloImpl.RegistryPort);
      Hello stub = (Hello) registry.lookup(HelloImpl.ServerURL);
      System.out.println("response: " + stub.hello());
    }
    catch (Exception e) 
    {
      System.err.println("Client exception: " + e.toString());
      e.printStackTrace();
    }
  }
}

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

rmic examples.rmi.HelloImpl

start rmiregistry 2000 

java examples.rmi.HelloImpl

java examples.rmi.HelloClient

Если никаких ошибок не сделано, и порты 2000 и 2001 на серверной машине свободны, клиент выдаст сообщение.

response: Hello!

Поскольку базовые интерфейсы компонентов EJB наследуют java.rmi.Remote, такие компоненты автоматически предоставляют возможность обращаться к некоторым из своих методов удаленно.

Служба сообщений Java ( JMS ) [11] представляет собой спецификацию интерфейсов для поддержки передачи сообщений (в частности, асинхронных) между компонентами в рамках платформы J2EE. Ее базовые библиотеки — пакет javax.JMS — не входят в состав J2SE. Та или иная реализация JMS должна входить в любую реализацию платформы J2EE.

Основные элементы JMS следующие.

Именование

Поиск ресурсов по именам или идентификаторам и набору их свойств в рамках 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 приложения или аплета, включает следующие:

Ниже приведен пример использования 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(); }
  }
}

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

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

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

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

Целостность

Целостность и непротиворечивость данных при работе 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) для их методов. Транзакционный атрибут может принимать одно из следующих значений.

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

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

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

Защита

Защищенность J2EE приложения поддерживается несколькими способами.

Работа с XML

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

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

Платформа .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.

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

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

Связь

Связь между компонентами в рамках .NET осуществляется при помощи механизма Remoting, реализующего как RMI, так и асинхронную передачу сообщений.

Классы и интерфейсы, служащие основой механизма Remoting, находятся в пространстве имен System.Runtime.Remoting и его подпространствах, в сборках mscorlib и System.Rutime.Remoting.

В рамках Remoting объекты, которые могут участвовать в качестве целей удаленного вызова, его параметров и результатов, делятся на передаваемые по значению (marshal-by-value) и передаваемые по ссылке (marshal-by-reference).

Тип объекта, передаваемого по значению, должен реализовывать интерфейс System.Runtime.Serialization.ISerializable или должен быть помечен атрибутом System.SerializableAttribute. В последнем случае .NET автоматически создает код, необходимый для сериализации или десериализации данных объекта. Исключения, которые могут быть созданы методом, вызываемым удаленно, также должны быть передаваемы по значению.

Объекты, передаваемые по ссылке, должны наследовать классу System.MarshalByRefObject. При передаче такого объекта как аргумента или результата в другом процессе (или зоне приложения, см. следующий раздел) создается клиентская заглушка, связанная с этим объектом и называемая в .NET посредником (proxy).

Более тонкую настройку удаленных вызовов можно делать при помощи наследников класса System.ContextBoundObject. Наследование этого класса говорит о том, что удаленные вызовы в объекте этого класса должны происходить в рамках некоторого контекста, являющегося частью его зоны приложения. Примером такого контекста служит контекст транзакции. При вызовах таких объектов .NET проводит дополнительные проверки, связанные с разницей контекстов между вызывающим объектом и вызываемым.

Ниже находится пример взаимодействующих по механизму Remoting классов, имеющий ту же функциональность, что и пример, приведенный для Java RMI.

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

using System;

namespace Examples.Remoting
{
  public class Hello : MarshalByRefObject
  {
    public String HelloMethod() { return "Hello!"; }
  }
}

Код сервера, ожидающего обращения клиентов.

using System;
using System.Runtime.Remoting;

namespace Examples.Remoting
{
  public class HelloImpl
  {
    public static void Main()
    {
      RemotingConfiguration.Configure("RemotingServer.exe.config");
      Console.ReadLine();
    }
  }
}

Код клиентского класса.

using System;
using System.Runtime.Remoting;

namespace Examples.Remoting
{
  public class HelloClient
  {
    public static void Main()
    {
      RemotingConfiguration.Configure("RemotingClient.exe.config");
      Hello stub = new Hello();
      Console.WriteLine("response: " + stub.HelloMethod());
    }
  }
}

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

<?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>

Чтобы запустить этот пример, нужно выполнить следующие шаги.

csc.exe /noconfig /t:library Hello.cs
csc.exe /noconfig /r:Hello.dll Server.cs
csc.exe /noconfig /r:Hello.dll Client.cs

Server.exe

Client.exe

response: Hello!

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

Асинхронное взаимодействие в рамках .NET может быть реализовано с помощью имеющихся в библиотеке .NET асинхронных делегатов, на основе асинхронных удаленных вызовов по Remoting или с помощью обмена сообщениями на базе библиотек System.Messaging.

Взаимодействие между компонентами ASP.NET использует похожие, но скрытые от разработчика компонентов механизмы.

Именование

В примере на взаимодействие по Remoting использовалась локальная служба именования, встроенная в среду .NET — поэтому никаких специальных действий по регистрации и поиску компонентов не производилось. Эта служба позволяет не заботиться об этих вопросах в том случае, если физическое положение компонентов, с которыми необходимо установить связь, известно и постоянно.

Если же это не так, необходимо иметь полноценную службу именования и/или службу каталогов. В этом качестве в .NET используется Active Directory. Поскольку эта технология появилась раньше, чем среда .NET, в рамках .NET была создана библиотека адаптеров, позволяющих использовать функции Active Directory. Элементы этой библиотеки находятся в пространстве имен System.DirectoryServices и его подпространствах, в сборках System.DirectoryServices и System.DirectoryServices.Protocols.

Для работы с записями Active Directory используются объекты класса System.DirectoryServices.DirectoryEntry. C помощью конструкторов и методов этого класса можно создавать и изменять регистрационные записи службы каталогов. Для поиска зарегистрированных объектов по идентификаторам или свойствам используются методы класса System.DirectoryServices.DirectorySearcher.

Active Directory поддерживает обращения к своим записям по нескольким разным протоколам, включая протокол LDAP.

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

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

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

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

Целостность

Целостность данных в .NET поддерживается, как и в J2EE, в основном, за счет механизма транзакций. Распределенные транзакции в .NET реализованы на базе сервера транзакций Microsoft (Microsoft Transaction Server, MTS), который появился как часть компонентной среды COM+. Интерфейсы для работы с его функциями собраны в пространстве имен System.EnterpriseServices, в сборке с таким же именем.

Автоматические транзакции поддерживаются при помощи указания у классов транзакционных атрибутов, имеющих тип System.EnterpriseServices.TransactionAttribute. Такой атрибут может принимать значения Required, RequiresNew, NotSupported, Supported и Disabled. Первые три имеют то же значение, что и в J2EE. Атрибут Supported действует аналогично Supports в J2EE. Атрибут Disabled обозначает, что транзакционный контекст вызвавшего метода будет проигнорирован.

Значение атрибутов по умолчанию для методов компонентов ASP.NET и методов обычных классов, используемых в распределенных транзакциях, различны — у первых это Disabled, у вторых — Required.

Чтобы определить класс, чьи методы могут участвовать в транзакциях, нужно унаследовать его от класса System.EnterpriseServices.ServicedComponent, определить транзакционный атрибут, а также прикрепить к сборке, содержащей этот класс, сертификат и зарегистрировать сборку в реестре COM+.

Для завершения или отката автоматической транзакции используются следующие конструкции.

Создание и управление транзакциями "в ручном режиме" может быть осуществлено для компонентов ADO.NET при помощи методов класса System.Data.Common.DbConnection и его наследников и класса System.Data.Common.DbTransaction. Для управления транзакциями при передаче сообщений используется класс System.Messaging.MessageQueueTransaction.

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

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

Защита

Защищенность .NET-приложений поддерживается примерно теми же методами, что и защищенность J2EE-приложений.

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

Программные интерфейсы к различным механизмам управления защищенностью приложений и ресурсов реализуются классами и интерфейсами пространства имен System.Security, находящимися в сборках mscorlib, System и System.Security.

Работа с XML

В целом техника работы с 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.