Сервер додатків і javabeans - стаття блог михаила флёнова
Використання серверів додатків є наступним кроком за клієнт-серверної технологією і дозволяє підвищити доступність, надійність і інформаційної системи підприємства. Але мені здається, що найважливішою перевагою використання сервера додатків є його велика гнучкість, що дуже важливо для великих підприємств. Здатність підприємства максимально швидко реагувати на стан ринку і навколишнього середовища дозволяє йому залишатися конкурентоспроможним.
Класика клієнт сервер
Класична архітектура доступу до даних клієнт-сервер складається з двох рівнів - рівня уявлення і рівня даних. Клієнт направляє серверу запити, а сервер відповідає на них: повертає необхідні дані або виробляє запитувані зміни над даними. У даній архітектурі сервер відповідає за зберігання даних і через збережені процедури виконує деякі дії. Вся інша навантаження (логіка програми та відображення даних) лягати на клієнтську програму.

Класична схема роботи з даними клієнт-сервер
Найстрашніше в цій технології те, що бізнес логіка лягати на плечі клієнта, а це веде до наступних недоліків:
1. При зміні логіки роботи програми доведеться оновлювати всі клієнтські програми, що не дуже то зручно і веде до великих витрат і витрат.
2. Зростають вимоги до клієнтського комп'ютера. Так, виробників ОС і комп'ютерного заліза це цілком влаштовує, але великому підприємству ці витрати не несуть прямої прибутку.
Якщо винести логіку роботи програми на сервер, то за комп'ютером клієнта залишається тільки функція подання даних, а з цим завданням впоратися навіть проста клієнтська машина або худий клієнт. Це серйозна економія грошей на оновлення клієнтського парку комп'ютерів і ОС. Вам вже не потрібна операційна система з великою кількістю функцій, а ніж вона простіше, тим менше буде містити помилок.
Вже напевно років 15 точаться розмови про те, що необхідно звільняти клієнтські машини і максимально використовувати можливості серверів. У зв'язку з цим, стали з'являтися багаторівневі системи клієнт-сервер, де клієнтські програми направляли запити проміжного програмного забезпечення, яке і виконувало функції бізнес логіки.
сервер додатків
При створенні концепції сервера додатків нічого нового не вигадували, просто поліпшили вже існуючу концепцію багаторівневої системи (а точніше, трьох рівневої). Сервер додатка ставати проміжним шаром між клієнтом і сервером.

Сервер додатків є проміжною ланкою між клієнтом і сервером
Така схема дозволяє отримати наступні переваги:
1. Клієнтської програмі абсолютно не потрібно знати, як і в якій базі даних зберігаються дані. Для отримання необхідних даних, клієнт викликає функції сервера додатків, а той вже отримує дані від сервера баз даних. Яким способом сервер додатків реалізує функцію, нікого не хвилює. А де перевага? Припустимо, що потрібно змінити структуру таблиць. Вносимо зміни, змінюємо реалізацію функції на сервері додатків, а клієнтські програми продовжують працювати, не підозрюючи, що структура змінилася.
2. Бізнес логіка зберігатися на сервері додатків. Якщо потрібно змінити алгоритм якогось звіту або розрахунку, наприклад, заробітної плати, то непотрібно змінювати функції клієнтських додатків. Досить змінити один сервер додатків.
3. Зменшується навантаження на клієнтські комп'ютери.
4. Сервер програми розподіляє навантаження і забезпечує захист від збоїв.
Можна продовжувати цей список далі, але, на наш погляд, ці пункти найбільш важливі і достатні для того, щоб звернути увагу на сервера додатків. Ну а звернувши увагу, ви побачите, що тут приховано майбутнє.
компонентний посередник
- Message orientated - яскраві представники MQseries і JMS;
- Object Broker - яскраві представники CORBA і DCOM;
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, тому що класи без пакетів - поганий тон в програмуванні. Крім цього, всі три файли будуть імпортувати наступні пакети:
Це і все, що є ідентичного в усіх трьох файлах. Тепер перейдемо до розгляду особливостей кожного класу.
код компонента
Почнемо з самого великого класу, його код ви можете побачити в урізанні. Клас для EJB компонента повинен реалізовувати інтерфейс SessionBean. Цей інтерфейс визначає наступні методи ejbRemove, ejbActivate, ejbPassivate і setSessionContext, а значить, вони повинні бути реалізовані нашим класом.
комунікації
Реалізація Enterprise JavaBeans на всі 100% відповідає концепції ООП і компонент є справжнісіньким чорним ящиком. Програміст, який буде використовувати цей компонент в своєму клієнтському додатку не зобов'язаний і навіть не повинен мати при собі вихідний код використовуваного EJB. Він навіть не буде знати, як там все влаштовано і реалізовано, головне, щоб клієнтська програма отримувала потрібний результат.
Якщо ви працювали з ActiveX від MS, то там використовується приблизно такий же підхід з трьох рівнів COM клієнт> інтерфейс-> COM сервер. Розробник клієнта бачить тільки інтерфейс, в якому описуються доступні йому методи і абсолютно не знає, як реалізований COM сервер.
Всю складність серверного компонента ховають класи HomeObject і EJBObject. Перший клас ви надаєте для того, щоб клієнтське додаток могло знайти і створити ваш EJB. Його код виглядає наступним чином:
Клас походить від EJBObject і оголошує один єдиний конструктор. Для простого компонента цього цілком достатньо. У більш складних компонентах ви можете реалізувати кілька варіантів конструкторів з різною кількістю переданих параметрів.
І останній клас EJBObject для нашого прикладу буде виглядати так:
Клас HomeObject повинен відбуватися від класу EJBObject, і в ньому ви тільки описуєте методи, які вже реалізовані в самому EJB. Даний клас є посередником між компонентом і клієнтським додатком і через нього клієнт дізнається, які йому доступні методи.
Компонент можна вважати готовим. Тепер подивимося, як клієнт може використовувати EJB. Повноцінне додатки ми писати не будемо, бо вивчення самої мови Java виходить за рамки статті. Ми побачимо тільки абстрактний код створення і виклику методу EJB компонента. Але для початку необхідно підключити наступний пакет:
Цим ми підключили функції JNDI контексту іменування. JNDI (Java Naming and Directory Service) - це Naming Service, який дозволяє нам працювати з об'єктами по дружнім іменах. При цьому, тут нічого нового немає, цей сервіс всього лише надбудова над вже існуючими (DNS, LDAP, CORBA, RMI), яка надає універсальний набір API, що дозволяє працювати з будь-яким з цим сервісів іменування.
У першому рядку створюємо клас контексту (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 компонента
Увага. Якщо ти копіюєш цю статтю собі на сайт, то залишай посилання безпосередньо на цю сторінку. Дякую за розуміння