Rambler's Top100IT • archiv

rus / eng | Логин | Комментарий к колонке | Печать | Почта | Клуб




Колонки


Enterprise JavaBeans. Часть 1

 
(Гопалан Суреш Рай)
Создание распределённых приложений масштаба предприятия всегда представляло собой серьёзную задачу. Но выполнение такой задачи, сравнимой разве что с подвигами Геркулеса, в настоящее время упрощается благодаря постоянному развитию комнонентных технологий программирования. Например, дальнейшее внедрение компонентных технологий позволяет создавать сложнейшие приложения, используя широкий спектр независимых друг от друга модулей. Это не просто помогает поставить процесс разработки приложений на поточную основу, но одновременно даёт возможность работать над повышением качества самих модулей.

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

И всё же, технологии типа Java, целью которых является создание компонентов "написанных однажды и работающих везде", значительно облегчают процесс решения проблем, связанных с разработкой распределённых приложений промышленного масштаба. В данной главе Вы познакомитесь с основополагающими концепциями и архитектурой технологии серверных компонентов - Enterprise JavaBeans (EJBs) - и примерами их реализации в программных решениях.

Основные положения - Надёжные технологии

Прежде чем приступить к изучению технологии EJBs, Вам следует понять, что из себя представляют сами приложения масштаба предприятия и для чего они нужны. И хотя дать очень подробное описание будет достаточно сложно, мы всё же детально изучим наиболее важные концепции.

Что такое транзакция?

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

Транзакции представляют собой способ объединения нескольких операций в атомарный выполнимый модуль.

Данная атомарность (можно сказать, в принципе, и взаимозависимость) является неотемлемой частью нашей повседневной жизни. К примеру, священник во время проведения церемонии бракосочетания сначала спрашивает жениха и невесту: "Хочешь ли ты взять себе в супруги этого человека?" Только после того, как и тот и другая ответят "Да", священик может сказать: "Объявляю вас мужем и женой." и таким образом зафиксировать переход из одного состояния в другое. Другими словами, в рамках транзакции несколько независимых друг от друга участников сделки должны прийти к общему для всех соглашению, прежде чем сделка будет заключена. Если одна из сторон будет против, каждый из участников остаётся при своих. В терминологии транзакций такое явление называется операцией возврата в исходное состояние (rollover operation).

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

Четыре источника - четыре составных части

Все транзакции должны обладать следующими четырьмя свойствами:

Атомарность (Atomicity):Транзакция либо фиксирует результат своей операции, либо возвращает всё на место. Если транзакция выполняется успешно, результат транзакции фиксируется. Если по какой-то причине транзакция не удалась, объекты, над которыми осуществлялась операция, возвращаются в исходное состояние. Например, при переименовании объекта должно призойти стирание старого имени и установка нового, или имя объекта должно остаться неизменным.

Согласованность (Consistency):Транзакция вызывает корректную трансформацию системы при этом сохраняя её состояние. Например, в рамках транзактного добавления одного элемента в двусвязный список, все четыре указателя в ту и в другую сторону обновляются одновременно.

Изолированность (Isolation): Выполняющиеся одновременно транзакции изолированы от воздействия не завершившихся транзакций. Данная характеристика также именуется как сериализуемость (serializability). Например, транзакция, проходящая через двусвязный список, который в это время подвергается изменению предыдущей транзакцией, будет видеть только те изменения, которые уже осуществились до её инициализации. Изменения же, осуществляемые предыдущей транзакцией, после запуска этой транзакции, уже никак не могут повлиять на неё.

Устойчивость (Durability):Если транзакция завершилась успешно, её результат будет зафиксирован и сохранён. Более того, в этом случае результат сохранится даже в случае опасности возникновения сбоя системы.

В задачу приложения входит определять последовательность и согласованность транзакций и принимать меры для фиксации результатов трансформации. А задача менеджеров транзактных ресурсов заключается в том, чтобы обеспечить правильное согласованное обновление объектов, которыми они управляют, и сохранение этих трансформаций. Если транзакции распределены между различными машинами, то для обеспечения атомарности и надёжности процесса используется двухфазный протокол фиксации транзакций (two-phase commit protocol).

JavaTransactionService

В качестве координатора транзакций в рамках архитектуры EJB используется Java Transaction Service (JTS). В терминологии JTS этот координатор именуется как менеджер транзакций (transaction manager). Участники транзакции, реализующие транзактно-защищённые ресурсы типа релятивных баз данных, называются менеджерами ресурсов (resource managers). Когда приложение инициирует транзакцию, оно создаёт объект, который представляет эту транзакцию. Затем приложение обращается к менеджерам ресурсов, которые должны осуществить операцию. В процессе выполнения транзакции каждый из менеджеров транзакций отслеживает работу каждого из указанных в транзакции менеджеров ресурсов.

Первое обращение приложения к каждому из менеджеров ресурсов определяет текущую транзакцию. Например, если приложение использует релятивную базу данных, оно вызывает интерфейс JDBC (Java Database Connectivity), который связывает транзактный объект с базой данных. С этого момента все вызовы, осуществляющиеся через это соединение, будут выполняться от лица транзакции самой базы данных, до тех пор пока транзакция не завершится.

Приложение фиксирует результат транзакции путём вызова метода xa_commit()и сообщает, что транзакция была успешно завершена. Если же по какой-либо причине приложение не может завершить транзакцию, оно вызывает метод xa_rollback(), отменяющий те изменения, которые были произведены. В случае, если приложение не в состоянии выполнить транзакцию, JTS снимает задачу. Когда транзактная операция завершается успешно, приложение обращается к JTS, чтобы сохранить результат. Затем JTS проходит через двухфазный протокол фиксации транзакций, чтобы передать задание указанным в транзакции менеджерам ресурсов.

Двухфазное фиксирование транзакций

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

Что такое Naming Service?

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

Служба имён (naming service) это специальная функция программного обеспечения, которая управляет системой наименования или namespace. Служба имен реализована как самостоятельный процесс, не зависящий от компъютерной системы, в которой она используется. Другими словами, эта служба обеспечивает функцию, которая связывает имена с конкретными данными или объектами - систему наименования, но которая при этом остаётся независимой и может работать в любой из систем, которые понимают её протокол и могут к ней подключиться.

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

Интерфейс Java Naming and Directory Interface

Интерфейс Java Naming and Directory Interface (JNDI), изображённый на рисунке 1, это клиентский API, который обеспечивает функции управления и наименования. JNDI был создан для обеспечения абстракций, представляющих наиболее общие для клиентов служб имен и управления элементы. JNDI не задумывался как альтернатива существующим системам наименования и управления. Наоборот, он создан для обеспечения стандартного интерфейса для доступа к общепринятым системам типа DNS, NDS, LDAP, CORBA или RMI.

Рисунок 1: Java Naming and Directory Interface

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

JavaBeans- базовая компонентная модель

Компонентная модель (component model) определяет среду, которая поддерживает многоразовые компоненты для приложений. В Java в качестве базовой компонентной модели принята технология JavaBeans, созданная для соединения воедино конструктивных элементов, как в конструкторе Lego, и построения из них аплетов и приложений. На сегодняшний день разработаны сотни компонентов JavaBeans и большое количество инструментальных средств, поддерживающих их работу.

Любой объект, подчиняющийся определённым требованиям, перчисленным в JavaBeans API, может считаться компонентом JavaBean, в дальнейшем - "бин". Кроме того, такой JavaBean помимо наличия в нем конструктора и способности к сериализации может экспортировать свойства (properties), события (events) и методы (methods). Свойства отражают внутреннее состояние бина и ими можно манипулировать с помощью методов get и set (getter/setter methods). Бин также способен генерировать события в соответствии с правилами Java 1.1 Delegation Event Model. Бин определяет события с помощью соответствующих методов для добавления и удаления слушателей (listener objects), расположенный в списке заинтересованных в этом событии слушателей. Методы бина могут быть как открытыми (public methods), которые видны пользователю (сюда правда не входят getter/setter methods) и с помощью которых можно изменять значения свойств, так и методами для регистрации и удаления слушателей событий.

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

Бин также может содержать класс BeanInfo, который предоставляет дополнительную информацию о самом бине в виде объектов FeatureDescriptor (описание свойств) для каждой из имеющихся характеристик бина. Если бин имеет достаточно сложный тип свойств, ему возможно понадобится класс PropertyEditor, позволяющий пользователю устанавливать свои значения для этого свойства. Бин так же может иметь класс Customizer, предназначенный для создания пользовательского GUI для настройки бина.

Note

Аббревиатура EJB используется для обозначения и компонента и архитектуры. Здесь на лицо некоторое смешение понятий, так как в спецификации EJB используется как аббревиатура для компонента Enterprise JavaBean и в тоже самое время как аббревиатура для архитектуры Enterprise JavaBeans.

Упакованный компонент EJB можно определить по наличию следующих элементов:

1. a. home-интерфейс - очевидно
b. home-объект - очевидно

2. a. remote-интерфейс - очевидно
b. Объект EJB - имплементация remote-интерфейса, который в целях простоты называется EJBObject.

3. Непосредственно имплементация бина - это код реализации бизнесс-логики. Здесь это будет называться Enterprise Bean.

4. Описание его установки и применения.

Компонент EJB определяется как комбинация трёх составных элементов и описания его установки и применения. Вы можете изменить любой из этих элементов и создать новый EJB (например, на многих серверах такие компоненты могут отличаться друг от друга только remote-интерфейсами, или классом реализации, или способом установки и применения и т.д.) В свете этого, описание является очень важным, так как оно определяет назначение этого EJB.

EnterpriseJavaBeans- компоненты для сервера

Технология Enterprise Java Beans (EJB) является высокоуровневым подходом к построению распределенных систем. Она предоставляет разработчику возможность полностью сконцентрировать своё внимание на программировании логики, вместо того чтобы корпеть над кодом. Например, разработчик большого приложения масштаба предприятия теперь не обязан больше писать код для обработки транзактного поведения, осуществления защиты информации, сведения связей или обработки нитей, так как данная архитектура предполагает, что это теперь должно входить в обязанности производителя сервера.

Текущая версия EJB имеет некоторое отношение к технологии JavaBeans. Само название "Enterprise JavaBeans," тем не менее, предполагает, что между ними должна существовать определённая связь, которая пока не очень просматривается. В принципе, компоненты JavaBeans используются практически так же как компоненты Microsoft ActiveX (для обеспечения понятных для пользователя средств управления для построения пользовательских интерфейсов), в то время как компоненты EJB применяются для реализации транзактного обеспечения и являются невизуальными. Кроме того, EJB не имеет таких вещей как классы BeanInfo, редакторы свойств или средства настройки.

В сущности, EJB - это модель серверных компонентов (server component model)для Java и одновременно спецификация для создания больших, масштабируемых, транзактных, приложений для промышленных серверов, обеспечивающих высокий уровень защиты данных. Но что ещё более важно, так это то, что компоненты EJB могут внедряться в уже существующие системы обработки транзакций, на Web-серверах, серверах приложений и т.п.

Зачем нужны EJB?

В приложениях типа Visual Basic от Microsoft существует окно настройки свойств - property window, использующееся для настройки частей приложения, не прибегая к кодированию. Похожее окно - data window - существует в PowerBuilder от Sybase, которое позволяет без ручного кодирования программировать доступ к данным приложений баз данных. EJB также придерживается подобной концепции построения приложений масштаба предприятия. Теперь наличие компонентов EJB позволяет пользователю сфокусироваться только на разработке бизнес-логики приложения.

В условиях многоуровневой архитектуры вопрос, где располагается бизнес-логика, играет не самую важную роль. Хотя в традиционной трёхуровневой архитектуре бизнес-логика обычно размещается в среднем уровне. Тем не менее, при использовании EJB Вы можете поместить свою бизнес-логику в любую удобную для Вас часть приложения, при необходимости добавляя дополнительные уровни. Компоненты EJB, содержащие бизнес-логику, платформенно-независимы и поэтому могут легко мигрировать при необходимости на другие более развитые платформы. Если на Вашей машине установлено необходимое для выполнения сложной задачи приложение и Вам нужно переместить свои компоненты EJB с одной платформы на другую, Вы можете сделать это, не меняя ни одной точки в коде бизнес-логики. Наиболее важной посылкой спецификации EJB является поддержка уже существующих компонентов. Это даёт вам возможность брать и применять созданные кем-то компоненты EJB без необходимости иметь специальные знания об особенностях их работы.

Самыми главными преимуществами работы с EJB для построения программных решений являются

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

Универсальные серверные компоненты -Так как в основу EJB положена технология Java, и разработчик и пользователь гарантированы, что написанные ими однажды компоненты будут работать везде. И до тех пор пока сервер EJB будет отвечать требованиями спецификации EJB, компоненты EJB, независимо от их производителя, будут работать на этом сервере.

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

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

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

EJB помогает создавать переносимые и масштабируемые решения - Компоненты EJB, подчиняющиеся требованиям EJB API, устанавливаются, выполняются и переносятся на любой сервер EJB.

EJB легко интегрируются с CORBA- EJB и CORBA естественным образом дополняют друг друга. Например, компоненты могут представлять CORBA/IIOP для обеспечения надёжного механизма передачи, или простые клиенты CORBA могут обращаться к компонентам EJB как клиенты EJB. В настоящее время широкий спектр функций может предложить разработчикам CORBAServices производства компании OMG. В будущем производители серверов EJB, возможно, смогут просто заворачивать эти функции в упрощённые API, чтобы ими могли пользоваться разработчики EJB без необходимости быть знатоками CORBA.

EJB не ограничивает производителя - Благодаря тому, что спецификация EJB предоставляет производителям определённую свободу и гибкость в процессе разработки, среда выполнения EJB может развиваться до бесконечности.

Различия между JavaBeans и Enterprise JavaBeans

В Таблице 1 приведены сравнительные характеристики компонентов JavaBean и Enterprise JavaBean.

JavaBeans

Enterprise JavaBeans

JavaBean во время выполнения может быть визуальным или невизуальным. Например, визуальными компонентами GUI могут быть кнопки, списки, графики, рисунки.

Компонент EJB - невизуальный, удалённо выполняемый объект.

JavaBean предназначен для выполнения одного процесса и изначально создаётся для работы на клиенте. Хотя можно создать и серверный JavaBean, гораздо легче это сделать пользуясь спецификацией EJB.

EJB это удалённо выполняемый компонент и бизнес-объект, который может устанавливаться только на сервере.

JavaBeans это компонентная технология производства стандартных Java-компонентов, из которых можно конструировать аплеты и приложения.

И хотя EJB это компонентная технология, она не основывается и не расширяет существующую спецификацию JavaBeans.

JavaBean имеет внешний интерфейс - Properties interface, позволяющий средству разработки интерпретировать функциональность этого бина.

EJB имеет описание установки и применения, определяющее его функции для внешнего средства разработки или интегрированной среды разработки (IDE).

JavaBean может иметь классы BeanInfo, редакторы свойств или средства настройки.

EJB не имеют классов BeanInfo, редакторов свойств или средств настройки и не предоставляют никакой дополнительной информации кроме описания установки и применения.

JavaBean не подразделяются по типам.

EJB могут быть двух типов - session-бины и entity-бины.

В JavaBean нет явной поддержки транзакций.

EJB могут быть транзактными, а серверы EJB обеспечивают поддержку транзакций.

Для JavaBeans существуют компонентные мосты. Например, любой JavaBean может использоваться и как компонент ActiveX.

EJB не может использоваться как компонент ActiveX, так как компоненты ActiveX предназначаются для выполнения на ПК, а EJB для работы на сервере. Тем не менее, для обеспечения совместимости CORBA-IIOP используется процесс преобразования EJB-to-CORBA, разработанный OMG.

Таблица 1: Различия между компонентами JavaBeans и Enterprise JavaBeans

TOC | Часть 2 >




Справка | Условия Copyright © 1999 — 2008, IT • archiv.
В начало | Логин | Комментарий к колонке | Поиск | Почта