Сервер додатків & 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.
EJB Object, назвемо його 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. Його код виглядає наступним чином:
package
com.itspec.ejbexamp;
import
javax.ejb .*; import java.util .*; import java.rmi .*;
public interface EJBExampleHome
extends javax.ejb.EJBHome (
public EJBExampleHome createO 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 SomeMethodlO 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
InitialContextO;
// отримуємо Home об'єкт
EJBExampleHome ejbObj =
(E JBExampleHome) initCtx.
lookup ( "EJBExample");
EJBExample ejbHome = ejbObj.Created;
e jbHome. SomeMethodl ();
ejbHome. SomeMethod2 ();
В
першому рядку створюємо клас контексту (Context), через який ми можемо
отримати доступ до функцій JNDI. У другому рядку ми використовуємо цей
контекст, а точніше-його метод lookup для пошуку необхідного нам EJB-компонента
Результатом пошуку буде об'єкт EJBExampleHome, це в нас HomeObject, через
який ми можемо створити сам компонент. Це і робимо в третьому рядку, викликом
методу Create. На цей раз, результатом буде об'єкт EJBExample. Пам'ятаєте, ми
говорили про те, що через нього ми будемо отримувати доступ до методів віддаленого
компонента? Значить, ми отримали те, що потрібно. Останні два рядки коду
показують, як можна викликати обидва наявних у компонента методу Так, вони в
даному прикладі нічого не роблять, але роботу перевірити вже можна.
Установка
Установка
J2ЕE-пpілoжeній-заняття не для слабкодухих. В основному це стосується тих, хто
звик працювати з мишкою, Windows-додатками і графічними програмами
установки. Для постачання додатків J2EE використовуються. Ear-архіви, які схожі
з J2SE-apxівамі.jar. Сама установка архіву на сервер залежить від використовуваного
сервера додатків. Сучасні середовища розробки Java включають в себе майстри
або утиліти, що спрощують підготовку архівів J2EE або взагалі, що автоматизують
процес створення такого архіву Вам не потрібно вручну писати файл маніфесту і
збирати файли за допомогою утиліт командного рядка, все буде зроблено
автоматично.
Разом
Ми
розглянули лише невеликий шаблон сесійного компонента Enterprise
JavaBeans. Цей шаблон ще нічого не вміє робити і тільки оголошує два
методу. На перший погляд складається враження, що код вийшов дуже
складним. Але ж це тільки верхівка айсберга Якщо подивитися, що відбувається на
нижньому рівні (всередині сервера додатків), то можна жахнутися. Але переляк
виникає тільки на перших порах, адже втом, що ми написали сьогодні немає нічого
зайвого.
Для
безпеки, надійності та ефективності дійсно потрібні всі три класи, але
при використанні сучасних середовищ розробки вам не доведеться писати код
вручну. Такі інтелектуальні Java IDE, як Borland JBuilder або NetBeans від
Sun Microsystems, дозволяють зробити все три класи, розглянуті сьогодні,
двома кліками мишки.
Код EJB-компоненту
package corn.itspec.ejbexarnp;
import javax.ejb .*; import
java.rmi .*;
public class EJBExampleBean
implements SessionBean (
//
поле для зберігання контексту сесії
SessionContext
sessionContext;
//
реалізація методів інтерфейсу SessionBean
public void ejbCreateO throws CreateException (
/*
Метод створення компоненту V
) Public void ejbRernoveO
(
/*
Знищення компонента V
) Public void ejbActivateO
(
/*
Активація компонента V
) Public void ejbPassivateO
(
/* Деактивація компоненту * /)
public void setSessionContext (Se
ssionContext context) (
/* Контекст сесії */
this.sessionContext = context;
//
реалізація власних методів компонента public void SomeMethodlO (
//
Тут реалізуйте метод 1)
public
void SomeMethod2 () (//Тут реалізуйте метод 2
Список літератури
IT
спец № 07 ЛИПЕНЬ 2007
