Со структурной точки зрения компонент EJB состоит из главного класса Java, часто называемого классом реализации или классом компонента, и двух интерфейсов: местного (Ноте) и удаленного (Remote). В компонентах-сущностях (они рассматриваются в главе 13), есть также класс первичного ключа. Отношения между этими элементами, а также базовые объекты J2EE, которые ими расширяются и реализуются, и определяют конкретные функциональные возможности EJB и его пригодность как компонента J2EE.
Во всех компонентах EJB используются описатели развертывания, которые хранят дополнительную информацию о компоненте. Сюда относятся параметры настройки для деловых методов, для типа компонента, для безопасности и т.д.
Компоненты EJB развертываются в контейнерах EJB с помощью утилиты развертывания. Контейнеры EJB располагаются на сервере EJB. Сервер EJB часто носит название сервера приложения уровня предприятия или просто сервера приложения. Конкретные возможности и уровень совместимости сервера EJB определяют, с какой версией спецификации EJB следует работать.
Представление компонентов EnterpriseJavaBeans в UML
Если учесть широту охвата UML, неудивительно, что существует, по-видимому, несколько потенциальных способов изображения EJB в языке UML. В первую очередь для этого кажутся подходящими две конструкции UML: класс и компонент.
Класс UML можно почти сразу отвергнуть, так как он, в отличие от EJB, описывает небольшие объекты. Кроме того, класс сам по себе не позволяет выразить специфические особенности EJB и требует привлечения дополнительных средств моделирования (таких как пакеты).
Можно, конечно, слить воедино элементы, составляющие компонент EJB, и представить его как один класс UML, как показано, например, на рис. 12.1. В таком случае класс должен иметь несколько отсеков, в каждом из которых содержится информация по отдельному аспекту EJB.
Казалось бы, такой подход дает более компактную модель EJB, но сложное изображение класса с несколькими отсеками может затруднить понимание такого представления и повысить вероятность ошибки. Кроме того, такая форма дает клиенту компонента гораздо больше информации, чем необходимо или желательно.
Аналогично, хотя в UML есть понятие компонента, это не совсем то же самое, что и компонент EJB. Компонент UML ближе связан с реализацией; он представляет физический артефакт, например файл исходного текста. Кроме того, компоненты UML, как правило, не моделируются на этапе анализа и проектирования. *
Еще один способ* состоит в комбинировании возможностей класса (точнее, классификатора) и пакета. Этот способ — моделирование посредством подсистемы. Как было сказано в главе 4, подсистема в общем случае представляет собой группу элементов UML, образующих модуль поведения в составе модели. Она может иметь интерфейсы и операции. Подсистемы, в отличие от компонентов, допускают работу на этапе анализа и проектирования и не имеют обычного для классов недостатка "мелкомодульности".
Имея надежное обоснование возможности применения подсистем для представления EJB, учитывая их преимущества, а также ввиду того, что такой подход уже фактически стал стандартом, мы выбрали в данной книге именно этот способ моделирования компонентов EJB.
Лучше всего оценить компоненты EJB можно с разных точек зрения, присущих определенным ролям (например, пользователю, разработчику и т.д.)- Рассмотрим эти разные представления EJB. После этого мы изучим сеансовые компоненты и особенности технологии, чтобы конкретизировать эти представления.
Клиентское представление
Клиентское представление EJB состоит из элементов, к которым может обращаться клиент, и включает местный и удаленный интерфейсы. На диаграмме классов UML клиентское представление EJB изображается подсистемой UML (обоснование см. в предыдущем разделе).
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.