Презентація на тему:
Платформа J2EE

Платформа J2EE 2007 (Курс “Інформаційні технології”) J2EE

Зміст Технологія Java. Напрямки J2ME, J2SE, J2EE. Платформа J2EE. Складові частини. Багаторівневі J2EE -системи. Загальна концепція контейнерів. Enterprise Java Beans (EJB). Використання EJB. Технологія Java Persistence. Object-Relational Mapping. Технологія Java Persistence у Java EE 5. Persistence provider. Класифікація EJB. Комбінування EJB. Поняття Session Beans та їх використання. Поняття Entity Beans. Entity Beans та Persistence. Відношення між Entity Beans. Кратність відношень, спрямованість відношень. Дескриптор розгортання (Deployment Descriptor) ejb-jar.xml. J2EE

Технологія Java™: Write Once, Run Anywhere Девіз технології Java™: “Write Once, Run Anywhere” (WORA). Незалежність від платформи (апаратної, операційної). Від smart-карт (JavaCard!) і мобільних телефонів до суперкомп'ютерів. Підтримка Internet-програмування (applets, servlets, JSP, Web Services). J2EE

Технологія Java™. Складові частини (найбільш загальний рівень) Технологія Java™ складається з двох елементів: мови програмування – Java та програмної платформи підтримки мови Java. Мова Java: об'єктно-орієнтована; строга типізація. Реалізація Java: компіляція у байт-код (bytecode); Java Virtual Machine (JVM): інтерпретація / динамічна (Just-in-Time) компіляція, динамічне завантаження класів; оптимізація (Java HotSpot ). Численні і багаті бібліотеки API (технології Java). J2EE

Технологія Java™. Ключові віхи історії та терміни (1/2) JDK SDK JRE Java 2 JDK – Java Development Kit (засіб розробки на Java) Починаючи з версії 1.3 замість JDK став використовуватися термін Standard Development Kit (SDK) Java Runtime Environment (JRE), середовище виконання Java – мінімальна реалізація віртуальної машини, що забезпечує виконання Java-додатків (не містить Java-компілятор та інші засоби розробки). Java 1.2 настільки перевершила Java 1.1, що була проголошена нова "ера" – ера Java 2. Java 1.0 (версія 1.0 мови Java )– 1995 (фінальна версія JDK 1.0 – січень 1996) Java 1.2 (фінальна версія – грудень 1998) – Java 2 J2EE

Технологія Java™. Ключові віхи історії та терміни (2/2) J2ME J2SE J2EE У червні 1999 р компанія Sun оголосила про поділ розвитку платформи Java 2 на три напрямки: Java 2 Platform, Micro Edition (J2ME); Java 2 Platform, Standard Edition (J2SE); Java 2 Platform, Enterprise Edition (J2EE). Причини поділу: полегшувався вихід на ринок і розвиток технології Java; платформа нараховувала декілька десятків різних специфікацій і бібліотек, а отже структуризація далеко не зайва. (Якщо у Java 1.0 різних класів і інтерфейсів нараховувалось трохи більше 200, то у Java 1.2 їх було вже біля 1800, а у Java 1.4 – більше2700). J2ME, J2SE, J2EE – червень 1999 J2EE

J2ME, J2SE, J2EE J2SE призначено для використання на робочих станціях і персональних комп'ютерах. (Standard Edition є основою технології Java та безпосереднім розвитком JDK (сам засіб розробки став називатися відповідно J2SDK чи просто SDK). J2EE містить засоби для створення складних, високонадійних, масштабованих серверних частин розподілених систем. Спрощена уява про Enterprise Edition: J2EE – це набір бібліотек, що підтримують розробку серверної частини ПС (і, перш за все розробку Enterprise Java Beans - EJB), плюс приклад реалізації відповідної платформи (на основі так званого сервера додатків EE - Application Server EE). J2ME є “обмеженням” Standard Edition з метою задовольняти жорстким апаратним вимогам портативних пристроїв,таких як кишенькові комп'ютери, стільникові телефони тощо. J2EE

J2ME та J2SE З J2ME у порівнянні з J2SE вилучені наступні можливості: типи float та double; метод Object.finalize(); Java Native Interface (JNI); Reflection API. Дві домінуючі конфігурації J2ME: Connected Limited Device Configuration (CLDC) та Connected Device Configuration (CDC). CLDC (Kilo Virtual Machine –– KVM) –– до 512 KB RAM; KVM: – не використовує JIT-компіляцію; CDC –– до 16 MB RAM. Обмеженість J2ME у порівнянні з J2SE часто виглядає умовною! Наприклад, клієнт Java Smart Ticket Demo може взаємодіяти з сервлетами та мати доступ до бізнес-логіки EJB (на сервері додатків J2EE) з можливостями залучення через JDBC API ланки EIS (інформаційної системи підприємства з базою даних). J2SE CDC CLDC J2EE

Платформа J2EE. Складові частини Специфікація J2EE (зокрема специфікація API J2EE, EJB, Application server). Еталонна реалізація до платформи J2EE. Пакет перевірки на сумісність сторонніх реалізацій. Технології розробки ПЗ на базі J2EE . Рекомендації з використання технологій J2EE. Специфікація Еталонна реалізація Пакет перевірки на сумісність Технології Рекомендації J2EE

Розвиток платформи J2EE Розподіл ринку між платформами за розрахунками аналітиків IBM (А.С.Деревянко, М.Н.Солощук – «IBM Technology Day в Киеве») J2EE

Платформа J2EE. Механізми та служби Взаємодія з клієнтом: JSP (Java Server Pages). Java сервлети. Web-служби. Бізнес-логіка (серверної частини): Enterprise Java Beans (EJB). (Специфікація EJB є серцевиною платформи J2EE). Базові служби (інтерфейси API): JNDI JTS JPA JTA JDBC RMI RMI/IIOP Java IDL JCA JMS JavaMail JAF У J2EE пропонується широкий спектр інтерфейсів API для уніфікованого доступу до сервісів (служб) та програм, реалізованих сторонніми організаціями J2EE

Багаторівневі J2EE -системи J2EE

Enterprise Java Beans (EJB) По суті EJB є специфікацією компонентної розподіленої технології, а сам термін Enterprise Java Beans (чи просто enterprise beans ) застосовується також для компонентів цієї технології (вони використовуються на сервері). Для зазначених компонентів разом з терміном EJB досить часто вживаються терміни розподілені біни, корпоративні біни, серверні біни. Важливо відрізняти розподілені біни від "звичайних" бінів. Останні можна розглядати як своєрідні аналоги ActiveX-компонентів. J2EE

Загальна концепція контейнерів Контейнер – програмний об'єкт, що виконується на сервері (сервері додатків) та створює середовище виконання для деяких програмних елементів. Контейнери можна розглядати як розвиток ідеї віртуальної машини (Java чи .Net): так само, як VM “від Вашого імені” займається (прозоро) управлінням пам'яттю (Вашої програми) , так і контейнер прозоро надає деякі сервіси “підшефним” елементам, зокрема компонентам EJB – надає сервіси транзакцій, безпеки, віддаленої взаємодії (remoting) тощо. Чотири види контейнерів у J2EE: контейнери додатків Java; контейнери аплетів; web-контейнери (містять сервлети та/або JSP – Java Server Pages); контейнери EJB. J2EE

J2EE- системи та контейнери J2EE

Контейнери EJB J2EE

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

До поняття масштабованості EJB-проектів. Application Server (з (*) Sing Li – Geronimo! Part 1: The J2EE 1.4 engine that could) Можна задати кластеру екземплярів Application Server Geronimo для виконання наступне завдання (команду): Надати Web-додаток "Pet Store" для 50000 клієнтів на годину у пікове навантаження із вказівкою у Service Level Agreement обмеження не менш 99% часу роботи (uptime) і не більш п'яти секунд на обробку одного замовлення до 15 червня. 15 червня знизити пікове навантаження до 10000 клієнтів на годину, обмеження SLA – 80% і 10 секунд на одне замовлення до серпня 31. Видалити Web-додаток 1 вересня. (*) www.ibm.com/developerworks/ library/j-geron1/index.html) J2EE

Сервери додатків (Application Servers) На ринку серверів додатків найбільш популярним є стандарт J2EE, призначений перш за все забезпечити портабельність проектів з одного J2EE-сумісного сервера на інший. Стандартом обумовлюються вимоги до можливостей даної категорії серверів та до їх продуктивності. Не в останню чергу саме завдяки цьому стандарту Java є найбільш популярною платформою для створення корпоративних проектів, підтримуваною багатьма головними виробниками програмного забезпечення. (Принагідно нагадаємо, що центральне місце у J2EE, займає концепція EJB, важливу роль у J2EE відіграє й концепція контейнерів.) Окрім J2EE-сумісних серверів існують й інші сервери додатків (у першу чергу від Microsoft: Enterprise Services з операційної системи Windows Server 2003, Microsoft Commerce Server, SharePoint Portal Server), які підтримують стандарти інтеграції додатків і в першу чергу стандарти Web-служб. J2EE

Application Server EE та EJB 3 Задачу розміщення EJB у контейнері називають розгортанням (deployment) EJB. J2EE

Cервери додатків J2EE Лідерами ринку серверів додатків масштабу підприємства (Application Servers J2EE ) є компанії IBM, BEA, Oracle. IBM WebSphere Application Server 6.0; BEA WebLogic Server 9.0 Diablo (сумісна зі специфікацією J2EE 1.4); Oracle 10g Application Server; JBoss Application Server (продукт з відкритим кодом) . Використовуються також сервери додатків від фірм Borland, Novell, Sun, Sybase. Sun Microsystems: Sun Java System Application Server GlassFish v2 (продукт з відкритим кодом, сумісність з Java EE5, більш того є еталонною версією Java EE5). Якщо перша версія GlassFish була призначена більше для розробників ПС, то друга є повноцінним сервером додатків корпоративного рівня. J2EE

Sun Microsystems. NetBeans IDE. Sun Java System Application Server J2EE

Використання EJB Найбільший ефект від використання технології EJB можна отримувати при вирішенні наступних проблем: забезпечення масштабованості розроблюваної системи; паралельний доступ для кількох клієнтів з дозволом модифікації даних; транзакційність розроблюваної системи (при використанні паралелізму до shared об'єктів); можливість використання клієнтів різних типів: тонких та товстих, віддалених та локальних, до того ж можливо чисельних та різноманітних за походженням; налаштування функцій безпеки, наприклад, впровадження обмежень на рівні операцій класів. J2EE

Java Persistence Architecture API (JPA) Додаткову гнучкість технології EJB надають такі можливості як персистентність (Persistence) та об'єктно-реляційне відображення (Object-Relational Mapping). Персистентність – це можливість об'єктні дані (дані entities) автоматично зберігати у реляційній БД, чим забезпечується їх постійне (довготривале) зберігання та актуальність. Персистентність підтримується JPA із використанням техніки Object-Relational Mapping (ORM). Головна задача – синхронізація даних EJB та БД J2EE

Object-Relational Mapping (ORM) ORM по суті визначає відображення об'єктних даних (станів) у пов'язані реляціями таблиці БД. Загалом техніка ORM звільняє розробників від потреби написання низько-рівневого, надокучливого та вельми непростого JDBC-коду. ORM є популярною концепцією. ORM-framework (ORM-каркас) дозволяє прозоро реалізувати персистентність, використовуючи спеціальні метадані OR-відображень (mappings). У EJB 2.1 ORM-framework з точки зору стандартизації виявився не зовсім завершеним. Прогалини у стандартизації призвели до появи кількох досить віддаляючихся одна від одної ORM-парадигм: Oracle TopLink (один з найперших каркасів); JBoss Hibernate (open source framework, один з найбільш популярних). J2EE

До історії J2EE (з (*) Barcia R. - Get to know Java EE 5) (*) www.ibm.com/developerworks/ websphere/library/techarticles/ 0707_barcia/0707_barcia.html J2EE

Java EE 5 EJB 3.0 Серед усіх технологічних розширень Java EE 5 найважливішою є специфікація EJB 3.0, значні синтаксичні зміни якої набагато спрощують розробку проектів з EJB. Значне спрощення (на рівні синтаксису) компонентів EJB; Значно спрощена об'єктно-реляційна модель персистентності. Plain Old Java Object (POJO) J2EE

Java Persistence Architecture API (JPA) Java EE 5. Persistence provider Провайдери персистентності (persistence provider), що можуть підключитись (plug in) в якості основи реалізації JPA : Hibernate (JBoss); TopLink (Oracle); Java Data Objects – JDO; Kodo (BEA). J2EE 1.4 Java EE 5 J2EE

Persistence provider Може «відокремлюватись» та застосовуватись для нерозподілених ПС (Desktop Application) J2EE

NetBeans IDE . Провайдери персистентності J2EE

Object-Relational Mapping (ORM). Для деяких EJB (а саме для Entity-бінів) можуть визначатись відношення на зразок one-to-one, one-to-many, many-to-one, many-to-many та така персистентність на основі Object-Relational mapping, що, наприклад, у реляційній базі Entity-бінам відповідають таблиці, а відношенням між бінами – відношення між таблицями. У J2EE 1.4 згадані відношення між корпоративними бінами задаються дескриптором розгортання (Deployment Descriptor– DD). Біни та відношення між ними, представлені у Deployment Descriptor, є спряженими з ER-схемою таблиць реляційної БД, проте відповідають більш високому рівню абстракції. Зауваження. ORM можна також задавати таким чином, що одному біну відповідатиме кілька таблиць, або навпаки, кільком бінам (а саме ієрархії бінів) відповідає одна таблиця. ER-схема EJB (а саме Entity-бінів!) ER-схема таблиць реляційної БД J2EE

Класифікація EJB Session Beans Найчастіше використовуються для реалізації деякої бізнес-логіки чи в якості фасаду інших серверних бінів; Entity Beans Основне призначення – забезпечити представлення даних у БД. Саме з ними пов'язуються персистентність та Object/Relational Mapping; Message-Driven Beans (історично з'явились пізніше за перші два типи). Можуть розглядатись як слухачі, підписувачі (listener, subscriber – у термінології JMS-технології ) асинхронних повідомлень. Java Message Service (JMS) API є одним з інтерфейсів J2EE. Загалом JMS підтримуються два способи передачі повідомлень: Point-to-Point та Publish-Subscribe (підписувачі-клієнти реєструються у видавця-сервера, який надсилає повідомлення зареєстрованим підписувачам; такий спосіб забезпечує більш слабу зв'язуваність між серверною та клієнтською частинами у порівнянні з Point-to-Point варіантом відправник-отримувач. J2EE

До класифікації EJB “Іменники” та “дієслова” J2EE

Комбінація EJB Часто різні варіанти EJB комбінуються: J2EE

Session Beans. Entity Beans. Зовнішнє (клієнтське) представлення Приклад. Session бін та Entity бін. Кожен має одну пару інтерфейсів для віддаленої взаємодії: Загальний випадок. Пара інтерфейсів (для взаємодії з іншого комп'ютера): віддалений (remote) інтерфейс, home-інтерфейс та/або пара інтерфейсів (для клієнтів, що виконуються на тій же JVM ): локальний (local) інтерфейс, локальний (local) home-інтерфейс. Забезпечується віддалений доступ Забезпечується локальний доступ (на тій же JVM) J2EE

Session Beans. Entity Beans. Визначення доступу через інтерфейси Клієнт може одержувати доступ до бінів тільки за допомогою методів, визначених в інтерфейсах біна. Усі інші аспекти біна, зокрема, реалізації методів інтерфейсів, установка дескриптора розгортання (Deployment Descriptor ), абстрактні схеми, засоби звертання до бази даних, тощо, приховані від клієнта. Для віддаленого клієнта місцезнаходження біна є прозорим. Для локального клієнта місцезнаходження біна не є прозорим, така непрозорість є засобом підвищення продуктивності: якщо у випадку віддалених викликів дані (параметри, return-значення) передаються “за значенням” (копіювання об'єктів забезпечується серіалізацією), то у випадку локальних викликів дані передаються “за посиланням” (як у звичайних викликах методів Java-класів). J2EE

Використання інтерфейсів EJB. Приклад клієнтської програми (фрагмент) Context c = new InitialContext(); Object remote = c.lookup("java:comp/env/ejb/cnvBean"); cnvRemoteHome rv = (cnvRemoteHome) PortableRemoteObject.narrow(remote, cnvRemoteHome.class); cnvRemote cnv = rv.create(); System.out.println("UAG --- "); System.out.println(cnv.USDtoUAG(3.0)); JNDI Home-”об'єкт” у ролі «фабрики» RMI Бізнес-метод Deployment Descriptor (фрагмент) J2EE

Виконання клієнтської програми J2EE

Session Bean. Внутрішнє представлення J2EE

Session Bean. Складові частини 1. Пара інтерфейсів: віддалений (remote) інтерфейс, home-інтерфейс та/або пара інтерфейсів: локальний (local) інтерфейс, локальний (local) home-інтерфейс. 2. Клас компонента (клас EJB-реалізації інтерфейсів EJB-компонента). (Тут використана назва EJB-реалізація, оскільки вона дещо відрізняється від стандартної реалізації Java-класом деяких Java-інтерфейсів). 3. Дескриптор розгортання (Deployment Descriptor - DD). J2EE

Session Bean. Основи використання Такий компонент не може використовуватись клієнтами спільно (shared), він відповідає сеансу одного клієнта. При завершенні сеансу бін не зберігається – його дані не записуються у БД. Два типи session бінів: зі станом (stateful) і без стану (stateless). Стан визначається полями екземпляра класа реалізації біна. Стан stateful-біна може зберігатись протягом усього сеансу, у stateless-біні стан може підтримуватись тільки в межах часу виконання окремого метода. Щоб звільнити частину основної пам'яті контейнер EJB може stateful-біни "переписувати" у вторинну пам'ять (це так звана пасивація бінів), а потім повертати в основну пам'ять, відновлюючи стан (це так звана активація біна, вона здійснюється контейнером, коли клієнт викликає метод біна). Усі екземпляри stateless-біна по суті еквівалентні, це дозволяє контейнеру EJB надавати будь-який екземпляр такого біна будь-якому клієнту. (Більш продуктивні у порівнянні з stateful-бінами). J2EE

Session Bean. EJB-реалізація (специфіка реалізації інтерфейсів EJB) public interface CalcHome extends EJBHome { Calc create() throws CreateException, RemoteException; } public class CalcEJB implements SessionBean, Calc { . . . public void ejbCreate() . . . Успадкований remove() “Класика” J2EE

Session Bean. Деякі вимоги до реалізації (1/2) Home-інтерфейс: має успадковуватись від javax.ejb.EJBHome; методи createXXX (їх має бути визначено не менше одного) мають бути спряженими з ejbCreateXXX у класі біна (у випадку stateless-біна метод один: з іменем create та без параметрів), спряженість також має місце для remove (він успадковується) та ejbRemote; вираз throws методів createXXX повинен включати java.rmi.RemoteException та javax.ejb.CreateException. Remote-інтерфейс: має успадковуватись від javax.ejb.EJBObject; вираз throws бізнес методів повинен включати java.rmi.RemoteException. J2EE

Session Bean. Деякі вимоги до реалізації (2/2) Клас біна: має реалізовувати інтерфейс SessionBean (SessionBean успадковується від EnterpriseBean, а той – від інтерфейсу Serializable). У проекті можуть не використовуватись методи ejbRemove, ejbActivate, ejbPassivate, setSessionContext з SessionBean, проте все одно клас біна повинен їх реалізовувати; повинен мати public конструктор без параметрів (екземпляри біна створюються контейнером та ініціалізуються завдяки спряженим методам createXXX- ejbCreateXXX; параметри віддалених бізнес-методів мають бути узгоджені з вимогами RMI. J2EE

Session Bean. Home-, та Remote- інтерфейси. Приклад package ejb; import java.rmi.RemoteException; import javax.ejb.CreateException; import javax.ejb.EJBHome; public interface cnvRemoteHome extends EJBHome { cnvRemote create() throws CreateException, RemoteException; } package ejb; import javax.ejb.EJBObject; public interface cnvRemote extends EJBObject, cnvRemoteBusiness { } package ejb; public interface cnvRemoteBusiness { double USDtoUAG(double USD) throws java.rmi.RemoteException; } J2EE

Session Bean. Клас біна. Приклад package ejb; import javax.ejb.*; public class cnvBean implements SessionBean, cnvRemoteBusiness { private SessionContext context; public void setSessionContext(SessionContext aContext) { context = aContext; } public void ejbActivate(){} public void ejbPassivate(){} public void ejbRemove() {} public void ejbCreate() {} public double USDtoUAG(double USD) { return (USD*5.05); } } J2EE

Session Bean. Deployment Descriptor (файл ejb-jar.xml) (1/2) Асоціюються інтерфейси з класом біна. Тип біна: session, Stateless. Транзакційний тип - Container-управління. J2EE

Session Bean. Deployment Descriptor (файл ejb-jar.xml) (2/2) Транзакційний атрибут (для кожного метода) - Required J2EE

Комбінування EJB Для кожного з так званих цільових Entity бінів наявність пари локальних інтерфейсів є обов'язковою. Фасадний Session бін забезпечує при необхідності клієнту віддалений доступ до бізнес-функціональності Entity бінів. Можуть бути розташовані на різних вузлах мережі J2EE

Entity Bean. Внутрішнє представлення ejbPostCreate() ejbLoad() ejbStore() J2EE

Entity Bean. Складові частини 1. Пара інтерфейсів: віддалений (remote) інтерфейс, home-інтерфейс та/або пара інтерфейсів: локальний (local) інтерфейс, локальний (local) home-інтерфейс. 2. Клас компонента (клас реалізації інтерфейсів EJB-компонента). 3. Клас первинного ключа (Primary Key Class). 4. Дескриптор розгортання (Deployment Descriptor - DD). J2EE

Entity Beans та Persistence Персистентність (persistence) – це функція забезпечення збереження актуального стану (даних) EJB у БД або, іншими словами, функція “синхронізації” стану EJB з представленням цього стану у БД (найчастіше реляційних БД) для довготривалого зберігання. Саме у забезпеченні persistence полягає головна роль Entity Beans , що використовуються у програмних проектах. J2EE

Entity Beans. Головний принцип J2EE Persistence Головний принцип J2EE Persistence – відокремлення проектування Entity Beans від проектування бази даних (у межах конкретної СУБД ). Спрощення розробки, портабельність – налаштування на конкретну СУБД здійснюється на етапі розгортання (deployment), спираючись на DD. Конкретні засоби: уведення спеціальних методів Entity Beans: ejbLoad() та ejbStore() (саме вони викликаються контейнером у випадку “автоматичної” персистентності); EJB QL – дуже спрощена “версія” SQL (забезпечується повне абстрагування find -та select- методів від конкретної БД). Імена беруться з “простору” EJB (імена абстрактних схем, імена персистентних полів), а не з “простору” БД. Подальший крок на шляху спрощення розробки проектів – використання провайдерів персистентності. find -та select- методи Entity Beans Оператори EJB QL (DD) Оператори SQL deployment J2EE

Entity Beans. Два механізми Persistence Bean-Managed Persistence (BMP) – управління «вручну», коли у програмному коді мають бути присутні фрагменти, що забезпечують необхідну синхронізацію. Container-Managed Persistence (CMP) – управління «автоматичне», яке не потребує додаткового коду для забезпечення необхідної синхронізації: у випадку, коли бізнес-метод асоційовано з транзакцією, перед його виконанням контейнер викликає ejbLoad(), а одразу після виконання – ejbStore(). J2EE

Entity Beans. Два механізми Persistence. Відмінності у кодуванні (“The J2EE™ 1.4 Tutorial “Sun Microsystems) J2EE

Варіант CMP . Відношення між Entity Beans. Container-managed relationships (CMR) Кратність відношення: one-to-one, one-to-many, many-to-one, many-to-many; Спрямованість відношення: односпрямоване (іноді навіть бажана “конфіденційність”: не доцільно надавати доступ до даних клієнта із даних замовлення), двоспрямоване. J2EE

Container-managed relationships (CMR). Приклад (RosterApp з “The J2EE™ 1.4 Tutorial “Sun Microsystems) Пунктирні стрілки відповідають можливому доступу шляхом використання JNDI-метода lookup J2EE

Entity Beans. Специфіка складу home-інтерфейсів create-методи: createXXX(...) (можуть бути й відсутні, оскільки екземпляри бінів можуть створюватись іншими засобами, наприклад, find-методами); find-методи: findYYY(...) обов'язково має бути findByPrimaryKey(primaryKey); remove-методи: removeZZZ(...); home-методи: деякий аналог статичних методів (home-метод не може застосовуватись до конкретного екземпляра біна, проте може обробляти сукупність екземпляри як ітератор. Найчастіше за допомогою find-метода спочатку отримується колекція екземплярів біна, яка потім ітеративно обробляється). Наприклад, можна створити home- метод для підвищення платні воротарям на якийсь відсоток (зрозуміло, має бути find-метод пошуку за ігровим амплуа – findByPosition). J2EE

Приклад (local-home interface for Player enterprise bean) package team; import java.util.Collection; import javax.ejb.*; public interface PlayerLocalHome extends EJBLocalHome { PlayerLocal findByPrimaryKey(String key) throws FinderException; public PlayerLocal create(String id, String name, String position, Double salary) throws CreateException; Collection findByPosition(String position) throws FinderException; Collection findAll() throws FinderException; . . . } J2EE

Приклад (local interface for Player enterprise bean) package team; import javax.ejb.EJBLocalObject; public interface PlayerLocal extends EJBLocalObject, PlayerLocalBusiness { } J2EE

Приклад (local business interface for Player enterprise bean) package team; import java.util.Collection; import javax.ejb.FinderException; public interface PlayerLocalBusiness { public abstract String getPlayerId(); public abstract void setPlayerId(String id); public abstract String getPosition(); public abstract void setPosition(String position); . . . Collection getTeams(); void setTeams(Collection teams); Collection getLeagues() throws FinderException; Collection getSports() throws FinderException; } Teams – поле відношення (CMR) з біном Team Бізнес-методи Методи доступу (get, set) до абстрактних персистентних полів PlayerId, Position, … є абстрактними персистентними полями (вони відображаються у поля таблиці) J2EE

Приклад (bean class for the PlayerBean enterprise bean) (1/4) package team; import java.util.Collection; import javax.ejb.*; public abstract class PlayerBean implements EntityBean, PlayerLocalBusiness { private EntityContext context; public void setEntityContext(EntityContext aContext) { context = aContext; } public void ejbActivate() {} public void ejbPassivate() {} public void ejbRemove() {} public void unsetEntityContext() { context = null; } public void ejbLoad() {} public void ejbStore() {} J2EE

Приклад (bean class for the PlayerBean enterprise bean) (2/4) public abstract String getPlayerId(); public abstract void setPlayerId(String id); public abstract String getName(); public abstract void setName(String name); public abstract String getPosition(); public abstract void setPosition(String position); public abstract Double getSalary(); public abstract void setSalary(Double salary); public abstract Collection getTeams(); public abstract void setTeams( Collection teams); Методи доступу (get, set) до абстрактних персистентних полів Методи доступу (get, set) до поля Teams відношення (CMR) з біном Team J2EE

Приклад (bean class for the PlayerBean enterprise bean) (3/4) public String ejbCreate(String playerId, String name, String position, Double salary) throws CreateException { if (playerId == null) { throw new CreateException( "The field \"id\" must not be null"); } setPlayerId(playerId); setName(name); setPosition(position); setSalary(salary); return null; } public void ejbPostCreate(String playerId, String name, String position, Double salary) { } ejbCreateXXX ejbPostCreateXXX (ejbPostCreateXXX використовується при потребі додаткової доінсталяції) J2EE

Приклад (bean class for the PlayerBean enterprise bean) (4/4) public Collection getLeagues() throws FinderException { PlayerLocal player = (PlayerLocal) context.getEJBLocalObject(); return ejbSelectLeagues(player); } public Collection getSports() throws FinderException { PlayerLocal player = (PlayerLocal) context.getEJBLocalObject(); return ejbSelectSports(player); } public abstract Collection ejbSelectLeagues( PlayerLocal p0) throws FinderException; public abstract Collection ejbSelectSports( PlayerLocal p0) throws FinderException; Бізнес-методи Абстрактні ejbSelect-методи. (Їх коди генеруються при розгортання на основі відповідних команд EJB QL) Бізнес-методи є “обгортками” відповідних ejbSelect-методів! J2EE

NetBeans. DD (ejb-jar.xml). “Майстри”. Абстрактні ejbSelect-методи ejb-jar.xml — 363 рядки, 13472 байти J2EE

DD (ejb-jar.xml). Фрагмент ejbSelectLeagues team.PlayerLocal select distinct t.league from Player p, in (p.teams) as t where p=?1 J2EE

NetBeans. DD (ejb-jar.xml) J2EE

DD (ejb-jar.xml). Фрагмент J2EE

DD (ejb-jar.xml). Фрагмент TeamBean Many TeamBean league league J2EE

DD (ejb-jar.xml). Фрагмент LeagueId One LeagueBean teams java.util.Collection teams J2EE

DD (ejb-jar.xml). Фрагмент J2EE

DD (ejb-jar.xml). Фрагмент Player playerId name position salary playerId J2EE

DD (ejb-jar.xml). Фрагмент auto generated method findByPosition java.lang.String SELECT OBJECT(p) FROM Player AS p WHERE p.position = ?1 J2EE

DD (ejb-jar.xml). Фрагмент TeamBean * Required J2EE

NetBeans. DD (ejb-jar.xml). CMR J2EE

NetBeans. DD (ejb-jar.xml) J2EE

NetBeans. DD (ejb-jar.xml) J2EE

NetBeans. DD (ejb-jar.xml) J2EE

Додаток J2EE

Мобільні телефони та технологія Java Як починалося: аналогові технології – у цілому задовольнялись потреби голосового зв'язку (проте окрім нього нічого не було). На основі Java-додатків користувачу надається багата анімаційна графіка, швидка взаємодія, можливість використання додатків у режимі оф-лайн (), і, головне, можливість динамічно завантажувати нові додатки. (Традиційно мобільні телефони постачаються з обмеженою кількістю встановлених додатків: годинник, календар, кілька ігор). Види Java-додатків, що можуть динамічно завантажуватись: двомовні розмовники, масштабовані мапи, служба "де я знаходжуся", гри, календарі (змагань, гастролей), анімація, робота з мелодіями, караоке, органайзери (закупівля, облік і планування ресурсів – бюджету, часу), конвертори валют, новини (загальні, фінансові), оптимізовані пошукові системи, годинник, що показує час у різних країнах світу тощо. J2EE

J2ME. Конфігурації та профілі Конфігурація по суті є специфікацією деякого класу портативних пристроїв, яка спряжена з віртуальною машиною JVM (повна або якимсь чином “урізана”) та з набором API, що може бути використаний пристроями цього класу. (Тут набір API, зрозуміло, розглядається як деяка підмножина API J2SE). Наприклад, конфігурація може бути розроблена для пристроїв з пам'яттю до 1024 KB, що мають тимчасове з'єднання з мережею. Профіль будується на основі конфігурації шляхом додавання спеціальних API для створення деякої завершеної оболонки для створення Java-додатків. (Найчастіше профіль містить API підтримки дружнього інтерфейсу користувача, персистенції, життєвого циклу). Дві домінуючі конфігурації: Connected Limited Device Configuration (CLDC) та Connected Device Configuration (CDC). J2EE

J2ME. Конфігурації та профілі (”дерево J2ME") Конфігурація CLDC призначена для невеликих мобільних пристроїв з тимчасовим з'єднанням з мережею: пейджеров, мобільних телефонів, Personal Digital Assistants (PDA). Mobile Information Device Profile (MIDP) - це перший завершений профіль (ISR 37); PDA Profile (PDAP ). Конфігурація CDC призначена для більш потужних (за об'ємом пам'яті та обчислювальними можливостями) пристроїв з постійним з'єднанням з мережею. Прикладами CDC-пристроїв є налагоджувальні вікна, інтернет-пристрої, а також PDA з розря- ду потужних (на зразок Sharp Zaurus). Foundation Profile (FP) базується на CDC і є основою декількох інших профілів. FP використовує фундаментальні API з J2SE, зокрема, використовує класи та інтерфейси з java.lang, java.io, java.util тощо. Java Specification Requests (JSR) розробляються шляхом Java Community Process (JCP). J2EE

Атрибути транзакцій Required RequiresNew Mandatory NotSupported Supports Never J2EE

Транзакції, керовані біном begin transaction commit transaction rollback transaction J2EE

sun-ejb-jar.xml J2EE