Enterprise JavaBeans (EJB) - это управляемый компонент, принадлежащий стороне сервера для модульного конструирования промышленного приложения [7].

Итак, начнем наш тур по Enterprise JavaBeans путем исследования значения этих слов.

"Компонент" - означает, что EJB распространяются в бинарном формате и могут настраиваться, так что клиентский программист может использовать их для создания собственного приложения. Эта та же самая концепция, которую мы видели в графических компонентах JavaBean: вы покупаете компонент JavaBean для создания части графической круговой диаграммы, вы встраиваете его в ваше приложение (обычно при использовании RAD инструмента, такого как JBuilder), вы настраиваете параметры компонента по своему желанию (например, цвет фона), и вы используете его в вашем приложении, создающем отчеты. У вас нет исходного кода для компоненты круговой диаграммы, тем не менее, вы можете подстроить его в соответствии со своими нуждами. Способ, которым вы внедряете, настраиваете и используете Enterprise JavaBeans, не похож на то, как вы работаете с обычным JavaBeans, но концепция сущности компонента та же самая. Это важно для создания терминологического различия между компонентами и экземплярами: мы используем термин Enterprise JavaBeans для указания типа компонента - например EJB, представляющий банковский счет; и мы используем термин "экземпляр EJB" для указания на объект, который представляет специфический банковский счет с уникальным номером счета.

"Сторона сервера" означает, что объект EJB размещается в процессе на том же сервере, а не на клиентской машине. EBJ может предлагать удаленный просмотр, локальный просмотр или оба. Термин "просмотр" не относится к графическому просмотру; здесь мы говорим о способе, которым EJB предоставляет свой интерфейс. Если EJB представляет удаленный просмотр, все вызовы методов между клиентским кодом и удаленным экземпляром происходят через протокол удаленного вызова процедур, такого как RMI-IIOP. Если EJB представляет локальный просмотр, клиентский код должен быть в том же процессе, что и EJB объект, а все вызовы являются прямыми вызовами методов.

Как вы видели в Главе 16, способность выполнять удаленный вызов процедур подразумевает присутствие двух фундаментальных частей архитектуры: именованные службы и RPC прокси. Именованные службы - это сетевые службы, которые клиентский программист использует для нахождения гетерогенных ресурсов сети. RPC прокси - это программно сгенерированный Java класс, созданный на клиентской стороне, который представляет тот же самый интерфейс, что и специфичный удаленный компонент. Так как он предоставляет тот же интерфейс, клиенты не могут общаться один с другим, а прокси может претендовать на роль удаленного экземпляра. Но поскольку это прокси, он делегирует все вызовы удаленному компоненту, реализующему сетевой код и прячущий все сложность от клиента. В EJB мы имеем аналогичную концепцию именованных служб и RPC прокси, но они слегка отличаются от того, что мы видели с Java Remote Method Invocation (RMI).

И последнее, и наиболее важное, EJB могут управляться. Это означает, что когда объект EJB активен в памяти, ведущий его процесс делает с ним немого больше, чем то, что обычно делает JVM. Процесс, обслуживающий EJB, вызывается EJB контейнером и является стандартизированной средой времени выполнения, которая предоставляет управляющую функциональность. Так как спецификация EJB стандартизирует службы, предоставляемые EJB контейнером, мы имеем поставщика, реализующего эту функциональность в коммерческих продуктах, таких как WebSphere и WebLogic, два наиболее известных коммерческих EJB контейнера от IBM и BEA Systems, соответственно. В EJB контейнере службы, такие как удаленные объекты и нейтралитет клиентского протокола, неявно используют JAVA RMI; другие службы (перечисленные ниже) являются стандартными. Такие службы, как кластеризация и поддержка при поломках, являются дополнительными и предлагаются определенными поставщиками.

Вот службы, предоставляемые всеми контейнерами EJB:

  • Постоянство Объекта
  • Декларативный Контроль Безопасности
  • Декларативный Контроль Транзакций
  • Управление Конкурированием (Параллельностью)
  • Управление Масштабированием

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

Декларативный Контроль Безопасности дает вам возможность позволить Контейнеру проверять, что клиент, вызывающий определенный метод для некоторого EJB, был авторизован и принадлежит к роли, которую вы ожидаете; если это не так, будет сгенерировано исключение и метод не будет выполнен. Выгода от декларативного контроля безопасности в том, что вам не нужен код для любой логики безопасности в вашем EJB - вы просто определяете роли и "говорите" контейнеру каким ролям позволяется вызывать какие методы. Так как нет жестко закодированной логики безопасности в вашем EJB, легко произвести изменения в соответствии с требованиями безопасности без перекомпиляции.

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

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

Управление конкурированием синхронизирует параллельные вызов методов, приходящие от различных удаленных клиентов, и направляет их к одному и тому же EJB объекту. На практике, это гарантирует, что компонент может быть безопасно использован в наследуемой многопоточной среде сервера приложений (довольно полезное свойство).

Управлению масштабируемостью адресуется проблема увеличения выделяемых ресурсов, которая возникает при увеличении количества одновременно работающих клиентов. Ресурсы выделяются для клиента, а не для EJB объектов, есть такие поддерживаемые ресурсы, как соединения с базой данных, нити (threads), сокеты, очередь сообщений и так далее. Например, если число одновременно работающих клиентов увеличивается от 100 до 1000, вы можете получить 1000 EJB объектов в памяти, которые могут открыть 1000 соединения с базой данных; это может быть слишком много для количества имеющейся у вас памяти, и это определенно слишком тяжелая нагрузка на ваш сервер базы данных. EJB Контейнер может решить заняться этой проблемой, предоставив объединенные (pooling) экземпляры EJB и объединенные (pooling) соединения с базой данных. Таким образом, Контейнер будет хранить только ограниченное количество экземпляров или соединений, живущих в памяти, и будет присваивать им различных клиентов только во время, когда клиент действительно будет нуждаться в этом.

← Использование Библиотек Тэга от Третьих Производителей Красота Enterprise JavaBean →