Сервер приложений & JavaBeans
Михаил Фленов
Современная альтернатива клиент-серверной технологии
Использование серверов приложений - следующий шаг за клиент-серверной технологией, позволяющий повысить доступность и надежность информационной системы предприятия. Но мне кажется, что самым важным преимуществом сервера приложений является его большая гибкость, что очень ценно для крупных предприятий. Способность компании максимально быстро реагировать на изменение состояния рынка и окружающей среды позволяет ей оставаться конкурентоспособной.
Использование серверов приложений—следующий шаг за клиент-серверной технологией, позволяющий повысить доступность и надежность информационной системы предприятия. Но мне кажется, что самым важным преимуществом сервера приложений является его большая гибкость, что очень ценно для крупных предприятий. Способность предприятия максимально быстро реагировать на изменение состояния рынка и окружающей среды позволяет ему оставаться конкурентоспособным.
Классика: клиент-сервер
Классическая архитектура доступа к данным клиент-сервер состоит из двух уровней —уровня представления и уровня данных. Клиент направляет серверу запросы, а сервер отвечает на них: возвращает необходимые данные или производит запрашиваемые изменения над данными. В данной архитектуре сервер отвечает за хранение данных и через хранимые процедуры выполняет некоторые действия. Вся остальная нагрузка (логика приложения и отображение данных) ложится на клиентское приложение.
Самое страшное в данной технологии то, что бизнес-логика ложится на плечи клиента, а это ведет к следующим недостаткам:
1. При изменении логики работы придется обновлять все клиентские приложения, что не очень-то удобно и ведет к большим издержкам;
2. Возрастают требования к клиентскому компьютеру. Да, производителей ОС и компьютерного железа это вполне устраивает, но даже крупному предприятию подобные расходы ни к чему.
Если вынести логику работы приложения на сервер, то за клиентским компьютером остается только функция представления данных, а с этой задачей справится и простая клиентская машина или тонкий клиент. Это серьезная экономия денег на обновлении клиентского парка компьютеров и ОС: ведь вам уже не нужна операционная система с большим количеством функций, а чем она проще, тем меньше будет содержать ошибок.
Уже наверно лет 15 идут разговоры о том, что необходимо освобождать клиентские машины и максимально использовать возможности серверов. В связи с этим стали появляться многоуровневые системы клиент-сервер, где клиентские программы направляют запросы промежуточному ПО, которое и выполняет функции бизнес-логики.
Сервер приложений
В процессе создания концепции сервера приложений ничего нового не придумывали, просто улучшили уже существующую схему многоуровневой системы (точнее—трехуровневой). Сервер приложения становится промежуточным слоем между клиентом и сервером.
Такая схема позволяет получить следующие преимущества:
1. Клиентской программе абсолютно не нужно знать, как и в какой базе данных (БД) хранится информация. Для получения необходимых данных клиент вызывает функции сервера приложений, а тот уже получает данные от сервера БД. Каким способом сервер приложений реализует функцию, никого не волнует. А где преимущество? Допустим, что нужно изменить структуру таблиц. Вносим изменения, меняем реализацию функции на сервере приложений, а клиентские приложения продолжают работать, не подозревая, что структура уже иная;
2. Бизнес-логика хранится на сервере приложений. Если нужно внести поправки в алгоритм какого-то отчета или расчета, например заработной платы, не требуется менять функции клиентских приложений, надо изменить один сервер приложений;
3. Уменьшается нагрузка на клиентские компьютеры;
4. Сервер приложения распределяет нагрузку и обеспечивает защиту от сбоев.
Можно продолжать этот список дальше, но, на наш взгляд, эти пункты наиболее важные и достаточные для того, чтобы обратить внимание на серверы приложений. Ну а обратив внимание, вы увидите, что здесь сокрыто будущее.
Компонентный посредник
Серверы приложений относят к приложениям промежуточного слоя (middleware). Существует несколько категорий продуктов промежуточного слоя:
1. Message orientated (яркие представители — MQseries и JMS);
2. Object Broker (пример—CORBA и DCOM);
3. Component based — наиболее перспективная категория, на мой взгляд, и это подтверждают известные представители данной категории .NET и EJB.
В данной статье мы будем рассматривать последнюю категорию на примере EJB (Enterprise JavaBeans) как законодателя моды. Недаром данная технология долгое время не давала спать одному очень знаменитому софтверному гиганту, и ему пришлось в срочном порядке создавать свою реализацию.
JavaBeans предоставляет нам набор инструментов (Framework), с помощью которых вы можете писать программы для работы на сервере.
Сервер приложений
В настоящее время есть несколько серверов приложений таких крупных компаний, как Sun Microsystems, Borland, IBM, Oracle, и каждый из них отличается набором предоставляемых сервисов (производительность в данном случае учитывать не будем). Эти сервисы облегчают программирование и развертывание приложений масштаба предприятия. Вы можете использовать уже готовые строительные блоки для реализации необходимой бизнес-логики.
Давайте посмотрим, какие сервисы может предоставлять сервер приложений, от этого зависит количество и качество строительных блоков:
1. Webserver—чаще всего включают в поставку самый популярный и мощный Apache;
2. Web Container—позволяет выполнять JSP и сервлеты. Для Apache таким сервисом является Tomcat;
3. CORBA Agent — может предоставлять распределенную директорию для хранения CORBA объектов;
4. Messaging Service — брокер сообщений;
5. Transaction Service—уже из названия понятно, что это сервис транзакций;
6. JDBC — предлагает драйверы для подключения к базам данных, ведь именно серверу приложений придется общаться с БД и ему нужно уметь подключаться к используемой в вашей компании базе;
7. Java Mail — предоставляет сервис к SMTP;
8. JMS (Java Messaging Service) — обработка синхронных и асинхронных сообщений;
9. RMI (Remote Method Invocation) — вызов удаленных процедур.
Это основные блоки, которые может предоставлять тот или иной сервер приложений. Кроме того, каждый из них должен реализовывать саму спецификацию J2EE, дабы он мог работать с компонентами Enterprise JavaBeans. Для этого в сервере приложений необходим EJB-контейнер, который и отвечает за выполнение компонентов.
Компоненты EJB
Нередко те, кто малознаком с Enterprise JavaBeans, неверно понимают смысл этих компонентов. Дело в том, что классические JavaBeans-компоненты используются для визуального построения в клиентских приложениях. Enterprise JavaBeans вызываются клиентом, но работают на сервере приложений, где нет визуального интерфейса, а значит, такие компоненты не визуальны. Существует 2 типа EJB компонентов — session и entity. Первый не рассчитан на долговременное хранение состояния JavaBeans. Состояние сбрасывается при создании каждой новой сессии. Второй тип (entity) может сохранять состояние между запусками. Сессионные компоненты удобны при создании таких механизмов, как корзина заказа или управление контентом, и при этом очень редко используются изолированно. Чаще всего session-компоненты работают совместно с entity.
Для работы EJB-компонента необходимо создать три класса:
1. Класс, реализующий работу самого компонента;
2. HomeObject—используется для поиска и при необходимости создания/удаления компонентов$;
3. EJBObject—объект, через который клиент получает информацию о доступных в компоненте EJB методах.
Создание EJB
Чтобы закрепить на практике вышесказанное, давайте напишем небольшой сессионный EJB компонент. Для этого нам нужно будет написать три класса:
1. Сам компонент, назовем его класс EJBExampleBean;
2. HomeObject, назовем его EJBExampleHome;
3. EJBObject, назовем его EJBExample.
Каждый класс будет реализовываться в отдельном файле, и я думаю, что не нужно сообщать имена файлов. Как и в J2SE, имя должно соответствовать имени основного класса плюс расширение .Java. Все три класса поместим в пакет ru.itspec.ejbexamp, потому что классы без пакетов—плохой тон в программировании. Помимо этого все три файла будут импортировать следующие пакеты:
import javax.ejb.*; import java.util.*; import java.rmi.*;
Это и все, что есть идентичного во всех трех файлах. Теперь перейдем к рассмотрению особенностей каждого класса.
Код компонента
Начнем с самого большого класса, его код вы можете увидеть во врезке. Класс для EJB-компонента должен реализовывать интерфейс SessionBean. Этот интерфейс определяет следующие методы: ejbRemove, ejbActivate, ejbPassivate и setSessionContext, a значит, они должны быть реализованы нашим классом.
Метод setSessionContext вызывается одним из первых при создании компонента сессии. Как минимум, здесь необходимо сохранить в качестве параметра контекст сессии (он имеет тип SessionContext), он обязательно понадобится в более сложных компонентах. Сейчас же мы рассматриваем пустышку, которая может стать шаблоном для ваших более сложных компонентов. Для хранения контекста в самой первой строке объявления класса объявляется переменная sessionContext:
SessionContext sessionContext;
Коммуникации
Реализация Enterprise JavaBeans на все 100% соответствует концепции ООП, а компонент этот является самым настоящим черным ящиком. Программист, который будет применять его в своем клиентском приложении, не обязан и даже не должен иметь при себе исходный код используемого EJB. Он даже не будет знать, как там все устроено и реализовано, главное, чтобы клиентская программа получала нужный результат. Если вы работали с ActiveX от MS, то знаете, что там используется примерно такой же подход из трех уровней: СОМ клиент->интерфейс->СОМ-сервер. Разработчик клиента видит только интерфейс, в котором описываются доступные ему методы, и абсолютно не знает, как реализован СОМ-сервер. Всю сложность серверного компонента прячут классы HomeObject и EJBObject. Первый из них вы предоставляете для того, чтобы клиентское приложение могло найти и создать ваш EJB. Его код выглядит следующим образом: