5. Въведение в J2EE

1. 5. Въведение в J2EE Лекционен курс “Езици и среди за програмиране в Интернет” доц. д-р Станимир Стоянов катедра “Компютърни системи”

2. Съдържание 5.1. Java технология 5.2. J2EE архитектура 5.3. J2EE среда за изпълнение 5.4. Предимства на J2EE 5.5. Разработване, пакетиране и разгръщане на J2EE приложения

3. 5.1. Java технология • Комуникационни модели • Client/Server • Pure P2P (Peer-to-peer) • Hybrid P2P • Middleware • Generic services • Instance communication • Data access • Encodings • Resource control • APIs • Simple-to-reuse building blocks

4. The Java technology Работни станции PDA Сървъри cell phone ПК, лаптоп телефони Java 2 Enterprise Edition Net TV Smart phone Java 2 Standard Edition CDC CLDC Cards Java 2 Micro Edition Java Language

5. J2EE - Обща характеристика • J2EE (Java 2 Enterprise Edition) • Спецификация, която съществува от няколко години • Заменя няколко частни, нестандартни технологии като средство за изграждане на Web-базирани приложения • В момента – де факто стандарт.

6. Какво е J2EE? • Спецификация: • Разработена от Sun – съвместно с други водещи в областта на Интернет и middleware технологиите производители • Първа версия – в началото на 1999 г. • Актуална версия – J2EE 1.5 • http://java.sun.com/j2ee

7. J2EE включва: Програмни модели и поддържащи API интерфейси за различни изграждащи блокове за разработване на многослойни Интернет-базирани приложения, напр.: • JSP • Сървлети • Компоненти • ...

8. Корпоративни API интерфейси – предоставящи различни услуги, като напр.: • Транзакции • Именуване • Обмен на съобщения • Достъп до БД • ... Средата за изпълнение (run-time) поддържа J2EE-приложения, осигурява достъп до средства за реализиране на корпоративни API интерфейси.

9. Производители на J2EE-съвместими сървъри: • BEA – WebLogic Application Server • IBM – WebSphere • Sun-AOL – iPLanet • Borland – Borland Application Server • Iona – iPortal Application Server

10. 5.2. J2EE архитектура • J2SE – ядро на архитектурата, което предоставя всички стандартни Java средства • Неразделна част на J2EE • J2EE контейнери – предоставящи динамична поддръжка на J2EE-базираните приложения • Реализират специфични за тях API интерфейси

11. J2EE услуги – предоставят API интерфейси на услугите, включени в съответния контейнер • Тези интерфейси осигуряват някои от средствата, изисквани от J2EE приложенията • Други услуги включват: • достъп до БД • достъп до наследени системи и т.н. • Компоненти на J2EE приложенията • Включват бизнес-логиката на приложенията.

12. JSP машина JSP JVM JDBC W e b S e r v e r XML XML/HTML JavaMail Аплети JNDI Сървлет машина RMI Приложения Java Session Streams Sockets & Serialization IIOP CORBA EJB Server Менъджър сигурност Jini Протокол грешки Session Beans Entity Beans

13. 5.3. J2EE среда за изпълнение Платформата J2EE се състои от един или повече контейнери.

14. J2EE специфицира следните 4 типа контейнери: • Web контейнери - за изпълнение на Web приложения. Могат да се създават Web приложения с динамични интерфейси (посредством Java сървлети и JSP страници) • EJB контейнери – за изпълнение на разпределени компоненти (EJBs) • Аплетни контейнери – поддържат среда за изпълнение на аплети в Web браузъри. В момента са с ограничено използване.

15. Контейнери за приложни клиенти – за изпълнение на стандартни Java приложни клиенти • Приложения с графични потребителски интерфейси – AWT (Abstract Windowing Toolkit) и Swing • Други J2EE или не-J2EE приложения, използващи J2EE компоненти – за създаване на интегрирани системи.

16. 5.4. Предимства на J2EE • Управление на компонентите на приложенията • Достъп до компонентите на приложенията • Достъп до API интерфейсите на корпоративни услуги

17. Управление на компонентите на приложенията • J2EE приложенията са от страна на сървъра • Необходим е процес, който да ги “приютява” • Основното предназначение на контейнерите за изпълнение • да създават инстанции на компонентите на приложенията • Средата за изпълнение премахва необходимостта разработчиците да генерират сами инстанциите на различните компоненти на приложенията

18. Управление на компонентите на приложенията • J2EE контейнерите определят как и кога да създават инстанциите • в зависимост от типа на компонента и определена конфигурационна информация • J2EE контейнерите – сами определят как да се освободят от инстанциите, когато те изпълнят задачите си.

19. Достъп до компонентите на приложенията • J2EE приложенията – обикновено разпределени и отдалечени спрямо клиентите • Необходима комуникация и протоколи за връзка между тях • Средата за изпълнение на контейнерите – поддържа също така необходимите протоколи за клиентски достъп (напр. HTTP)

20. Компонентите на приложенията, разпределени в тези контейнери не трябва да се занимават с действителните протоколи • Вместо това контейнерите предоставят API интерфейс на по-високо ниво за реализиране на достъп до заявената информация. • Така компонентите не се интересуват как действително се осъществява комуникацията.

21. Достъп до API интерфейсите на услугите • J2EE интегрира различни съществуващи API интерфейси • стандартизирапрограмирането им • Добавя нови • напр. API интерфейси за поддръжка на XML • Очевидно предимство на стандартизацията • компонентите на приложенията не зависят от детайлите на реализацията

22. Могат да се използват вече реализирани услуги • J2EE специфицира метода за достъп на компонентите до услугите • Напр. връзка с БД, независимо от използваните драйвери • Това важи и при изпращане на електронна поща, обмен на съобщения, транзакции и др. • Администраторът на една J2EE платформа може да направи услугите достъпни за приложението по стандартен начин • J2EE средата за изпълнение • Оперира като портал за всички корпоративни услуги.

23. Какво означава всичко това за разработчиците? • J2EE дефинира ясна граница между: • компонентите на приложенията • средата за изпълнение • Средата елиминира зависимостта от частни API интерфейси и услуги • J2EE приложенията могат да бъдат използвани във всяка съвместима с J2EE контейнерите среда за изпълнение.

24. J2EE не специфицира естеството и структурата на средата за изпълнение • указвайки компонентите на приложенията и поведението на услугите, спецификацията предполага определено поведение на контейнерите. • Задачата на производителите на контейнери е да предостави съответстващо поведение.

25. 5.5. Разработване, пакетиране и разгръщане на J2EE приложения • Корпоративни приложения • J2EE – поддържа идеята за корпоративни приложения • Корпоративно приложение – съвкупност от Web и EJB модули, като всеки от тях се състои от един или повечефайла от тип: • .WAR (за Web приложения) • .JAR (за EJB)

26. Корпоративните приложения се пакетират във файлове с корпоративни архиви • .EAR • Всеки .EAR файл съдържа дескриптор за разгръщане • използва се за опаковане и конфигуриране на различни модули.

27. Разработване и разгръщане • J2EE приложенията са изградени от: • Java сървлети • JSP страници • EJBs • Разработването на типично J2EE приложение обикновено включва: • разработката на необходимите за приложението помощни Java класа • JSP библиотеки • допълнителни Java библиотеки и др.

28. Задачата по идентифициране на тези класове по време на проектиране и разработване е различна от тяхното разгръщане в J2EE платформата. • Типичен процес на разработка – поддържа обвързване на всички тези класове с дескриптор за разгръщане

29. Успешно разгръщане • всики необходими класове са направени достъпни за J2EE средата • Дескрипторите • така конфигурирани, че платформата да може да активира J2EE компонентите на приложението.

30. Пакетиране • За да се опрости процесът на разгръщане • J2EE специфицира един комплексен модел за приложения (от аспекта на корпоративни приложения) • Както подчертахме • едно корпоративно приложение представлява съвкупност от модули, всеки от които съдържа един или повече компонента от даден тип. • Всеки един от компонентите (Web, EJB, приложни клиенти) може да бъде пакитиран.

31. Пример Едно приложение е изградено от: • няколко EJBs • JSP страници • сървлети • няколко статични HTML страници • изображения

32. Те могат да се групират както следва: • Web модул – съдържа всичките • JSP страници • сървлетни класове • статични HTML страници и изображения • EJB модул – съдържа EJB класове

33. В J2EE: • Web модулите • пакетирани във Web архивни файлове (WAR) с дескриптор за разгръщане (web.xml) • EJB модулите • стандартни JAR файлове с дескриптор за разгръщане (ejb-jar.xml)

34. Java клиенти • JAR – файлове с дескриптор (application-client.xml) • Пакетираните модули могат да се композират в корпоративни приложения • корпоративните приложения също така могат да бъдат пакетирани в EAR (Enterprise Archive) с дескриптор за разгръщане (application.xml)

35. Web модул EJB модул (web.xml) (ejb-jar.xml) Модул за приложни клиенти Сървлети, JSPs, Статични HTML, Аплетни класове, Библиотеки с класове, ... EJBs, Асоциирани класове, Библиотеки с класове, ... (application-client.xml) Класове за приложни клиенти, Библиотеки с класове, ... Модел на J2EE приложения J2EE приложение ( application.xml)

36. Разработване на приложения според модела Разработката на едно приложение включва следните стъпки: • Разработване на компонентите на приложението • JSPs страници • Сървлети • EJBs • други асоциирани Java класове • Композиране на компонентите в модули • пакетиране на компонентите и приложните клиенти в съответни JAR и WAR файлове

37. Композиране на модулите в приложение • асемблиране на модулите в J2EE приложения • Разгръщане на приложението • последен етап, който обикновено включва указване на местоположението на EAR файла в J2EE платформата • Зависи от използваната конкретна платформа.

38. Ориентиран към роли модел • Доставчик на компоненти на приложения • Създават компонентите на приложението • Отговорността не надвишава пакетирането на различните компоненти в модули • Асемблатор на приложения • Асемблира модулите в приложение

39. Отговорник по разгръщането • Инсталира пакетираното приложение и го конфигурира за съответната J2EE платформа • Системен администратор • Отговорен за управлението и администрирането на приложението, след като е инсталирано и настроено.