Думай на Java

       

Enterprise JavaBeans


Предположим, [77] вам нужно разработать многоярусное приложение для просмотра и обновления записей в базе данных через Web интерфейс. Вы можете написать приложение для баз данных, используя JDBC, а Web интерфейс использует JSP/сервлеты, а распределенная система использует CORBA/RMI. Но какие дополнительные соображения вы должны принять во внимание при разработке системы распределенных объектов кроме уже известного API? Вот основные соображения:

Производительность: Распределенные объекты, которые вы создаете, должны хорошо работать, так как потенциально они должны обслуживать много клиентов одновременно. Вам надо использовать оптимизационные технологии, такие как кеширование и объединение таких ресурсов, как соединение с базой данных. Вам также понадобится управлять продолжительностью жизни ваших распределенных объектов.

Масштабируемость: распределенные объекты должны быть масштабируемыми. Масштабируемость в распределенных приложениях означает, что число экземпляров ваших распределенных объектов может увеличиваться и они могут перемещаться на дополнительные машины без изменения какого-либо кода.

Безопасность: Распределенный объект часто должен управлять авторизацией доступа клиента. В идеале вы добавляете новых пользователей и политики без перекомпиляции.

Распределенные Транзакции: Распределенные объекты должны быть способны прозрачно ссылаться на распределенные транзакции. Например, если вы работаете с двумя разными базами данных, вы должны быть способны обновить их одновременно в одной трензакции и отменить изменения, если не был выполнен определенный критерий.

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

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

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

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



Содержание раздела