Если удаленные вызовы обходятся так дорого, нет ли способа избежать их, чтобы повысить производительность приложения?
Основное правило, которому надо следовать, состоит в том, чтобы количество вызовов EJB было как можно меньше. Например, если сеансовый компонент сеанса имеет три разных задания, которые он должен выполнять при обработке запроса от сервлета, все эти задания должны выполняться в одном вызове делового метода сеансового компонента. Часто это означает, что такой деловой метод состоит лишь из обращений к трем другим методам. В результате количество необходимых удаленных вызовов уменьшается на два.
Сократить число удаленных вызовов можно также с помощью технологии JavaBeans, как описано выше.
Кроме того, на разных серверах приложений есть несколько различных механизмов предварительного выделения и группирования ресурсов, тонкой настройки и распределения нагрузки, которые дают другие пути повышения производительности приложения.
Локальный клиент
До этого момента мы предполагали, что клиент всегда является удаленным. В версии J2EE 1.3 появилась концепция локального клиента для сеансовых компонентов и компонентов-сущностей.
Локальный клиент призван повысить производительность системы в тех случаях, когда известно, что требуемые компоненты EJB находятся на той же виртуальной машине Java (т.е. локальны). При переходе от удаленного клиента к локальному наблюдаются следующие изменения.
· Удаленный клиент становится локальным клиентом.
· Удаленный интерфейс становится локальным интерфейсом.
· Местный интерфейс становится локальным местным интерфейсом.
· Объекты, реализующие эти два интерфейса, должны быть локальными для клиента объектами Java.
· Параметры и результаты всех методов этих интерфейсов теперь передаются по ссылке, а не по значению.
Выбор схемы реализации с локальным клиентом потенциально ограничивает возможность распределить обработку частей приложения на несколько серверов. В большинстве случаев этот недостаток с лихвой компенсируется приростом производительности, который дает такой подход. Применение локального клиента может быть хорошей отправной точкой в развитии приложения. В то же время целесообразно сохранять минимальным количество обращений к локальным компонентам EJB, предвидя тот момент, когда их понадобится преобразовать в удаленные компоненты EJB.
Применение локального клиента рекомендуется также для большинства ситуаций, в которых присутствуют отношения между компонентами EJB. Но в случаях, когда целевые EJB находятся в разных архивах Java, или для связи с реализацией на другом языке требуется другой транспортный механизм, локальные клиенты не следует применять.
На момент написания этой книги технология локального клиента еще не была доработана. Но, как ожидается, эта новая возможность будет введена в окончательную версию спецификации J2EE 1.3.
Определение сеансовых компонентов в приложениях масштаба предприятия
В предыдущей главе мы разделили объект управления на сервлеты, обслуживающие внешние задачи, и внутренний объект управления, который отвечает за логику приложения и взаимодействие с объектами-сущностями.
Исходя из всего сказанного выше, можно заключить, что сеансовые компоненты идеально подходят для выполнения обязанностей внутреннего объекта управления.
В контексте сценария перевода денег, с которым мы работали раньше, для использования сеансового компонента в роли внутреннего объекта управления остается разрешить еще несколько вопросов.
· Отвечает ли сеансовый компонент за одиночное действие, т.е. за перевод денег, или у него есть и другие обязанности?
· Должен ли этот сеансовый компонент поддерживать состояния?
· Какие транзакции он имеет?
· Будут ли задействованы транзакции, управляемые компонентом или транзакции,управляемые контейнером?
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.