Методологія побудови корпоративних інформаційних систем на основі технології EJB, Java, Програмування, статті

Введення

Думаю, розхвалювати те, що буде написано мною відразу не варто. Краще сказати чого я постараюся не написати. Якщо Ви хочете побачити тут підручник по якому можна навчиться основам EJB, то краще Вам почитати книжки типу Corba за 14 днів. Якщо Ви чекаєте моїх зітхань по перспективності і крутості технології EJB, то Вам краще почитати огляди популярних комп’ютерних журналів. Якщо Ви очікуєте знайти тут велика кількість вихідних прикладів, та ще що б вони компілювалися і працювали, то Вам краще почитати Manual від будь-якого постачальника комерційної або некомерційної версії EJB сервера. Загалом виходить, що не зовсім зрозуміло, для кого я це все буду писати. Не знаю, як навіть охарактеризувати мого потенційного читача. Думаю, що я пишу це для себе самого. Але не для себе в даний момент, а для себе кілька місяців тому. Справа в тому, що не так давно я писав лінійні програми без об’єктно-орієнтованого підходу. Хоча прекрасно знав про ООП, але не використав, так як вважав це незручним. Мені, на жаль, довелося вирішувати кілька досить складних задач. І вирішував я їх без ООП. Вирішував цілком успішно. Але ось коли прийшов час модернізації розроблених систем … Я був просто пригнічений. І тут мене доля звела з людиною, який мені показав способи застосування ООП: відображення об’єктів у БД, колекції об’єктів і т.д. Ім’я цієї людини Сергій Резінкін. Висловлюю йому подяку. Якби не він … Іншими словами мені потрібен був поштовх у правильному напрямку. Я став цікавитися UML, потім CORBA, потім вийшов на EJB і багато іншого. Так от я хочу Вам дати поштовх у правильному напрямку. Я позначу Вам шлях. Багато що тут Ви, можливо, не сприйму через стислості викладу або відсутності досвіду, який би дозволив вірно сприйняти деякі речі. Сподіваюся Вас зачепити, що б Ви самі далі почали копати в цьому напрямку.

Архітектура технології EJB

Найчастіше системи будуються таким чином. Є клієнтське додаток, який з’єднується з сервером БД і за допомогою SQL запитів маніпулює даними, відображеними в клієнтському GUI інтерфейсі. Клієнтська частина таких систем зазвичай дуже складна і на сервер баз даних покладається, в основному завдання, зберігання і підтримки цілісності даних. Іноді бази даних підтримують збережені процедури, що дозволяє знизити мережевий трафік між сервером і клієнтом. Така система зображена на рис. 1.


Рис.1

Такий підхід має свої плюси і мінуси. В плюс йде відносно проста архітектура системи і відносно висока швидкість роботи при невеликій кількості клієнтських звернень до сервера. У мінус йде те, що таку систему складно модернізувати, так як зміна в БД тягнуть за собою зміни в клієнтській частині і навпаки. У разі нестачі ресурсів сервера, доводиться або нарощувати його обчислювальну потужність або використовувати розподілену БД, яка не завжди зможе вирішити вашу проблему.

Існує інший підхід побудови інформаційних систем. Система поділяється на три рівні. Кожен рівень має свої обов’язки і функціональні можливості. На першому рівні знаходиться клієнтську програму, яке зазвичай “легке” і займається в основному презентаційним шаром системи. Другий рівень відповідає за бізнес логіку системи і взаємодіє з презентаційним шаром, відповідаючи на його запити. Другим рівнем називають сервер додатки. На третьому рівні знаходиться база даних, яка, як уже говорилося вище, відповідає за збереження даних та за їх цілісність. Така система зображена на рис. 2.


Рис.2

Такий підхід теж має свої плюси і мінуси. В плюс йде поділ системи на рівні, що дозволяє відносно легко модернізувати систему. Наприклад, сьогодні у Вас СУБД MySQL, а завтра Ви купили ORACLE і для цього Вам потрібно поправити тільки другий рівень, а презентаційний шар навіть не помітить змін. Або, наприклад, Ваш другий рівень не дуже оптимально працює і Ви вирішили його вдосконалити, немає проблем: перший і третій рівень можуть бути не порушені. Ще однією перевагою є можливість групової роботи над системою, в якій кожен з рівнів розробляється незалежно. Хтось проектує структури баз даних, хтось “малює” презентаційні шари, а хтось пише оптимальні алгоритми. В добавок до всього, компонентна технологія EJB орієнтована на можливість розподілу другого рівня, тобто якщо Ваш сервер додатків не справляється з навантаженням, то є можливість без єдиного зміни коду сервера додатків, рознести його на кілька обчислювальних машин. А компоненти, з яких складається другий рівень, не будуть відчувати різниці між роботою на одній обчислювальній машині і на кількох машинах. Мінусом таких систем є їх спрямованість на великі корпоративні рішення. Якщо Ви вирішуєте задачу в якій невелика кількість звернень до сервера і малий бюджет на створення системи, то зв’язавшись з EJB Ви будете стріляти з гармати по горобцях.

Багато запитають, а навіщо взагалі користуватися EJB технологією? Можна й самому побудувати таку ж систему, наприклад, використовуючи C + +. Це звичайно вірно, але Ви будете винаходити велосипед і прийдете до такого ж архітектурному рішенню, як у EJB, та й до того ж створення такої архітектури досить не тривіальна задача. Значно дешевше і швидше розібратися в правилах побудови компонентів EJB архітектури і будувати по її принципам свою систему на налагоджених технологіях. Так, трохи не забув: EJB – Enterprise JavaBeans. До речі на рахунок CORBA. Хтось запитає, а чому б не використовувати CORBA архітектуру замість EJB, які працюють не на дуже швидкісному мовою JAVA? Відповім досить просто. У CORBA поки що не готова специфікація компонентів CORBA. Ну а тим більше немає реалізацій ще не готовою специфікації. Ну а хто згадає про DCOM, тих відсилаю до статей, де проводиться порівняльний аналіз з CORBA, а після прочитання цих статей моя відповідь зводиться до того, що DCOM намагається конкурувати з CORBA і програє за кількома критеріями, та й до того ж не є компонентної технологією в “чистому” вигляді як EJB.

Насправді JAVA просуває 5 рівневу архітектуру на основі EJB, показану на рис.3.


Рис.3

Пояснювати її я не буду, щоб не заплутати читача, а привів тільки для того, що б частина читачів заспокоїлося на рахунок можливості побудови багато-рівневих систем на основі EJB.


СЕРВЕР ДОДАТКІВ


Найголовніше в EJB це сервер додатків. Без нього у Вас нічого працювати не буде. Клієнтські додатки будуть спілкуватися з ним через RMI або CORBA. Зазвичай сервер додатків надає Вашим EJB компонентам відповідне середовище. Наприклад: зберігає права доступу до Ваших компонентів (а точніше логіни з паролями з доступу до сервера додатків), підтримує RMI і CORBA взаємодію з ними, надає JNDI сервіс (сервіс іменування EJB компонентів), координатор транзакцій і контейнер, в якому будуть зберігатися ваші EJB компоненти, сервіс асинхронних повідомлень JMS. Фахівці, які це прочитають, будуть обурені грубими помилками. Справа в тому, щоб не вантажити читача, я досить спростив і змішав деякі речі. Сервер Додатків зображений на рис. 4.


Рис. 4

Як видно з малюнка, є комп’ютер, на якому працює сервер і до нього є доступ через RMI і CORBA. Усередині самого сервера додатків працюють чотири служби і контейнер. Тепер трохи докладніше про служби.

JNDI (Java Naming Directory Interface) – ця служба дозволяє Вашим клієнтськими додатками знаходити на сервері додатків EJB компоненти по їх імені. Насправді Ви можете взяти 10 комп’ютерів, об’єднати їх в мережу, встановити на них сервера додатків. Але сервіс JNDI включити тільки на одному з них. І вийде, що всі компоненти EJB будуть доступні на одному дереві імен, а працювати на різних серверах додатків. Звичайно, не даремно я застосовую термін дерево імен. Справа в тому, що ця служба дуже схожа на деревоподібну файлову структуру, де є папки (контексти) і файли (EJB компоненти). Я розповідаю це до того, що насправді можна запустити на всіх 10 комп’ютерах JNDI сервіс, але налаштувати їх так, що якийсь один з цих сервісів буде кореневим, а всі інші будуть підключені до нього і на загальному дереві імен будуть показані як татка (контексти).

Transaction Service – сервіс транзакцій. Цей сервіс надає схожі послуги транзакцій, як у звичайних реляційних базах даних. Тільки в даному випадку немає SQL запитів і немає рядків бази даних залучених в транзакцію. Замість SQL запитів Ви викликаєте методи змінюють стану компонентів і як тільки Ви почали транзакцію, то всі об’єкти, з якими Ви почнете працювати, будуть в неї залучені. В кінці Ви можете відкотити зміни, зроблені Вами в об’єктах або зафіксувати їх.

Security Service – сервіс безпеки. Так як сервер додатків надає віддалений доступ до EJB компонентів, то взагалі-то дуже добре б цей доступ обмежити. Для цього цей сервіс і потрібен.

JMS (Java Message Service) – сервіс асинхронних повідомлень. Є можливість послати повідомлення і не чекати підтвердження про отримання або відповіді. Наприклад, коли Ви викликаєте метод віддаленого компонента, то Вам доведеться чекати, поки компонент відпрацює і поверне Вам значення. Хоча Ви звичайно можете щось робити в інших нитках Вашого застосування. Насправді JMS бере всю відповідальність за доставку і зберігання черг повідомлень, що значно розвантажує клієнтські програми. Підтримуються механізми: точка до точки, підписка, розсилка. Також, на стороні JMS передплатник може встановити фільтр і отримувати тільки ті повідомлення, які його цікавлять.

КОНТЕЙНЕР

Контейнер це контейнер. Він надає середовище, в якому можуть функціонувати Ваші компоненти EJB. Виходить, у Вас є контейнер, в який ви можете запихати свої компоненти.

Які функції контейнера? Їх багато:



  1. Розбір XML-опису компонента EJB (deployment descriptor) і підтримка конфігурації, описаної в цьому XML-файлі.

  2. Управління життєвим циклом компонента EJB, тобто для надання послуг компонента прописаних в його інтерфейсі і зареєстрованому на JNDI, необхідно створювати, знищувати і кешувати реалізації (об’єкти), які будуть відповідати на запити клієнтів.

  3. Розбалансування навантаження між реалізаціями (об’єктами) обслуговуючими компонент EJB і керування пулом таких об’єктів.

  4. Управління транзакціями в компонентах EJB. У випадку з компонентами, які працюють з СУБД, управління транзакціями сильно пов’язано з механізмом синхронізації стану компонентів зі станом СУБД.

  5. Управління безпекою доступу до компонентів. Опціонально ця функція може бути відключена і перевірку прав доступу до методів Вашого компонента доведеться реалізовувати своїми руками в самому компоненті.

Контейнер зображений на рис. 5.


Рис. 5

Компонентної моделі

Для того, щоб зрозуміти, що ж насправді таке ці компоненти EJB, необхідно засвоїти деякі ідеї компонентної моделі. Слід усвідомити, якщо Ви використовуєте компонентну модель, значить, будівельними блоками моделі є компоненти, що має стандартний зовнішній вигляд, за допомогою якого можна ці компоненти зістиковувати. Іншими словами, якщо ви будете використовувати таку модель Вам необхідно суворо дотримуватися стандартів описують зовнішній вигляд ваших компонентів. Нутрощі Ваших компонентів, це Ваша проблема, Ви вільні реалізовувати функціонал, як Вам завгодно, правда є деякі рекомендації, які Вам принесуть більше користі, ніж шкоди.

Компоненти EJB мають, вільно висловлюючись, два зовнішніх опису (інтерфейсу). Через них, власне, клієнт і взаємодіє з Вашим компонентом.

Приклад цього зображений на рис. 6


Рис. 6

Home-інтерфейс, є точкою входу в Ваш компонент або фабрикою компонента. Іншими словами будь початок взаємодії з Вашими компонентами відбувається через Home-інтерфейси. Клієнт звертається до інтерфейсу і створює через нього екземпляри (об’єкти), які обслуговують даний компонент. А в кінці своєї роботи він їх знищує.

Remote-інтерфейс дозволяє взаємодіяти з примірниками (об’єктами), які були створені через фабрику (Home-інтерфейс). Через Remote-інтерфейс користувач викликає бізнес-методи компонента, які природно Вам доведеться реалізовувати, запихаючи туди логіку Вашого застосування.

Розберемо стандартний сценарій взаємодії клієнта з компонентами EJB. Взаємодія зображено на рис. 7


Рис. 7

1: Клієнт шукає Home-інтерфейс потрібного йому компонента по його імені через сервіс імен JNDI (клієнту повертається в результаті пошуку Home-інтерфейс цього знайденого компонента).
2: Клієнт, через знайдений Home-інтерфейс, викликає функцію створення екземпляра компонента на стороні сервера (клієнту повертається Remote-інтерфейс створеного екземпляра компонента).
2.1: Сервер створює цей екземпляр.
3: Клієнт викликає бізнес-метод на створеному компоненті через його Remote-інтерфейс цього компонента.
3.1: Сервер викликає бізнес-метод на конкретному екземплярі компонента.

На стороні клієнта Remote-інтерфейс і Home-інтерфейс оформлені у вигляді класів, які приховують мережеві взаємодії на основі RMI з сервером додатків. Клієнт працює з об’єктами, думаючи, що вони працюють в тому ж адресному просторі, що і сам додаток, а насправді відбуваються мережеві виклики і функціонал об’єктів працює зовсім на інший обчислювальній машині.

HOME-ІНТЕРФЕЙС

Як вже говорилося вище, вся робота з компонентами починається зі звернення до Home-інтерфейсу. Кожен тип компонент повинен його мати. Приклад Home-інтерфейсу зображений на рис. 8.

Рис. 8

У цьому інтерфейсі Ви повинні визначити методи двох типів. Це фабричні методи create та пошукові find.

Фабричні методи дозволяють Вам створювати для себе екземпляри компонентів на стороні сервера. При виклику цього методу Ви можете передати параметри ініціалізації компонента. Можна мати кілька фабричних методів з різним числом параметрів. При виклику фабричного методу Вам повертається посилання створеного компонента на стороні сервера. Отримавши це посилання, Ви можете почати спілкування зі створеним компонентом, тобто Викликати його бізнес методи.

Пошукові методи дозволяють знайти вже створені компоненти на стороні сервера. Пошукові методи застосовні лише до компонентів, які називаються EntityBean або, по-російськи, сутнісні біни. Іншими словами, час життя таких компонентів перевищує час роботи сервера додатків і, найчастіше, стан таких компонентів відображається в реляційні бази даних. Пошукові методи по результату дії дуже схожі на фабричні, але вони можу повертати не тільки посилання на один компонент, але і колекцію посилань декількох знайдених компонентів. Ще одна відмінність. При виклику пошукового методу Ви передаєте умова пошуку компонентів, і по цій умові відбувається вибірка компонента з бази даних.

REMOTE-ІНТЕРФЕЙС

Після того, як Ви створили чи знайшли компонент через його Home-інтерфейс і отримали посилання на його Remote-інтерфейс, можна приступити до взаємодії з цим EJB-компонентом. Всі способи взаємодії з компонентом строго визначені в отриманому Remote-інтерфейсі. Приклад Remote-інтерфейсу зображений на рис. 9.

Рис. 9

Стандартом, звичайно, є get / set-методи, що зчитують і встановлюють стану параметрів EJB-компонентів. Можна визначити будь-які методи в Remote-інтерфейсі, наприклад перерахунку суми з однієї валюти в іншу по такому-то курсу другої валюти щодо першої.

РЕАЛІЗАЦІЯ КОМПОНЕНТА

Після того як Ви визначили Home і Remote інтерфейси свого компонента, необхідно написати реалізації методів визначених у них. До деяких методів в реалізації додається приставка ejb. Приклад реалізації вище розглянутого компонента зображений на рис. 10.

Рис. 10

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*