Дескриптор розгортання web-прикладних програм та компонент

Дескриптор (англ. Descriptor) – дослівно описувач, описовий елемент. Дескриптор – невід’ємне ціле число, яке задає номер будь-якого ресурсу в процесі роботи з ним і використовується зазвичай через деякий інтерфейс, причому смисл значення дескриптора схований за цим інтерфейсом.

Платформа Java 2 Enterprise Edition. J2EE-платформа – це розподілена комп’ютерна платформа, що полегшує дизайн, розробку, компонування і розгортання компонентно-орієнтованих корпоративних прикладних програм.

Розрізняють безліч способів, за якими можна подавати специфічний набір бізнес-вимог, логічну модель і опис рішення, які задовольняють таким вимогам. J2EE-платформа найбільш придатна і найкраще підходить для підтримування крос-платформності, безпеки, транзакційних прикладних програм, які надають корпоративну інформацію для Internet- та Internet-клієнтів.

J2EE-прикладна програма являє собою набір програмних компонентів, створених для поширення на кілька рівнів. J2EE-платформа сервер-орієнтована, тому для J2EE-прикладних програм типово пропонувати засоби різноманітним клієнтам. Терміни «клієнт» і «сервер» використовують, щоб відобразити логічну, а не апаратну структуру.

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

Платформа J2EE призначена передусім для розробки розподіленого Web-орієнтованого прикладного програмного забезпечення і підтримує такі види компонентів:

Enterprise JavaBeans (EJB). Компоненти EJB призначені для реалізації на їх основі бізнес-логіки програми та операцій над даними. Будь-які компоненти, розроблені на Java, називають бінами.

Web-компоненти (Web components). Ці компоненти надають інтерфейс до корпоративних програмних систем зверху широко використовуваних протоколів Internet, зокрема HTTP. Надані інтерфейси можуть бути як інтерфейсами для людей (WebUI), так і спеціалізованими програмними інтерфейсами, що працюють подібно віддаленому виклику методів, але зверху HTTP. До групи Web-компонентів входять фільтри (filters), обробники Web-подій (web eventlisteners), сервлети (servlets) і серверні сторінки Java (JSP).

Звичайні програми на Java. J2EE (Java Platform Enterprise Edition) є розширенням J2SE (Java Platform Standart Edition), тому всі прикладні програми, написані мовою Java, можуть працювати і в цьому середовищі. Однак, окрім звичайних можливостей J2SE, ці прикладні програми можуть використовувати у своїй роботі Web-компоненти і EJB як безпосередньо, так і віддалено, зв’язуючись з ними по HTTP.

Аплети (applets). Це невеликі компоненти, що мають графічний інтерфейс користувача і призначені для роботи всередині стандартного Web-браузера. Вони використовуються тоді, коли не вистачає можливостей подання інформації для користувача інтерфейсу на основі HTML, і можуть зв’язуватися з віддаленими Web-компонентами, які працюють на сервері, по HTTP.

Компоненти, які підтримує ця платформа, мають дескриптор розгортання (deployment descriptor) – опис у встановленому форматі на основі XML- конфігурації компонента у межах контейнера, в якому він міститься. Прикладна програма в цілому також має дескриптор розгортання. Дескриптори розгортання відіграють важливу роль, дозволяючи змінювати деякі параметри функціонування компонента і прив’язувати їх до параметрів середовища, у межах якого компонент працює, не змінюючи його коду.

Розглянемо способи вирішення спільних завдань побудови розподілених систем на основі платформи J2EE.

Цілісність і несуперечність даних під час роботи J2EE-прикладних програм підтримується за допомогою механізму розподілених транзакцій, керувати якими може EJB-контейнер, який створюється визначенням політики участі методів EJB-компонентів у транзакції в їх дескрипторах розгортання або може здійснюватися вручну. В обох випадках використовуються механізми, що реалізують інтерфейси керування транзакціями Java (Java Transaction API, JTA).

Базові інтерфейси JTA містяться у пакетах javax.transaction і javax.transaction.xa. Це, передусім, інтерфейси менеджера транзакцій TransactionManager, самих транзакцій Transaction і UserTransaction та інтерфейс синхронізації Synchronization, що дозволяє отримувати повідомлення про початок завершення і кінець завершення транзакцій.

Методи інтерфейсу TransactionManager дозволяють запустити транзакцію, завершити її успішно або відкотити, а також отримати об’єкт, що подає поточну транзакцію і має тип Transaction. Методи інтерфейсу Transaction дають змогу завершити або відкотити транзакцію, яку подає об’єкт такого інтерфейсу, зареєструвати об’єкти для синхронізації у процесі завершення транзакції, а також додати деякі ресурси до числа учасників даної транзакції або видалити їх із цього списку. Такі ресурси подаються у вигляді об’єктів інтерфейсу javax.transaction.xa.XAResource.

Інтерфейс UserTransaction використовують, щоб керувати призначеними для користувача транзакціями – він надає дещо менше можливостей, ніж TransactionManager.

У тому разі, якщо керування транзакціями цілком доручається EJB-контейнеру (це транзакції, керовані контейнером, container managed transactions), впливати на їх перебіг можна, зазначаючи в дескрипторах розгортання EJB-компонентів різні транзакційні атрибути (transaction attributes) для їх методів. Транзакційний атрибут може набувати одною з таких значень:

Required. Метод, у якого наявний такий атрибут, завжди має виконуватися в контексті транзакції, тобто він працюватиме в контексті тієї самої транзакції, в якій працював метод, що викликав його, а якщо він був викликаний поза контекстом транзакції, з початком його роботи буде запущена нова транзакція. Цей атрибут використовується найбільш часто;

RequiresNew. Метод, який має такий атрибут, завжди буде запускати нову транзакцію на самому початку роботи, при цьому зовнішня транзакція, якщо вона виконувалась, буде тимчасово припинена;

Mandatory. Метод, у якого наявний такий атрибут, має викликатися тільки з транзакції, у контексті якої він і продовжить працювати. У разі виклику такого методу ззовні транзакції буде створена виняткова ситуація, зокрема TransactionRequiredException;

NotSupported. У разі виклику такого методу зовнішня транзакція, якщо вона є, буде тимчасово припинена, а якщо її немає, то нова транзакція не буде запущена;

Supports. Такий метод працює у транзакції, якщо його викликали з її контексту, якщо ж він був викликаний поза транзакцією, то нова транзакція не запускається;

Never. У разі виклику такого методу з транзакції створюється виняткова ситуація RemoteException. Він може працювати, тільки якщо його викликано ззовні транзакції.

Відкотити автоматично керовану транзакцію можна, створивши виняткову ситуацію javax.ejb.EJBException або викликавши метод setRollbackOnly() інтерфейсу javax.ejb.EJBContext.

Захищеність J2EE-програми підтримується декількома способами:

1. За допомогою методів аутентифікації, тобто визначення ідентичності користувачів, які позначають у дескрипторі розгортання програми. Можна використовувати такі способи аутентифікації:

· аутентифікація не виконується;

· за допомогою основного механізму протоколу HTTP. У разі спроби звертання до ресурсу за протоколом HTTP буде запитане ім’я користувача та па-роль, які перевірить Web-сервер. Цей спосіб не дуже добре захищений, оскільки реквізити користувача пересилаються мережею в незашифрованому вигляді;

· за допомогою дайджесту (digest). Цей метод працює так само, як основ-ний механізм аутентифікації по HTTP, але ім’я і пароль користувача пересилаються в зашифрованому вигляді. Такий спосіб використовується досить рідко;

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

· з використанням сертифіката клієнта. Цей метод використовує протокол HTTPS, клієнт повинен надати свій сертифікат або відкритий ключ, який відповідає стандарту X.509 на інфраструктуру відкритих ключів. Можна використовувати і взаємну аутентифікацію – у цьому разі й клієнт, і сервер надають свої сертифікати.

2. За допомогою з’єднань за протоколом HTTP поверх рівня захищених сокетів (Secure Socket Layer, SSL, на HTTP поверх SSL часто посилаються за допомогою окремої абревіатури HTTPS). Можна використовувати лише такі комбінації, вказавши атрибути CONFIDENTIAL та/або INTEGRAL у дескрипторі розгортання програми. Перший атрибут означає, що передачу да-них між клієнтом та програмою буде зашифровано так, що їх важко буде прочитати третій стороні. Другий атрибут означає, що ці дані супроводжуватимуть додатковою інформацією, яка гарантує їх цілісність, тобто те, що їх не було підмінено десь між сторонами, які беруть участь у зв’язку.

3. За допомогою механізму опису ролей визначення доступності різних методів Web-компонентів і EJB-компонентів для різних ролей, а також завдання політики перенесення або створення ролей під час спільної роботи кількох методів. Ролі, політики їх перенесення і правила доступу різних ролей до методів описуються в дескрипторах розгортання компонентів. У процесі розгортання програми зареєстровані на J2EE-сервері користувачі та групи користувачів можуть бути відображені на різні ролі, зазначені в прикладній програмі.

4. За допомогою встановлення обмежень доступу до наборів ресурсів, що задаються у вигляді списків уніфікованих ідентифікаторів ресурсів (URI) або шаблонів URI. Ці обмеження описуються в дескрипторі розгортання про-грами та визначають ролі й дозволені їм види прямого доступу (не через звертання до інших компонентів) до певного набору URI.

5. За допомогою програмного визначення ролей і користувачів, від іме-ні яких працює поточний потік, з коду самих компонентів. Це можна робити за допомогою методів isUserInRole() та getUserPrincipal() інтерфейсу HTTP ServletRequest, використовуваного для подання запитів до Web-компонентів й аналогічних методів isCallerInRole() та getCallerPrincipal() інтерфейсу EJBContext, для опису контексту виконання методів EJB-компонентів.

Платформа .NET. Середовище .NET призначено для більш широкого використання, ніж платформа J2EE. Однак його функціональність у частині, призначеній для розробки розподілених Web-прикладних програм, дуже схожа на J2EE. Роль дескрипторів розгортання відіграють конфігураційні файли, подані в певному форматі на основі XML.

EJB-контейнер. У цілому EJB-контейнер являє собою приклад об’єктного монітора транзакцій – програмного забезпечення проміжного рівня, що підтримує в межах об’єктно-орієнтованої парадигми віддалені ви-клики методів та розподілені транзакції. Це компонентне середовище для компонентів Enterprise JavaBeans, яке підтримує автоматичну синхронізацію Java об’єктів з базою даних.

· EJB-контейнер підтримує такі базові служби при роботі з компонентами EJB:

· автоматична підтримка звертань до компонентів, розміщених на різних машинах;

· автоматична підтримка транзакцій;

· автоматична синхронізація стану баз даних та відповідних компонентів EJB у обидва боки;

· автоматична підтримка захищеності за рахунок аутентифікації користувачів, перевірки прав користувачів або компонентів на виконання виклика-них ними операцій та авторизації відповідних дій;

· автоматичне керування життєвим циклом компонента (послідовністю переходів між станами «немає» – «ініціалізований» – «активний») і набором компонентів аналогічно до ресурсів, тобто видалення компонентів, що стали непотрібними; завантаження нових компонентів; балансування навантаження між наявними компонентами.

WEB-контейнер. Компонентним середовищем для роботи Web-компонентів є Web-контейнер, що постачається в межах будь-якої реалізації платформи J2EE. Web-контейнер реалізує такі служби, як керування життєвим циклом компонентів і набором компонентів аналогічно до ресурсу, тобто розпаралелювання незалежних робіт, виконання віддалених звертань до компонентів, підтримка захищеності за допомогою перевірки прав компонентів і користувачів на виконання різних операцій.

Результати роботи компонентів EJB перетворюються Web-компонентами в динамічно генеровані HTML-сторінки, і надсилаються назад до користувача, постаючи перед ним у вікні браузера.

Роль Web- і EJB-контейнерів. Процеси та синхронізація. Розбиває прикладну програму J2EE на низку процесів із потоками керування, які взаємодіють, Web- або EJB-контейнер автоматично. На їх роботу можна впливати, конфігуруючи як J2EE-сервер у цілому, так і конкретні прикладні програми. Усі методи допоміжних класів, які використовують Web-компоненти й компоненти EJB, слід оголошувати синхронізованими. Компоненти J2EE, що працюють у межах контейнерів, можуть створювати власні окремі потоки, але робити це потрібно з великою обережністю, оскільки цими потоками контейнер керувати не зможе, і вони можуть зашкодити роботі інших компонентів (рис. 54).

Рисунок 54 – Архітектура прикладної програми J2EE

Деякі сценарії прикладних програм та роль Web- і EJB-контейнерів.

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

Рисунок 55 – Сценарії

На вибір сценарію створення прикладного програмного забезпечення суттєво впливають такі корпоративні вимоги:

- необхідність швидко й часто змінювати вигляд прикладної програми;

- необхідність поділяти прикладні програми на представлення (інтерфейс користувача) та бізнес-логіку, щоб збільшити модульність;

- необхідність спрощувати процес подання інформації користувачам, які виконують завдання разом, причому робота кожним з них має виконуватися порівняно незалежно, але пов’язаними сценаріями;

- необхідність мати розробників, які знаються на офісних прикладних програмах, звільнених від розробки GUI і дизайну, в яких вони не можуть бути високо кваліфікованими;

- необхідність мати певний словник, щоб передати бізнес-логіку командам розробників, які розуміють вплив людського фактора й естетики прикладного програмного забезпечення;

- здатність створювати офісні прикладні програми, використовуючи компоненти з різних джерел, включаючи наявні компоненти бізнес-логіки;

- здатність розгортати виконувані (transactional) компоненти через чис-ленні апаратні та програмні платформи, незалежно від основної технології бази даних;

- здатність перетворювати внутрішні дані на зовнішні без додаткої інформації про споживача даних і виконувати це слабкозв’язаним способом.

Безсумнівно, врахування не в повному обсязі деяких або всіх названих вимог може впливати на рішення щодо проектування рівнів прикладної програми. Модель програмування J2EE вирішує проблему шляхом створення трирівневої прикладної програми так, щоб у подальшому перехід на багаторівневу архітектуру спрощувався за рахунок повторно використовуваних компонентів. Хоча розумно говорити про «недовговічність» логіки представлення (інтерфейс користувача часто змінюють), все ж таки існує порівняно мало змінюваний інтерфейс між рівнями прикладного програмного забезпечення, який зв’язує інтерфейс користувача з бізнес-логікою. Такий підхід широко використовують у разі організації взаємодії схем баз даних і даних. Нині за рахунок використання єдиного середовища доступу до ресурсів (EIS) з’являється можливість частої зміни коду прикладної програми, тобто довговічність прикладної програми значно знижується. Таким чином, модель програмування J2EE прискорює розвиток, сприяє по вторному використанню компонентно-орієнтованого коду та є важелем для посилення міжрівневої взаємодії, яка використовує інтеграцію рівнів у моделі програмування J2EE.

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

Багаторівневий сценарій програми. Сценарій програми, в якому Web-контейнер містить Web-компоненти, які майже повністю обробляють логіку представлення цієї прикладної програми, ілюструє рис. 56. Передача динамічного Web-вмісту клієнта є завданням JSP-сторінок (підтримується сервлетами). EJB-контейнер містить компоненти, які, з одного боку, відповідають на запити з Web-рівня, а з другого, мають доступ до ресурсів EIS.

Рисунок 56 – Багаторівневий сценарій функціонування програмного забезпечення

Здатність ізолювати дані, що йдуть від кінцевого користувача,– перевага такого сценарію, оскільки прикладна програма неявно масштабована, але більш важливо, що офісна функціональність програми деякою мірою ізолюється від «look and feel» кінцевого користувача. Такий підхід має сенс, ураховуючи що XML включений як невід'ємна частина цього сценарію.

Здатність одночасно генерувати й опрацьовувати дані у форматі XML у Web-контейнері можна розглядати як дуже гнучку взаємодію з різними клієнтськими платформами, складність яких може бути різною, починаючи від універсального XML-підтримувального браузера закінчуючи спеціалізованою XML-генерувальної машини, орієнтованої на вертикальні рішення.

Незалежно від сфери застосування XML-дані передають через протокол HTTP. Терміном «передача даних XML» позначають модель програмування, у якій XML використовують для обміну інформацією замість застосування для цього об’єктної моделі, протилежної об’єктній моделі Java. Отже, XML можна розглядати як доповнення до мови Java.

На Web-рівні часто виникає запитання, що використовувати: JSP-сторінки або сервлети. Модель програмування J2EE використовує JSP-технологію, як основний засіб програмування у Web-контейнері. JSP-сторінки залежать від функціональності сервлетів, але модель програмування J2EE визначає JSP-сторінки як найбільш ефективний інструмент програмування для Web-інженерів, тому в Web-контейнері, спроектованому для створення динамічного вмісту для Web-клієнтів, використання технології JSP слід розглядати як норму, а використання сервлетів як виняток.

Сценарій незалежного клієнта. Сценарій, який використовує незалежного клієнта у процесі функціонування прикладної програми (рис. 57).

Рисунок 57 – Сценарій з використанням незалежного клієнта

У моделі програмування J2EE розглядають три типи незалежних клієнтів:

1. EJB-клієнти, які безпосередньо взаємодіють з EJB-сервером, причому корпоративні біни містяться в EJB-контейнері. Такий сценарій (рис. 58), у якому допускається використання RMI-IIOP і EJB-сервера, який буде звертатися до ресурсів EIS за допомогою JDBC (або конекторів).

Рисунок 58 – EJB-клієнти безпосередньо взаємодіють з EJB-сервером

2. Незалежні Java-клієнти, які звертаються до ресурсів EIS безпосередньо, використовуючи JDBC або конектори. У цьому сценарії логіка представлення та бізнес-логіка за призначенням розміщені на клієнтській платформі й можуть бути інтегровані в одну прикладну програму. Цей сценарій переміщує середній рівень на платформу клієнта й, по суті, є клієнт-серверним сценарієм програми, з усіма притаманними йому проблемами поширення, підтримки та оновлення.

3. VB-клієнти, які використовують динамічний Web-контент, що подається найчастіше у вигляді XML-даних. У цьому сценарії Web-контейнер керує XML-перетвореннями й забезпечує Web-зв’язок з клієнтами. Логіка представлення передається для керування на клієнтський рівень, а Web-рівень керує бізнес-логікою і прямим доступом до ресурсів EIS. В ідеалі, бізнес -логіка виноситься на EJB-сервер, де розвинена компонентна модель може її значно підсилити.

Сценарій трирівневої Web-прикладної програми. EJB-сервер є достатньо потужним інструментом для створення розподіленого програмного забезпечення. Специфікація J2EE не зобов’язує використовувати дво-, три- або багаторівневі моделі прикладних програм, тобто потрібно використовувати інструменти, які відповідають складності задачі. Сценарій трирівневої Web-прикладної програми нині дуже поширений; Web-контейнер фактично містить логіку представлення і бізнес-логіку, а за допомогою JDBC можна отри-мати доступ до ресурсів EIS. Сценарій функціонування трирівневої Web-прикладної програми (рис. 59).

Рисунок 59 – Сценарій трирівневої Web-прикладної програми

Використання Web-контейнера у сценарії функціонування Web-орієнтованих (рис. 60), у якому, варто враховувати, що термін «Web-контейнер» використано в дуже вузькому значенні.

Рисунок 60 – Web-контейнер у сценарії функціонування Web-прикладних програм

Наприклад, якщо такий продукт J2EE вибрано для реалізації, то у Web-прикладній програмі Web-контейнер і EJB-контейнер розміщені разом (тобто міжконтейнерна взаємодія оптимізована та деталі реалізації закриті), модель програмування J2EE використовує компоненти, встановлені на такій самій платформі, як за багаторівневим сценарієм.

Сценарій «Бізнес-Бізнес». Сценарій взаємодії бізнес-процесів у процесі функціонування Web-орієнтованого програмного забезпечення, який нази-вають «Бізнес-Бізнес» (рис. 61).

Рисунку 61 – Сценарій Бізнес-Бізнес

Цей сценарій акцентує увагу на міжрівневій взаємодії між Web- і EJB-контейнерами. Модель програмування J2EE пропонує використовувати XML-дані як головний засіб комунікації між Web-контейнерами, що зручно у разі розробки та розгортання комерційних рішень, в основу яких покладено Web. Міжрівневі комунікації між EJB-контейнерами в даний час найкраще рішення для Internet-середовища.