Отношения между сеансовым компонентом и JSP в основном подобны отношениям с сервлетом. Пример таких отношений показан на рис. 12.17.
Но, несмотря на то, что компоненты JSP при компилировании преобразуются в серв-леты, в общем предпочтительно применять JSP лишь для аспектов представления и не включать в них такой объем логики, как это делается в сервлетах. Один из возможных вариантов — обращаться из JSP к сервлету, который будет выполнять задачи взаимодействия с сеансовыми компонентами и/или компонентами-сущностями.
Отношения между сеансами
Сеансовому компоненту для выполнения своих обязанностей может быть необходимо взаимодействовать с другими сеансовыми компонентами. Например, компонент с поддержкой состояний может обслуживать сеанс размещения заказа у субподрядчика, и тогда ему потребуется взаимодействовать с сеансовым компонентом без состояний для получения разрешения на принятие заказа.
Другой пример представляет возможная реализация сеанса электронной покупки. Сеанс пользователя может обслуживаться сеансовым компонентом, который имеет взаимно однозначное отношение с компонентом тележки для товаров.
Такие отношения моделируются как ассоциации или зависимости между сеансовыми компонентами. Если сеансовый компонент должен долгое время, т.е. в интервале от одного делового метода до другого, хранить информацию о другом компоненте, оптимально будет использовать ассоциацию. В иных случаях для моделирования достаточно зависимости.
Использование межсеансовых отношений такого рода иногда называется построением цепочек сеансовых компонентов. Целесообразно строить цепочки из одного компонента с поддержкой состояний и нескольких компонентов без состояний; но при соединении в цепочку нескольких компонентов с поддержкой состояний надо соблюдать осторожность. Может потребоваться много усилий и времени, чтобы привести такую цепочку в нужное состояние, например, при восстановлении после отказа.
На рис. 12.18 показан пример отношения между сеансовыми компонентами.
|
|
Наследование сеансовых компонентов
В текущей версии спецификации EJB не определен механизм наследования компонентов. Иначе говоря, невозможно сразу создать подкласс всего компонента EJB, в котором можно было бы использовать как интерфейсы, так и класс реализации. Хотя некоторые производители серверов поддерживают такое наследование, им нужно пользоваться с осторожностью, если к системе предъявляются требования переносимости.
Пока рекомендуется создавать подклассы местного и удаленного интерфейсов и класса реализации по отдельности и уже затем формировать из них новый сеансовый компонент.
Управление производительностью
Решение применять в программной системе предприятия компоненты EJB дает много преимуществ, описанных выше. Однако, используя EJB, никогда не следует упускать из виду такой аспект, как влияние этих компонентов на общую производительность приложения.
Эффективное разделение интерфейса и реализации в EJB достигается, как правило, за счет использования технологии RMI (Remote Method Invocation — удаленный вызов метода). Это упрощает разработку распределенных приложений и позволяет распределить рабочую нагрузку EJB на любое количество разных машин. Например, в приложении экземпляр сеансового компонента EJB может выполняться на одной машине, а объекты-сущности и базы данных могут находиться на других. Используя EJB с этой автоматически встроенной возможностью удаленной работы, разработчик даже не обязан знать, как в конечном счете распределятся компоненты после развертывания.
Однако эта схема имеет и свой недостаток: удаленный вызов всегда требует больше времени и ресурсов по сравнению с обращением к локальному объекту. В версии J2EE 1.2 для удаленного обращения нет никаких альтернатив. Но в J2EE 1.3, как ожидается, будет поддерживаться концепция локального клиента. Этот вариант мы рассмотрим ниже в разделе "Локальный клиент".
Сокращение удаленных вызовов
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.
