4.6 Среда Microsoft Message Queuing (msmq)
Промежуточная среда MSMQ – разработка Microsoft для асинхронной передачи сообщений внутри локальной сети, впервые появившаяся в составе операционной системы Windows NT. В настоящее время последней является версия MSMQ 3.0, включенная в Windows XP PE и 2003 Server, достаточно актуальна так же версия 2.0, включенная в состав операционной системы Windows 2000.
Служба MSMQ позволяет произвольному набору приложений добавлять сообщения в некоторую очередь, и произвольному же набору – читать сообщения из очереди.
Приложению, использующему MSMQ, доступны следующие основные операции:
– добавить сообщение в очередь;
– извлечь первое сообщение из очереди;
– установить обработчик, вызываемый при появлении сообщения.
Структура сообщения определяется приложением, и может быть произвольной, с ограничением на размер одного сообщения (2Мб для MSMQ 2.0).
При отправке сообщения с использованием MSMQ посылающему приложению необходимо указать имя компьютера и очереди, в которую его необходимо доставить.
После вызова приложением функции отправки сообщение сохраняется в локальной исходящей очереди. Затем MSMQ определяет имя компьютера и очереди, куда необходимо передать сообщение. Возможны следующие случаи:
– сообщение доставляется сразу в указанную отправителем очередь (прямая доставка);
– сообщение посылается в некоторую промежуточную очередь, определяемую маршрутизатором службы сообщений;
– MSMQ определяет, что сообщение требуется разослать в несколько очередей (возможность поддерживается начиная с MSMQ 3.0).
Менеджер очереди сообщений в таких системах может находиться на удаленном компьютере. В этом случае сообщение первоначально помещается в исходящую очередь на компьютере с посылающей сообщения компонентой, а затем пересылается менеджеру требуемой.
Для создания крупных систем обмена сообщениями может использоваться маршрутизация сообщений, при которой сообщения не передаются напрямую менеджеру, поддерживающему очередь, а проходят через ряд промежуточных менеджеров очередей сообщений (рис. 4.4).
Рис. 4.4. Системы очередей сообщений
После определения имени компьютера с очередью назначения, MSMQ проверяет доступность компьютера (пакетом UDP) и в случае ответа сразу пытается отправить ему сообщение, повторяя попытки с интервалом по умолчанию 5 секунд. Если сообщение не удается отправить, то обычно каждые 5 минут служба сообщений пытается найти новый пункт назначения сообщения, используя маршрутизацию MSMQ. Процесс пересылки сообщения между компьютерами повторяется, пока оно не достигнет очереди назначения. С момента поступления сообщения в указанную при отправке очередь любое использующее MSMQ приложение с необходимыми правами доступа может прочитать это сообщение (рис 4.5).
Рис. 4.5. Пересылка сообщения в промежуточной среде MSMQ
Таким образом, MSMQ поддерживает асинхронную передачу сообщений, при которой участвующие в обмене компоненты распределенной системы не обязательно должны функционировать в один и тот же момент времени.
Благодаря службе маршрутизации сообщений возможно создание моста между MSMQ и аналогичной технологией IBM – IBM Websphere MQ (ранее MQSeries).
Websphere MQ может использоваться и напрямую программами .NET Framework, однако обычно это менее удобно, чем использование MSMQ, и может быть связано с дополнительными затратами – служба MSMQ уже входит в большинство систем семейства Windows. Использование моста MSMQ-MQSeries позволяет создавать гетерогенные распределенные системы на основе обмена сообщениями, поскольку технология IBM MQ является изначально межплатформенной.
Приложение может вести поиск нужной ему очереди по ряду критериев. Это возможно при использовании механизма общих очередей в Microsoft Message Queuing, что требует развертывания Microsoft Active Directory.
Инфраструктура, необходимая для использования MSMQ
Служба MSMQ может работать как в составе домена Active Directory, так и при отсутствии такого домена, но во втором случае невозможно использовать ряд возможностей MSMQ, а именно:
– не поддерживается шифрование передаваемых сообщений;
– не поддерживаются общие очереди и механизмы их обнаружения;
– не поддерживается маршрутизация сообщений и групповая рассылка сообщений.
В MSMQ существуют два вида очередей – общие (public) и частные (private). Как частные, так и общие очереди могут либо использовать, либо не использовать транзакции, что задается при создании очереди и не может быть изменено в дальнейшем.
Информация об общих очередях публикуется в службе каталогов Active Directory. Путь к общей очереди имеет вид ComputerName\QueueName, возможна также запись пути в
виде .\QueueName для очереди на локальном компьютере. Посылающее сообщение приложение может искать доступные в домене общие очереди по заданным критериям.
Возможна также проверка приложением наличия общей очереди на удаленном компьютере и ее создание. Для использования общих очередей требуется развертывание MSMQ в рамках домена Active Directory.
Частные очереди доступны как при наличии домена, так и при его отсутствии. Путь к такой очереди имеет вид ComputerName\Private$\QueueName или .\Private$\QueueName для локального компьютера. Приложение, не имеет возможности ни создать, ни проверить наличие частной очереди на удаленном компьютере при использовании средств библиотеки FCL.
Применение службы сообщений MSMQ в распределенных системах
Рассмотрим возможности, предоставляемые службой MSMQ как промежуточным программным обеспечением с точки зрения требований, предъявляемых к распределенной системе.
1. Открытость. Требование выполняется частично: используя в качестве сообщения XML-документ с заданной XSD-схемой, можно добиться открытости передаваемых данных. Однако сама технология MSMQ является закрытой и одноплатформенной.
2. Безопасность. MSMQ поддерживает обычные для Windows NT списки управлением доступа (ACL) для каждой очереди, а при наличии домена AD – прозрачное шифрование сообщений. Таким образом, система, использующая MSMQ, может являться безопасной при развертывании в пределах домена Active Directory.
3. Расширяемость. MSMQ позволяет создавать масштабируемые системы, поскольку не накладывает ограничений на число машин, считывающих сообщения из одной очереди.
Если время обработки сообщения удаленным приложением несравнимо больше времени на его пересылку между очередями, то возможен линейный рост производительности при увеличении числа компьютеров, считывающих и обрабатывающих сообщения из очереди.
4. Обеспечение целостности данных. MSMQ поддерживает внутренние транзакции, распределенные транзакции среды COM+ и транзакции из System.Transactions.
Внутренние транзакции гарантируют, что некоторая последовательность операций компоненты с очередями (например, получение сообщение и отправка ответа на него) будет либо выполнена полностью, либо не выполнена вообще. Транзакции среды COM+ и пространства имен System.Transactions используют координатор распределенных транзакций (MS DTC). При их использовании в последовательность операций, образующих транзакцию, кроме действий с очередями сообщений могут входить операции с любыми службами, поддерживающие распределенные транзакции. Кроме использования транзакций, для повышения надежности в MSMQ следует использовать механизм восстанавливаемых сообщений, который повышает вероятность того, что после принятия службой MSMQ сообщение не будет потеряно при аварийном отключении питания.
5. Устойчивость. Основной особенностью MSMQ является возможность использования нескольких читающих из очереди серверов. Кроме того, при использовании общих очередей возможен выбор того или иного компьютера с требуемой очередью. В силу этого при использовании очередей сообщений можно избежать возникновения уникальной точки уязвимости.
Таким образом, с точки зрения требований к распределенной системе технология MSMQ обладает многочисленными достоинствами. Однако данная технология промежуточного ПО также имеет ряд важных недостатков.
– необходимость явного использования очередей распределенным приложением;
- сложность реализации синхронного обмена.
Службы очередей сообщений находят наилучшее применение в случаях, когда какая-либо компонента распределенной системы посылает заявки, не требующие ответа (модель «запрос»). Если же компонента получает некоторые ответы в асинхронном режиме (модель «запрос-ответ»), то она должна поддерживать собственный список ожидающих ответов заявок. Это означает наличие у компоненты некоторого внутреннего состояния, которое должно сохраняться в течение длительного времени. Наличие такого состояния является недостатком с точки зрения концепции распределенной системы как набора сервисов, не сохраняющих историю своих вызовов. С точки зрения этой концепции использующая MSMQ компонента либо дожидается ответа сервера в течение одного своего вызова другими компонентами, либо не нуждается в ответе вообще.
В первом случае MSMQ предпочтительнее технологий удаленного вызова в одном из в следующих случаев:
– обеим взаимодействующим компонентам известен только посредник (компьютер с используемой очередью сообщений);
– заявки обрабатываются несколькими компьютерами параллельно;
– вызывающая компонента не знает внешний интерфейс удаленного вызова вызываемой компоненты.
Использование очередей сообщений MSMQ в .NET Framework
Для работы с очередями сообщений используются классы из пространства имен System.Messaging. Класс System.Messaging.MessageQueue содержит три группы методов.
1. Статические методы для администрирования очередей: Create, Delete, Exists, Purge.
2. Методы поиска общих очередей: GetPublicQueues, GetPublicQueuesByLabel и другие. При их использовании можно создать приложение, которое переключается между несколькими менеджерами очередей в пределах Active Directory, если один из них выходит из строя.
3. Методы для работы с сообщениями (Send, Receive, Peek и другие), в том числе позволяющие использовать обработчик на завершение операции (BeginPeek, BeginReceive).
При применении классов из System.Messaging возможно три варианта работы с очередями сообщений:
– работа с очередями, не использующими транзакции;
– работа с очередями, поддерживающими транзакции, при использовании внутренних транзакций MSMQ;
– работа с очередями, поддерживающими транзакции, при использовании распределенных транзакций COM+.
Определенной трудностью при использовании MSMQ в .NET Framework являются различия по использованию разных видов очередей. В частности, для очередей без транзакций можно установить обработчик на завершение приема сообщения, а для очередей с транзакциями этот способ неприемлем, поскольку само чтение сообщения должно быть оформлено как часть транзакции. Для обоих видов очередей можно поставить обработчик на появление сообщения в очереди, что и является рекомендованным способом.
Пример.
Программа использует пространство имен с классами передачи сообщений System.Messaging и пространство имен с коллекциями общего вида.
using System;
using System.Messaging;
using System.Collections.Generic;
Классы используют два делегата общего вида, которые будут связаны с событиями обработки сообщения сервером и получения ответа клиентом.
namespace Seva.Msmq
{
// типы очередей
enum QueueType {NonTransactional, Transactional};
// типы классов форматирования
enum QueueFormatter {Binary, Xml};
// делегат общего вида для обработки сервером сообщений клиента
delegate AnswerType ProcessRequestEventHandler
<RequestType, AnswerType>(Object sender, RequestType request,
MessageQueue queueResponse);
// делегат общего вида для обработки ответов сервера клиентом
delegate void ProcessAnswerEventHandler<RequestType, AnswerType>
(Object sender, RequestType request, AnswerType answer);
Абстрактный класс MSMQUser, наследуемый классами MSMQServer и MSMQClient.
public abstract class MsmqUser
{
// использование восстанавливаемых сообщений
private bool recoverable = false;
public bool Recoverable
{
get {
return recoverable;
}
set {
recoverable = value;
}
}
// объекты форматирования для посылки приема сообщений
protected IMessageFormatter requestFormatter;
protected IMessageFormatter answerFormatter;
//
public MsmqUser(QueueFormatter formatterType)
{
if (formatterType == QueueFormatter.Xml)
{
requestFormatter = new XmlMessageFormatter(
new Type[]{typeof(RequestType)});
answerFormatter = new XmlMessageFormatter(
new Type[]{typeof(AnswerType)});
}
if (formatterType == QueueFormatter.Binary)
{
requestFormatter = new BinaryMessageFormatter();
answerFormatter = new BinaryMessageFormatter();
}
}
}
Класс общего вида, посылающий через MSMQ запросы и получающий ответы на них.
class MsmqClient<RequestType, AnswerType> :
MsmqUser<RequestType, AnswerType>, IDisposable
{
// очереди для отсылки запросов и приема ответов
private MessageQueue queueSend;
private MessageQueue queueReceive;
// список необслуженных запросов
private Dictionary<String, RequestType> messages;
public Dictionary<String, RequestType> Messages
{
get { return messages;}
}
// событие, вызываемое при приеме ответа
public event ProcessAnswerEventHandler<RequestType, AnswerType>
ProcessAnswer;
Конструктор, получающий имена очередей для посылки и приема сообщений.
public MsmqClient(String queueSendName, String queueReceiveName,
QueueFormatter formatterType): base(formatterType)
{
// список отправленных сообщений без ответов
messages = new Dictionary<String,RequestType>();
// создание очереди для посылки запросов, если она не существует
queueSend = MsmqTools.CreateQueue(queueSendName,
QueueType.Transactional);
// создание очереди для приема ответов, если она нужна
if (queueReceiveName != null)
{
queueReceive = MsmqTools.CreateQueue(queueReceiveName);
queueReceive.Formatter = answerFormatter;
// считывать из очереди свойство CorrelationId
queueReceive.MessageReadPropertyFilter.CorrelationId = true;
}
else
{
queueReceive = null;
}
}
В методе Dispose происходит закрытие используемых очередей.
public void Dispose()
{
queueSend.Close();
queueSend.Dispose();
if (queueReceive != null)
{
queueReceive.Close();
queueReceive.Dispose();
}
}
Функции BeginReceive и EndReceive начинают и прекращают прием ответов сервера,
изменяя обработчик события PeekComplete очереди ответов.
public void BeginReceive()
{
// установить обработчик на событие, возникающее при появлении
// сообщения в очереди
queueReceive.PeekCompleted += OnPeek;
// начать отслеживание поступления сообщения в очередь
queueReceive.BeginPeek();
}
// прекратить прием ответов сервера
public void EndReceive()
{
// отключить обработчик
queueReceive.PeekCompleted -= OnPeek;
}
Функция Send посылает в исходящую очередь запрос общего типа для его обработки сервером. Для ответа на сообщение серверу следует использовать очередь, указанную в поле ResponseQueue посылаемого сообщения.
public void Send(RequestType request)
{
// создание нового сообщения
Message message = new Message(request, requestFormatter);
message.ResponseQueue = queueReceive;
// использование восстаналиваемых сообщений
message.Recoverable = Recoverable;
// послать сообщение; поскольку транзакция состоит из
// единственной операции, вместо объекта-транзакции используется
// значение MessageQueueTransactionType.Single
queueSend.Send(message, MessageQueueTransactionType.Single);
// поле message.Id устанавливается после посылки сообщения;
// идентификатор сообщения связывается c отосланным запросом
// в списке необслуженных запросов
messages.Add(message.Id, request);
}
Обработчик события очереди PeekComplete использует внутренние транзакции MSMQ.
В одну транзакцию входит операция чтения ответа из очереди и последующий вызов события ProcessAnswer. Если в ходе обработки события возникло исключение, ответ сервера останется в очереди ответов. Иначе сообщение удаляется из поддерживаемого клиентом списка невыполненных запросов.
public void OnPeek(Object source, PeekCompletedEventArgs asyncResult)
{
// создание внутренней транзакции MSMQ
MessageQueueTransaction transaction = new MessageQueueTransaction();
// начало транзакции
transaction.Begin();
try
{
// прекратить ожидание сообщений в очереди
queueReceive.EndPeek(asyncResult.AsyncResult);
// получить сообщение из очереди в рамках транзакции
Message message = queueReceive.Receive(transaction);
// в поле CorrelationId должен быть идентификатор сообщения
// с исходным запросом
String messageId = message.CorrelationId;
// есть ли такое сообщение в списке невыполненных запросов?
if (messages.ContainsKey(messageId))
{
if (message.Body is AnswerType)
{
// преобразовать тело сообщения к типу ответа
// и вызвать событие по его обработке
AnswerType answer = (AnswerType) message.Body;
ProcessAnswer(this, messages[messageId], answer);
};
messages.Remove(messageId);
}
// продолжить ожидать сообщения
BeginReceive();
// успешное завершение транзакции
transaction.Commit();
}
catch (Exception e)
{
// отмена транзакции
transaction.Abort();
throw e;
}
}
}
MSMQServer – класс общего вида, принимающий через MSMQ запросы и посылающий
ответы на них.
class MsmqServer<RequestType, AnswerType>:
MsmqUser<RequestType, AnswerType>, IDisposable
{
// очередь приема запросов
private MessageQueue queueReceive;
// событие, вызываемое при приеме запроса
public event ProcessRequestEventHandler<RequestType, AnswerType>
ProcessMessage;
Конструктор класса проверяет наличие очереди.
public MsmqServer(String queueReceiveName, QueueFormatter formatterType):
base(formatterType)
{
// создание очереди приема сообщений, если она не существует
queueReceive = MsmqTools.CreateQueue(queueReceiveName,
QueueType.Transactional);
queueReceive.Formatter = requestFormatter;
}
В методе Dispose происходит закрытие используемых очередей.
{
queueReceive.Close();
queueReceive.Dispose();
}
Функции BeginReceive и EndReceive начинают и прекращают прием ответов сервера,
изменяя обработчик события PeekComplete очереди ответов.
// начать прием запросов от клиента
public void BeginReceive()
{
queueReceive.PeekCompleted += OnPeek;
queueReceive.BeginPeek();
}
// прекратить прием запросов от клиента
public void EndReceive()
{
queueReceive.PeekCompleted -= OnPeek;
}
Метод OnPeek – обработчик события PeekCompleted очереди с запросами. В одну транзакцию входит две операции с очередями – чтения запроса и отправка ответа на него. Для обработки принятого сообщения и создания ответа на него вызывается событие ProcessMessage. В поле ResponseQueue полученного сообщения содержится ссылка на очередь, в которую следует отправить ответ на обработанный запрос.
// обработчки события PeekCompleted очереди с запросами
public void OnPeek(Object source, PeekCompletedEventArgs asyncResult)
{
// создание внутренней транзакции MSMQ
MessageQueueTransaction transaction = new MessageQueueTransaction();
// начало транзакции
transaction.Begin();
try
{
queueReceive.EndPeek(asyncResult.AsyncResult);
// прием cообщения в рамках транзакции
Message message = queueReceive.Receive(transaction);
// в поле ResponseQueue содержится ссылка на очередь,
// куда следует послать ответ на запрос
MessageQueue queueResponse = message.ResponseQueue;
try
{
if (message.Body is RequestType)
{
RequestType request = (RequestType) message.Body;
// вызвать событие обработки запроса
AnswerType answer = ProcessMessage(this, request,
queueResponse);
if ((queueResponse != null) && (answer != null))
{
Message answerMessage = new Message(answer, answerFormatter);
answerMessage.Label = "Answer";
answerMessage.CorrelationId = message.Id;
answerMessage.Recoverable = Recoverable;
// послать собщение в рамках транзакции
queueResponse.Send(answerMessage, transaction);
}
}
}
finally
{
if (queueResponse != null)
{
queueResponse.Close();
queueResponse.Dispose();
}
};
// продолжить прием запросов
BeginReceive();
// завершить транзакцию
transaction.Commit();
}
catch (Exception e)
{
// отменить транзакцию в случае ошибки
Console.WriteLine(e);
transaction.Abort();
throw e;
}
}
}
Класс MsmqTools содержит вспомогательный статический метод для создания очереди сообщений.
static class MsmqTools
{
static public MessageQueue CreateQueue(String queueName)
{
return CreateQueue(queueName, QueueType.Transactional);
}
// функция проверяет наличие очереди и создает ее при необходимости
static public MessageQueue CreateQueue(String queueName,
QueueType type)
{
MessageQueue messageQueue;
// если это частная очередь удаленного компьютера,
// то при попытке проверки ее наличие возникает исключение
try
{
if (!MessageQueue.Exists(queueName))
{
MessageQueue.Create(queueName,
type == QueueType.Transactional);
}
}
catch(Exception)
{
}
MessageQueue messageQueue = new MessageQueue(queueName);
return messageQueue;
}
}
}
Следует отметить, что при работе с общими очередями можно обращаться к очереди по ее пути, например следующим образом.
queueName = @"Server\PublicQueue";
При использовании частных очередей на удаленном компьютере в большинстве случаев требуется применять прямое имя очереди.
queueName = @"Formatname:DIRECT=OS:Computer\Private$\PrivateName";
Имена используемых очередей следует хранить в конфигурационном файле программы.
Выводы по использованию MSMQ
Промежуточная среда Microsoft Message Queuing обеспечивает асинхронный обмен сообщениями и может быть использована программными компонентами распределенной системы в одном из следующих случаях:
– необходимо организовать параллельную обработку заявок несколькими компьютерами;
– одна компонента посылает другой запросы без получения ответов на них;
– взаимодействие компонент не должно быть синхронным;
– требуется интеграция с какими-либо другими независимыми системами, которые могут использовать очереди сообщений (MSMQ или IBM MQ).
Альтернативным способом использования MSMQ являются отложенные компоненты (queued components) среды COM+
Кроме того, существует возможность использовать MSMQ как канал в .NET Remoting, для чего необходимо создать собственный канал.
Таким образом, MSMQ является не только самостоятельной промежуточной средой, но и может быть использовано другими промежуточными средами как асинхронный канал передачи данных.
3.4. Технология EJB для построения распределенных систем
Технология EJB (Enterprise JavaBeans) представляет собой один из подходов к построению распределенных систем. С помощью этой технологии разработчику достаточно программировать только бизнес-логику приложения и можно не заниматься стандартными вещами, такими, как обработка транзакций. Данная архитектура предполагает, что подобные стандартные функции - проблема производителя сервера.
К ее конкурентам можно отнести RMI (remote method invocation - вызов удаленных методов), CORBA (common object request broker architecture), DCOM (distributed component object model) и некоторые другие. Надо сказать, что многие принципы CORBA были сознательно положены в основу EJB. Более того, существует стандарт отображения EJB на CORBA, касающийся службы имен и управления транзакциями и безопасностью.
Спецификация EJB определяет следующие цели:
Облегчить разработчикам создание приложений, избавив их от необходимости реализовывать с нуля такие службы, как транзакции (transactions) и другие. Разработчики могут сконцентрироваться на описании логики своих приложений, оставляя заботы о хранении, передаче и безопасности данных на EJB-систему. При этом все равно имеется возможность самому контролировать и описывать порученные системе процессы.
Описать основные структуры EJB-системы, описав при этом интерфейсы взаимодействия между ее компонентами.
EJB преследует цель стать стандартом для разработки приложений клиент/сервер на Java. Таким же образом, как исходные JavaBeans компоненты от различных производителей можно было составлять вместе с помощью соответствующих RAD-систем, получая в результате работоспособные клиенты, таким же образом серверные компоненты EJB от различных производителей также могут быть использованы вместе. EJB-компоненты, будучи Java-классами, должны работать на любом EJB-совместимом сервере даже без перекомпиляции, что практически нереально для других систем.
EJB совместима с Java API, может взаимодействовать с другими (не обязательно Java) приложениями, а также совместима с CORBA.
Основная идея, лежавшая в разработке технологии Enterprise JavaBeans - создать такую инфраструктуру для компонент, чтобы они могли бы легко ``вставляться'' (``plug in'') и удаляться из серверов, тем самым увеличивая или снижая функциональность сервера. Каждый компонент в среде EJB должен функционировать внутри контейнера, изолирующего его от ОС сервера.
Контейнер автоматически выделяет компоненту поток процессов и управляет от его имени службами поддержки параллелизма, защиты, долговременного хранения, транзакционной обработки и другими службами, предоставляемыми приложениям со стороны серверной среды.
В составе служб серверной среды EJB предусмотрены:
1. Протокол удаленной связи. Java Beans имеет доступ к протоколу удаленного вызова методов (Remote Method Invocation, RMI), входящему в состав Java и работающему непосредственно поверх сетевых протоколов TCP/IP.
2 Служба каталогов. Эта служба обеспечивается через независимый от реализации API-интерфейс Java Naming & Directory Interface (JNDI) компании Sun Microsystems, позволяющий приложениям, написанным на языке Java, пользоваться имеющимися службами каталогов, например, DNS.
3. Служба безопасности. Платформа EJB может использовать все сервисы защиты, предоставляемые стандартным пакетом Java-security от Sun Microsystems. К ним относятся: аутентификация с применением открытого и секретного ключей, шифрование, управление цифровыми ключами и списками контроля доступа.
4. Служба системного администрирования. Эта служба обеспечивается через API-интерфейс Java Management API (JMAPI) компании Sun Microsystems. Он предоставляет набор служб мониторинга, управления и администрирования, а также описание пользовательского интерфейса консоли системного администратора.
5. Служба транзакций. В среде EJB определена модель обработки транзакций, в основу которой положена спецификация Object Transaction Service, разработанная Object Management Group (OMG) (API-интерфейс Java Transaction Service, JTS, в этой среде не используется).
В модели Java Beans предусмотрены средства, позволяющие упаковать компоненты Java Beans для вложения в контейнеры, поддерживающие модель DCOM, в том числе в контейнеры для MS Visual Basic, MS Internet Explorer, MS Office, Lotus Notes. Для этого служит специальный коммуникационный мост, технологической основой которого служит утилита упаковки. Эта утилита для выбранных компонентов Java Beans генерирует библиотеку OLE Type Library и реестровую информацию для интерфейса Win32 ОС Windows. Полученные в результате данные позволяют контейнерам DCOM правильно анализировать, представлять и обрабатывать компоненты Java Beans, например, перехватывать события компонента, инициировать методы его служб, создавать страницы свойств для настройки компонентов.
Базовая модель EJB
Базовая структура EJB состоит из пяти частей:
серверы EJB;
контейнеры EJB, которые работают внутри сервера;
объекты типа home, remote, EJBObjects и EJB, которые работают в контейнерах;
клиенты EJB;
вспомогательные службы, например, JNDI, JTS, службы безопасности и т. д.
|
|
|
Сервер EJB обеспечивает среду для выполнения - в ней могут работать контейнеры EJB. Сервер делает EJB-контейнеры видимыми для внешнего мира. Он дополнительно может предоставлять функции, зависящие от поставщика, скажем, интерфейс оптимального доступа к данным, SSL-поддержку, JNDI-доступную службу имен и службу управления транзакциями.
Контейнер EJB - это абстракция, которая управляет одним или более классом EJB, в то же время делая необходимые службы доступными классам EJB через стандартные интерфейсы, как указано в спецификации EJB. Производитель контейнера также может предоставить дополнительный сервис, выполняемый как на уровне контейнера, так и на уровне сервера.
Клиент EJB никогда не имеет прямого доступа к "бину" (bean в аббревиатуре EJB - "боб", или компонент). Любой доступ к bean выполняется посредством методов контейнерно-генерируемых классов, которые в свою очередь вызывают методы этого компонента.
Методы для нахождения, создания и удаления экземпляров классов EJB определяются в home-интерфейсе, реализацией которого выступает home-объект. Разработчик EJB сначала должен определить home-интерфейс для своего bean-компонента. Производитель контейнера EJB предоставляет средства, которые автоматически генерируют код-реализацию для home-интерфейса, определенного разработчиком EJB.
Remote-интерфейс перечисляет бизнес-методы, доступные для EJB. EJBObject - это клиентское представление объекта EJB, реализующее remote-интерфейс. В то время как разработчик EJB определяет remote-интерфейс, производитель контейнера предоставляет средства, позволяющие сгенерировать код для соответствующего объекта EJBObject.
Настоящий объект EJB содержится в контейнере EJB и никогда не должен быть напрямую доступен никому, кроме контейнера. Хотя прямой доступ в принципе возможен, применять его не рекомендуется, так как это разрывает связь ("контракт") между bean и контейнером. Контейнер EJB должен служить связующим звеном между всеми обращениями к EJB. По этой причине разработчик EJB не реализует remote-интерфейс в самом EJB.
Клиенты EJB находят определенный контейнер EJB, который содержит объект EJB, через протокол JNDI (Java Naming and Directory Interface, Java-интерфейс именования и каталогов). Затем они используют контейнер EJB для вызовов методов bean-компонента. Клиент EJB получает ссылку только на экземпляр EJBObject - он никогда в действительности не получает ссылку на текущий экземпляр собственно EJB. Когда клиент вызывает метод, экземпляр EJBObject принимает запрос и перенаправляет его соответствующему экземпляру bean, предоставляя всю необходимую дополнительную функциональность. Клиент использует home-объект для нахождения, создания или разрушения экземпляров EJB. Затем он использует экземпляр EJBObject для вызова бизнес-методов экземпляра bean.
Enterprise beans
Понятно, что одно из основных понятий в Enterprise JavaBeans - компонент EJB, который по сути представляет собой отрезок кода, имеющий поля и методы для реализации каждого модуля бизнес-логики. Они могут быть постоянными или непостоянными.
Разработчику, однако, не нужно самому реализовывать EJB-объект. Этот класс создается специальным кодогенератором, поставляемым вместе в EJB-контейнером. EJB-объект (созданный с помощью сервисов контейнера) и EJB-компонент (созданный разработчиком), реализуют один и тот же интерфейс. В результате, когда приложение-клиент хочет вызвать метод у EJB-компонента, то сначала вызывается аналогичный (по имени) метод у EJB-объекта, что находится на стороне клиента, а тот, в свою очередь, связывается с удаленным EJB-компонентом и вызывает у него этот метод (с теми же аргументами).
Существует два различных типа ``бинов''.
Session bean представляет собой EJB-компонент, связанный с одним клиентом. ``Бины'' этого типа, как правило, имеют ограниченный срок жизни (хотя это и не обязательно), и редко участвуют в транзакциях. В частности, они обычно не восстанавливаются после сбоя сервера. В качестве примера session bean можно взять ``бин'', который живет в Web-сервере и динамически создает HTML-страницы клиенту, при этом следя за тем, какая именно страница загружена у клиента. Когда же пользователь покидает Web-узел, или по истечении некоторого времени, session bean уничтожается. Несмотря на то, что в процессе своей работы, session bean мог сохранять некоторую информацию в базе данных, его предназначение заключается не в отображении состояния или в работе с ``вечными объектами'', а просто в выполнении некоторых функций на стороне сервера от имени одного клиента.
Entity bean, наоборот, представляет собой компонент, работающий с постоянной (persistent) информацией, хранящейся, например, в базе данных. Entity beans ассоциируются с элементами баз данных и могут быть доступны одновременно нескольким пользователям. Так как информация в базе данных является постоянной, то и entity beans живут постоянно, ``выживая'', тем самым, после сбоев сервера (когда сервер восстанавливается после сбоя, он может восстановить ``бин'' из базы данных). Например, entity bean может представлять собой строку какой-нибудь таблицы из базы данных, или даже результат операции SELECT. В объектно-ориентированных базах данных, entity bean может представлять собой отдельный объект, со всеми его методами и свойствами.
Средства защиты EJB
Модель Enterprise JavaBeans использует службы защиты на Java, предусмотренные в Java Development Kit. Средства защиты Java-платформы поддерживают сервисы аутентификации и авторизации, ограничивающие доступ к защищенным объектам и методам.
Кроме того, технология EJB автоматизирует процесс использования средств защиты Java-платформы. Правила защиты для каждого bean определены декларативно в пакете объектов AccessControlEntry в объекте deployment descriptor.
Транзакции
Технология EJB требует распределенной системы управления транзакциями, которая поддерживает протоколы двухфазовой фиксации распределенных транзакций. Спецификация Enterprise JavaBeans предусматривает, но не требует осуществления транзакций, основанных на интерфейсе Java Transaction Service (JTS) API.
JTS представляет собой Java-технологию, связанную с механизмом CORBA Object Transaction Service (OTS). Эта технология поддерживает распределенные транзакции, которые могут охватывать множество баз данных на многочисленных системах, координируемых многими менеджерами транзакций. При использовании JTS сервер Enterprise JavaBeans гарантирует, что его транзакции способны охватить многие серверы Enterprise JavaBeans.
Технология Enterprise JavaBeans значительно упрощает процесс разработки приложений, автоматизируя использование распределенных транзакций. Все функции транзакций могут выполняться непосредственно EJB-контейнером и EJB-сервером. Отдельным beans не обязательно создавать операторы разграничения транзакций, включая их в код. И поскольку код транзакций требуется для логики приложений, beans проще писать и переносить посредством различных менеджеров транзакций.
EJB имеет следующие положительные и отрицательные стороны:
Достоинства
Быстрое и простое создание
Java-оптимизация
Кроссплатформенность
Динамическая загрузка компонент-переходников
Возможность передачи объектов по значению
Встроенная безопасность
Недостатки
Поддержка только одного языка - Java
Трудность интегрирования с существующими приложениями
Плохая масштабируемость
Производительность
Отсутствие международной стандартизации
Благодаря своей легко используемой Java-модели, EJB является самым простым и самым быстрым способом создания распределенных систем. EJB - хороший выбор для создания RAD-компонент и небольших приложений на языке Java.