Е серверов приложений является следующим шагом за клиент-серверной технологией и позволяет повысить доступность, надежность и информационной системы предприятия
| Вид материала | Документы |
- О проектировании данных для клиент-серверных приложений С++Builder, 179.76kb.
- Berkrley Internet Name Domain. Иногда для этой цели выделяют специальную машину задача, 5769.74kb.
- Настоящая статья посвящена вопросам обеспечения информационной безопасности при осуществлении, 557.89kb.
- Пользователю системы Клиент-Банк Памятка о мерах по обеспечению информационной безопасности, 43.58kb.
- Программы информатизации муниципального общеобразовательного учреждения средней общеобразовательной, 417.39kb.
- Надежность 1 введение, 380.4kb.
- Вестник Брянского государственного технического университета. 2006, 147.04kb.
- Мирончик Игорь Янович ClipperIgor@gmail com (496)573-34-22 курс лекций, 28.92kb.
- Техническое задание Наименование: Закуп Системы антивирусной защиты для рабочих станций,, 137.25kb.
- "Программные агенты и мультиагентные системы", 138.64kb.
Сервер приложений и JavaBeans
Использование серверов приложений является следующим шагом за клиент-серверной технологией и позволяет повысить доступность, надежность и информационной системы предприятия. Но мне кажется, что самым важным преимуществом использования сервера приложений является его большая гибкость, что очень важно для больших предприятий. Способность предприятия максимально быстро реагировать на состояние рынка и окружающей среды позволяет ему оставаться конкурентоспособным.
Классика клиент сервер
Классическая архитектура доступа к данным клиент-сервер состоит из двух уровней – уровня представления и уровня данных. Клиент направляет серверу запросы, а сервер отвечает на них: возвращает необходимые данные или производит запрашиваемые изменения над данными. В данной архитектуре сервер отвечает за хранение данных и через хранимые процедуры выполняет некоторые действия. Вся остальная нагрузка (логика приложения и отображение данных) ложиться на клиентское приложение.
Классическая схема работы с данными клиент-сервер
Самое страшное в данной технологии то, что бизнес логика ложиться на плечи клиента, а это ведет к следующим недостаткам:
1. При изменении логики работы приложения придется обновлять все клиентские приложения, что не очень то удобно и ведет к большим затратам и издержкам.
2. Возрастают требования к клиентскому компьютеру. Да, производителей ОС и компьютерного железа это вполне устраивает, но крупному предприятию эти расходы не несут прямой прибыли.
Если вынести логику работы приложения на сервер, то за клиентским компьютером остается только функция представления данных, а с этой задачей справиться даже простая клиентская машина или тощий клиент. Это серьезная экономия денег на обновлении клиентского парка компьютеров и ОС. Вам уже не нужна операционная система с большим количеством функций, а чем она проще, тем меньше будет содержать ошибок.
Уже наверно лет 15 идут разговоры о том, что необходимо освобождать клиентские машины и максимально использовать возможности серверов. В связи с этим, стали появляться многоуровневые системы клиент-сервер, где клиентские программы направляли запросы промежуточному программному обеспечению, которое и выполняло функции бизнес логики.
Сервер приложений
При создании концепции сервера приложений ничего нового не придумывали, просто улучшили уже существующую концепцию многоуровневой системы (а точнее, трех уровневой). Сервер приложения становиться промежуточным слоем между клиентом и сервером.
Сервер приложений является промежуточным звеном между клиентом и сервером
Такая схема позволяет получить следующие преимущества:
1. Клиентской программе абсолютно не нужно знать, как и в какой базе данных хранятся данные. Для получения необходимых данных, клиент вызывает функции сервера приложений, а тот уже получает данные от сервера баз данных. Каким способом сервер приложений реализует функцию, никого не волнует. А где преимущество? Допустим, что нужно изменить структуру таблиц. Вносим изменения, изменяем реализацию функции на сервере приложений, а клиентские приложения продолжают работать, не подозревая, что структура изменилась.
2. Бизнес логика храниться на сервере приложений. Если нужно изменить алгоритм какого-то отчета или расчета, например, заработной платы, то ненужно изменять функции клиентских приложений. Достаточно изменить один сервер приложений.
3. Уменьшается нагрузка на клиентские компьютеры.
4. Сервер приложения распределяет нагрузку и обеспечивает защиту от сбоев.
Можно продолжать этот список дальше, но, на наш взгляд, эти пункты наиболее важные и достаточные для того, чтобы обратить внимание на сервера приложений. Ну а обратив внимание, вы увидите, что здесь сокрыто будущее.
Компонентный посредник
Серверы приложений относят к приложениям промежуточного слоя (middleware). Существует несколько категорий продуктов промежуточного слоя:
- Message orientated – яркие представители MQseries и JMS;
- Object Broker – яркие представители CORBA и DCOM;
- Component based – наиболее перспективная категория, на мой взгляд, и это подтверждают знаменитые представители данной категории .NET и EJB.
В данной статье мы будем рассматривать последнюю категорию на примере EJB (Enterprise JavaBeans), как законодателя моды. Недаром данная технология долгое время не давала спать одному очень знаменитому софтверному гиганту, и ему пришлось в срочном порядке создавать свою реализацию.
JavaBeans предоставляет нам набор инструментов (Framework), с помощью которых вы можете писать программы для работы на сервере. Такие программы подключаются к серверу приложений и .
Сервер приложений
Существует несколько серверов приложений от таких знаменитых компаний как Sun Microsystem, Borland, IBM, Oracle и каждый из них отличается набором предоставляемых сервисов (производительность в данном случае учитывать не будем). Эти сервисы облегчают программирование и развертывание приложений масштаба предприятия. Вы можете использовать уже готовые строительные блоки для реализации необходимой бизнес логики.
Давайте посмотрим, какие сервисы может предоставлять сервер приложений, от этого зависит количество и качество строительных блоков:
- WEB Server – чаще всего включают в поставку самый популярный и мощный Apache;
- WEB Container – позволяет выполнять JSP и сервлеты. Для Apache таким сервисом является Tomcat;
- CORBA Agent – может предоставлять распределенную директорию для хранения CORBA объектов;
- Messaging Service – брокер сообщений;
- Transaction Service – уже из названия понятно, что это сервис транзакций;
- JDBC – драйвера для подключения к базам данных, ведь именно серверу приложений придется общаться с базами данных и ему нужно уметь подключаться к используемой в вашей компании базе;
- Java Mail – данный сервис может предоставлять сервис к SMTP;
- JMS (Java Messaging Service) – обработка синхронных и асинхронных сообщений;
- RMI (Remote Method Invocation) - вызов удаленных процедур.
Это основные блоки, которые может предоставлять тот или иной сервер приложений. Помимо этого, каждый из них должен реализовывать саму спецификацию J2EE, дабы он мог работать с Enterprise JavaBeans компонентами. Для этого, в сервере приложений должен быть реализован EJB контейнер. Этот контейнер и отвечает за выполнение компонентов.
Компоненты EJB
Те, кто не слышал или слышал, но мимолетом про Enterprise JavaBeans неверно понимают смысл этих компонентов. Дело в том, что классические JavaBeans компоненты используются для построения визуально в клиентских приложениях. Enterprise JavaBeans вызываются клиентом, но работают на сервере приложений, где нет визуального интерфейса, а значит, такие компоненты не визуальны.
Существует два типа EJB компонентов – session и entity. Первый тип не предоставляет долговременное хранение состояния JavaBean. Состояние сбрасывается при создании каждой новой сессии. Второй тип (entity) может сохранять состояние между запусками.
Сессионные компоненты удобны при создании таких механизмов как корзина заказа или управление контентом, и при этом, очень редко используются изолировано. Чаще всего session компоненты работают совместно с entity.
Для работы EJB компонента необходимо создать три класса:
1. Класс, реализующий работу самого компонента;
2. HomeObject – используется для поиска и при необходимости создания/удаления компонентов.
3. EJBObject - объект, через который клиент получает информацию о доступных в компоненте EJB методах.
Создание EJB
Чтобы закрепить на практике вышесказанное, давайте напишем небольшой сессионный EJB компонент. Для этого нам нужно будет написать три класса:
1. Cам компонент, назовем его класс 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, а значит, они должны быть реализованы нашим классом.
Метод setSessionContext вызывается одним из первых при создании компонента сессии. Как минимум, здесь необходимо сохранить в качестве параметра контекст сессии (он имеет тип SessionContext), он обязательно понадобиться в более сложных компонентах. Сейчас же мы рассматриваем пустышку, которая может стать шаблоном для ваших более сложных компонентов. Для хранения контекста, в самой первой строке объявления класса объявляется переменная sessionContext:
SessionContext sessionContext;
Коммуникации
Реализация Enterprise JavaBeans на все 100% соответствует концепции ООП и компонент является самым настоящим черным ящиком. Программист, который будет использовать этот компонент в своем клиентском приложении не обязан и даже не должен иметь при себе исходный код используемого EJB. Он даже не будет знать, как там все устроено и реализовано, главное, чтобы клиентская программа получала нужный результат.
Если вы работали с ActiveX от MS, то там используется примерно такой же подход из трех уровней COM клиент->Интерфейс->COM сервер. Разработчик клиента видит только интерфейс, в котором описываются доступные ему методы и абсолютно не знает, как реализован COM сервер.
Всю сложность серверного компонента прячут классы HomeObject и EJBObject. Первый класс вы предоставляете для того, чтобы клиентское приложение могло найти и создать ваш EJB. Его код выглядит следующим образом:
package com.itspec.ejbexamp;
import javax.ejb.*;
import java.util.*;
import java.rmi.*;
public interface EJBExampleHome extends javax.ejb.EJBHome {
public EJBExampleHome create() throws CreateException, RemoteException;
}
Класс происходит от EJBObject и объявляет один единственный конструктор. Для простого компонента этого вполне достаточно. В более сложных компонентах вы можете реализовать несколько вариантов конструкторов с различным количеством передаваемых параметров.
И последний класс EJBObject для нашего примера будет выглядеть так:
package com.itspec.ejbexamp;
import javax.ejb.*;
import java.util.*;
import java.rmi.*;
public interface EJBExample extends javax.ejb.EJBObject {
public void SomeMethod1() throws RemoteException;
public void SomeMethod2() throws RemoteException;
}
Класс HomeObject должен происходить от класса EJBObject, и в нем вы только описываете методы, которые уже реализованы в самом EJB. Данный класс является посредником между компонентом и клиентским приложением и через него клиент узнает, какие ему доступны методы.
Клиент
Компонент можно считать готовым. Теперь посмотрим, как клиент может использовать EJB. Полноценное приложения мы писать не будем, ибо изучение самого языка Java выходит за рамки статьи. Мы увидим только абстрактный код создания и вызова метода EJB компонента. Но для начала необходимо подключить следующий пакет:
import javax.naming.*;
Этим мы подключили функции JNDI контекста именования. JNDI (Java Naming and Directory Service) – это Naming Service, который позволяет нам работать с объектами по дружественным именам. При этом, тут ничего нового нет, этот сервис всего лишь надстройка над уже существующими (DNS, LDAP, CORBA, RMI), которая предоставляет универсальный набор API, позволяющий работать с любым из этим сервисов именования.
// инициализация контекста JNDI
Context initCtx = new InitialContext();
// получаем Home объект
EJBExampleHome ejbObj = (EJBExampleHome)initCtx.lookup("EJBExample");
EJBExample ejbHome = ejbObj.Create();
ejbHome.SomeMethod1();
ejbHome.SomeMethod2();
В первой строке создаем класс контекста (Context), через который мы можем получить доступ к функциям JNDI. Во второй строке мы уже используем этот контекст, а точнее его метод lookup для поиска необходимого нам EJB компонента. Результатом поиска будет объект EJBExampleHome, это у нас HomeObject, через который мы можем создать сам компонент. Это и делаем в третьей строке, вызовом метода Create. На этот раз, результатом будет объект EJBExample. Помните, мы говорили о том, что через него мы будем получать доступ к методам удаленного компонента? Значит, мы получили то, что нужно.
Последние две строки кода показывают, как можно вызвать оба имеющихся у компонента метода. Да, они в данном примере ничего не делают, но сам факт работу уже проверить можно.
Поставка
Поставка J2EE приложений – занятие не для слабонервных. В основном это касается тех, кто привык работать с мышкой, Windows приложениями и графическими программами установки. Для поставки приложений J2EE используются .ear архивы, которые схожи с J2SE архивами .jar. Сама установка архива на сервер зависит от используемого сервера приложений.
Современные среды разработки Java включают в себя мастера или утилиты, упрощающие подготовку архивов J2EE или вообще, автоматизирующих процесс создания подобного архива. Вам не нужно вручную писать файл манифеста и собирать файлы с помощью утилит командной строки, все будет сделано автоматически без вашего вмешательства.
Итого
Мы рассмотрели только небольшой шаблон сессионного Enterprise JavaBeans компонента. Этот шаблон еще ничего не умеет делать и только объявляет два метода. На первый взгляд создается впечатление, что код получился слишком сложным. А ведь это только верхушка айсберга. Если посмотреть, что происходит на нижнем уровне (внутри сервера приложений), то можно ужаснуться. Но испуг возникает только на первых порах, ведь в том, что мы написали сегодня нет ничего лишнего.
Для безопасности, надежности и эффективности действительно нужны все три класса, но при использовании современных сред разработки вам не придутся писать код вручную. Такие интеллектуальные Java IDE как Borland JBuilder или NetBeans от Sun Microsystems позволяют сделать все три класса, рассмотренных сегодня двумя кликами мышки.
Код EJB компонента
package com.itspec.ejbexamp;
import javax.ejb.*;
import java.rmi.*;
public class EJBExampleBean implements SessionBean {
// поле для хранения контекста сессии
SessionContext sessionContext;
// реализация методов интерфейса SessionBean
public void ejbCreate() throws CreateException {
/* Метод создания компонента */
}
public void ejbRemove() {
/* Уничтожение компонента */
}
public void ejbActivate() {
/* Активация компонента */
}
public void ejbPassivate() {
/* Деактивация компонента */
}
public void setSessionContext(SessionContext сontext) {
/* Контекст сессии */
this.sessionContext = сontext;
}
// реализация собственных методом компонента
public void SomeMethod1(){
// Здесь реализуйте метод 1
}
public void SomeMethod2(){
// Здесь реализуйте метод 2
}