Vývoj podnikových aplikací na platformě Java EE – Část 1.

Download Report

Transcript Vývoj podnikových aplikací na platformě Java EE – Část 1.

1
VÝVOJ PODNIKOVÝCH
APLIKACÍ NA PLATFORMĚ
JAVA EE
Část 1.
Zbyněk Šlajchrt
http://java.vse.cz/4it447/HomePage
Historické ohlédnutí – 5 revolucí
2

60. léta


70. léta



Osobní počítače
SQL
90. léta



On-line pořizování dat
80. léta


První multitaskingový OS
Client-server aplikace
Třívrstvé aplikace v druhé polovině desetiletí
2000

Java Enterprise Edition
60. léta
3


První multitaskingový OS vyvinutý IBM (MVT/MFT)
Mainframes, počítače řady IBM System/360
 8-bitové,
později kvůli finančním tlakům 6/4-bitové
 Děrné štítky
 Magnetické pásky s 9 stopami
 Diskové plotny po 7,25 MB (max 6), 85ms seek time,
156 kb/s transfer rate


Zpracování dat jednou denně dávkami psanými v
COBOLu – tzv. batch night cycles
Nevýhoda: data nebyla aktuální, opožděná o den
60. léta
4
Zdroj: http://en.wikipedia.org/wiki/IBM_System/360
Zdroj: http://www.columbia.edu/acis/history/cards.html
70. léta
5


Ve znamení on-line pořizování dat
IBM CICS – Customer Information Control System
 transakční
server pro mainframy
 terminálový přístup pro zadávání dat
 Assembler, PL/I, COBOL

IBM VSAM – Virtual Storage Access Method
 ukládání
dat a jejich indexace pro rychlé vyhledávání
 nezávislé na zařízení (tj. virtual)

Výhoda: data byla aktuální
80. léta
6



Počátek éry osobního počítače – Microsoft
Nahrazení zelených obrazovek terminálů IBM
SQL-86 – ANSI standard
 Zadávání
příkazů databázi jazykem blízkým
přirozenému
 Původ v jazyku SEQUEL, výzkum 70. léta v IBM
 1979 – Relational Software uvádí Oracle Database
 Následují DB2, Progres, Informix, Sybase
 Standard později upraven pro nedostatky – SQL-92
90. léta
7

Microsoft prosazuje klient-server aplikace
 Klient
zasílá požadavky na server prostřednictvím
počítačové sítě a čeká na odpověď
 Všechny údaje jsou uloženy na serveru - bezpečnost
 Snadnější úpravy a modernizace serverové části
 Nevýhody: snadno dochází k přetížení sítě, náchylnost k
výpadkům kvůli centralizaci, náročná správa verzí
klientských aplikací
Zdroj: http://cs.wikipedia.org/wiki/Klient-server
Přelom tisíciletí
8


Java Enteprise Edition - Sun Microsystems a další
definují standard pro vývoj distribuovaných
přenositelných aplikací
Navazuje na standardní Javu
write once, run everywhere
 JDBC API – transparentní přístup k databázím
 RMI –volání metod na vzdálených objektech


Přináší další, komponentové technologie
Enterprise Java Beans (EJB)
 Servlety, portlety a JSP stránky
 Webové služby
 Java Connector API – integrace s legacy aplikacemi

Přehled Java EE
9



První specifikace 1999-2000, verze J2EE 1.2
Další verze J2EE 1.3, 1.4, Java EE 5 a Java EE 6 (2009)
Obsahuje sadu specifikací pro jednotlivé oblasti vývoje
distribuovaných aplikací:
vývoj webových aplikací – servlety, portlety, JSP, JSF
 vývoj sdílené aplikační (business) logiky – EJB
 ukládání a získávání dat z databází – JPA, dříve entity
beans
 vývoj webových služeb
 asynchronní zpracování dat – Java Messaging Service
 integrace s legacy aplikacemi – Java Connector API

Referenční implementace (RI)
10




Aplikační server kompletně podporující poslední
specifikaci
Slouží především jako ukázka implementace nových
rysů (features) v poslední specifikaci
Není určen k nasazení do produkčního prostředí
Java EE 6 – referenční implementace GlassFish v3
 open-source
produkt (CDDL licence) firmy Sun
Microsystems (nyní součástí Oracle)
Compatibility Test Suite
11




Utilita, která ověřuje, že daná implementace je
kompatibilní se specifikací Java EE
Bez tohoto nástroje bychom neměli jistotu, že
implementace splňuje vše podle specifikace
Různí výrobci by si mohli specifikaci vykládat po
svém
To by vedlo k omezení výhod plynoucích z principu
write once, run everywhere
APM Blueprint
12




Application Programming Model Blueprint
Referenční příručka pro výuku vývoje
distribuovaných aplikací na platformě Java EE
V posledních letech ztrácí na důležitosti a
opodstatněnosti
Řada lidí je již z problematikou seznámena,
případně využívá jiných knih
Schéma Java EE aplikací
13
Zdroj: http://edndoc.esri.com/arcobjects/9.2/Java/java/server/enterprise_adf/intro_eadf.htm
Typický scénář
14
Zdroj: http://edndoc.esri.com/arcobjects/9.2/Java/java/server/enterprise_adf/intro_eadf.htm
Dosavadní certifikované implementace
15

Java EE 6




GlassFish v3 (RI)
Sun GlassFish Enterprise Server v3
TmaxSoft JEUS 7
Java EE 5











Sun Java System Application Server 9.0
GlassFish
JBoss Application Server
JOnAS
Apache Geronimo/Open EJB
IBM WebSphere
Oracle (BEA) Web Logic
Oracle Containers for Java EE 11
SAP NetWeaver Application Server
TmaxSoft JEUS 6
NEC WebOTX
Aplikační rozhraní v Java EE
16

Java Standard Edition (Java SE)
 Java

EE vychází ze standardní Javy
Java Database Connectivity (JDBC)
 Standardní
API pro jednotné připojování k databázím
bez ohledu na výrobce

RMI-JRMP
 RMI
– Remote Method Invocation, API pro volání metod
na vzdálených javovských objektech
 JRMP – Java Remote Message Protocol, nativní protokol
přenos zpráv mezi JVM
Aplikační rozhraní – část 2.
17

Java Interface Definition Language (Java IDL)
 Služba,
která umožňuje definovat Java rozhraní
prostřednictvím jazyka Interface Definition Language
 Součinnost s programy vyvinutými ve standardu CORBA

RMI/IIOP – RMI Over Internet Inter-ORB Protocol
 Umožňuje
použít RMI API pro komunikaci s CORBA
aplikacemi, které používají IIOP protokol

Enterprise Java Bean (EJB)

Komponentová architektura pro vývoj a nasazování
distribuovaných business aplikací
Aplikační rozhraní – část 3.
18

Servlets
 Komponenty
pro komunikaci s webovým klientem
 Komunikace probíhá ve stylu dotaz-odpověď
 V principu není omezena na HTTP protokol
 Náhrada CGI (Common Gateway Interface) skriptů

Java Server Pages (JSP)
 Šablony
pro dynamické webové stránky, např. HTML,
XML, WML

Java Standard Tag Library (JSTL)
 Standardní
knihovny tagů pro JSP stránky
Aplikační rozhraní – část 4.
19

Java Message Service (JMS)
 API
ke komunikaci s Message Oriented Middleware
(MOM)
 Topic – Publish/Subscribe
 Jedna
strana odesílá (publikuje) zprávu
 Příjemci jsou všichni, kteří se přihlásí k odběru
 Po předání zprávy odběratelům se obvykle maže
 Fronta
– FIFO (First In First Out), Point-to-point
 Jedna
strana vkládá zprávy do fronty
 Příjemce je právě jeden
 Zpráva čeká ve frontě, dokud si ji příjemce nevyzvedne
Aplikační rozhraní – část 5.
20

Java Naming and Directory Service (JNDI)
 API

Java Transaction API (JTA)
 API

pro řízení distribuovaných transakcí
JavaMail
 API

pro přístup k adresářovým službám (např. LDAP)
pro odesílání a přijímání elektronické pošty
JavaBeans Activation Framework (JAF)
 API
pro rozeznávání obsahu v libovolném vzorku dat
 Např. rozeznání formátu obrázku z dat (JPEG)
Aplikační rozhraní – část 6
21

Java Persistence API (JPA)
 ORM
framework, který umožňuje vývojářům spravovat
relační data v aplikacích
 Definuje Java Persitence Query Language (JPQL)
 Nahrazuje entity beans z dřívějších specifikací Java EE

Java Authorization Contract for Containers (JACC)
 Vyjadřuje
operace kontejnerů ve smyslu povolenek
řídících přístupy k prostředkům systému
(java.security.Permission)
Aplikační rozhraní – část 7
22

Java API for XML Web Services (JAX-WS)
 API
pro vývoj webových služeb
 založeno na anotacích

Java Architecture for XML Binding (JAXB)
 API
pro mapování javovských tříd do XML
 Umožňuje objekty ukládat do XML (marsall) a načítat je
zpět z XML (unmarshall)
Kontejnery v Java EE
23



Kontejnery poskytují podporu Java EE aplikačním
komponentám – komfortní vývoj aplikací
Komponenty používají metody a protokoly
kontejneru ke komunikaci s ostatními komponentami
a službami aplikačního serveru
Java EE zavádí čtyři druhy kontejnerů
 Klientský
kontejner
 Kontejner appletů
 Webový kontejner
 EJB kontejner
Klíčové pojmy
24

Separation of Concerns (SoC)
 oddělení
zájmů
 "sebestředné" komponenty

Inversion of Control (IoC)
 Aplikační
logika je pasivní, tj. čeká na událost (callback)
 Hollywood principle: "Don't call us, we will call you!"

Dependency Injection (DI)
 Aplikace
se nestará o získávání služeb, které potřebuje
 Kontejner injektuje závislosti do komponent
SoC - Separation of Concerns
25


Rozdělení programu do částí (komponent), jejichž
funkcionalita se pokud možno nepřekrývá a je úplná
Pozitivně ovlivňuje řadu tzv. systémových kvalit
 Udržovatelnost
(Maintainability) – snadná výměna
komponent
 Testovatelnost
 Škálovatelnost
 a další

Objektově orientované programování velmi
napomáhá tomuto procesu
SoC – Separation of Concerns
26


Příklad: Bankovní aplikace-Založení bankovního účtu
Příjem HTTP dotazu – dříve (procedurálně)
1.
2.
3.
4.
5.
6.
7.
8.
9.
poslouchej na TCP portu 80
analyzuj HTTP dotaz
přečti z konf. souboru parametry db připojení
otevři spojení
sestroj SQL příkaz pro založení účtu
zadej příkaz
vyhodnoť odpověď
ukonči spojení (commit)
předej odpověď klientovi
Aplikace
SoC – Separation of Concerns
27


Příklad: E-Shop-Nákup
Příjem HTTP dotazu – dříve (procedurálně)
1.
2.
3.
4.
5.
6.
7.
8.
9.
poslouchej na TCP portu 80
analyzuj HTTP dotaz
přečti z konf. souboru parametry db připojení
otevři spojení
sestroj SQL příkaz aktualizaci skladu
zadej příkaz
proveď platbu kreditní kartou
ukonči spojení (commit)
předej odpověď klientovi
Aplikace
SoC – Separation of Concerns
28


Příklad: Založení bankovního účtu
Příjem HTTP dotazu – oddělení zájmů
1.
2.
3.
4.
Kontejner
5.
6.
7.
8.
9.
poslouchej na TCP portu 80
analyzuj HTTP dotaz
přečti z konf. souboru parametry db připojení
otevři spojení
sestroj SQL příkaz pro založení účtu
zadej příkaz
Aplikace
(Business Logic)
vyhodnoť odpověď
ukonči spojení (commit)
předej odpověď klientovi
Separation of Concerns
29
Kontejner
9
8
66
7
Aplikace
ss
11
55
22
33
44
SoC – Separation of Concerns
30

Zpracování požadavku klienta
1.
2.
3.


Příjem požadavku a příprava komponenty
Aplikační logika
Finalizace a předání odpovědi na klienta
Body 1 a 3 se příliš nezávisí na aplikační
logice
Informace o aplikaci spravované kontejnerem
se zapisují deklarativně prostřednictvím
konfiguračního XML souboru nebo anotací.
IoC – Inversion of Control
31



Hollywood principle: "Don't call us, we will call you!"
Princip událostmi řízeného programování
(použito např. v knihovně Swing)
Aplikace principu SoC
 Nezabývej
se tím, jak otevřít připojení k databázi nebo
vyhledat službu pro ověření kreditní karty. Kontejner ti
nastaví vše, co potřebuješ. (Konfigurační aspekt IoC)
 Neřeš příjem požadavku z klienta ani čekání na zprávu
ve frontě. Kontejner tě zavolá, až přijde ta správná
chvíle. (Behaviorální aspekt IoC)
DI - Dependency Injection
32

Řeší konfigurační aspekt IoC
 nastavování

parametrů, připojení a služeb
Dotaženo v Java EE 5
 Inspirace:
Spring, NanoContainer, Avalon
Container
DI:
Tradiční styl:
A
new A()
new A()
A
C
B
new B()
setA(A)
C
new C()
B
setB(B)
new B()
Lookup Service
33


Alternativní metoda pro implementaci konfigurační
stránky IoC, kdy komponenta sama vyhledává
službu pomocí tzv. vyhledávací služby (Lookup
Service)
Využíváno v dřívějších verzích Java EE
lookup(A)
C
lookup(B)
A
Look
up
B
Klientský kontejner
34


Pro klientské aplikace psané v jazyce Java
Poskytuje tyto služby:
 Vzdálená
volání (RMI)
 Připojení k databázi
 Vyhledávací služba
 Např.
k vyhledávání databázových zdrojů, EJB a MOM
prostředků podle jména

Klientský kontejner obsahuje tato API:
 J2SE,
JMS, JNDI, RMI-IIOP a JDBC
Kontejner appletů
35



Poskytuje služby javovským appletům
Applet je program napsaný v Javě, který běží ve
webovém prohlížeči – kontejneru
Kontejner appletů musí poskytovat Java SE API
Webový kontejner
36




Poskytuje podporu servletům a JSP stránkám
Servlety a JSP stránky jsou komponenty pro
přípravu, zpracování a formátování dynamického
obsahu určeného k zobrazení
Zajišťuje bezpečnostní aspekty jako ověřování
uživatele a autorizaci přístupu uživatelů ke
stránkám.
Musí podporovat následující API:
 Java
SE, JMS, JNDI, JTA, JavaMail, JAF, RMI-IIOP, JDBC,
JPA ad.
EJB kontejner
37

Poskytuje služby pro:
 řízení
transakcí
 správu stavů komponent
 resource pooling
 bezpečnostní kontroly



EJB komponenty obsahují business logiku aplikace
Jsou jádrem distribuované aplikace
Kontejner musí poskytovat tato rozhraní:
 Java
SE, JMS, JNDI, JTA, JavaMail, JAF, RMI-IIOP, JDBC,
JPA ad.
Integrace s dřívějšími aplikacemi
38





Java Connector Architecture (JCA)
Je zapotřebí propojit Java EE aplikace s jinými,
které nejsou vyvinuty na platformě Java EE
Důležitá vlastnost Java EE významně přispívající k
jejímu rozšíření
JDBC hraje podobnou roli na poli databází
JCA má širší záběr:
 Mainframes,
SAP, Siebel, PeopleSoft, LDAP
 http://java.sun.com/j2ee/connector/products.html
Novinky v Java EE 6
39

Profily – podmnožiny technologií z Java EE ušité na
míru nějaké oblasti použití
 Web

Profile, Full Profile
WebBeans 1.0
 Sjednocuje
JSF, JPA a EJB3
 Inspirováno Seam, Google Guice a Spring
 Zjednodušuje práci s JSF

Java Server Faces 2.0 (JSF)
 Zavádí
tzv. facelets, alternativu k JSP
 Využívá anotací, podpora AJAXu
 Zabudovaná podpora pro obrázky, skripty, CSS atp.
Novinky v Java EE 6 – část 2.
40

EJB 3.1
 Singleton
beans – jediná instance v aplikace, thread
safe by default
 Plánování úloh v cron stylu (5 * * * ? *)
 Možnost volání session beanů asynchronně
 EJB 3.1 Lite – ořezaná verze pro webový profil

JPA 2.0
 Modelování
kolekcí, které nereprezentují relaci mezi
entitami
 Criteria API – umožňuje vytvářet dotazy objektověorientovaným a typově bezpečným způsobem
Novinky v Java EE 6 – část 3.
41

Servlet 3.0
Zavádí užitečné anotace, redukuje web.xml
 Fragmenty web.xml – jednotlivé moduly aplikace mohou
přispívat vlastním fragmentem
 Možnost programově přidávat servlety, filtry a posluchače
– usnadňuje práci webovým frameworkům


JAX-RS 1.1
REST alternativa JAX-WS
 REST – REpresentational State Transfer

URL reprezentují prostředky na webu
 Obsah prostředku představuje stav
 HTTP metody GET, POST, DELETE a další mají obecnější význam a
představují operace nad prostředkem

SunTone AM Methodology
42
Převzato ze SUNTONE ARCHITECTURE METHODOLOGY A 3-DIMENSIONAL APPROACH TO ARCHITECTURAL DESIGN
SunTone AM Methodology
43



Architektonická metodologie pro vývoj missioncrtical enterprise aplikací
Má svůj původ v RUP
Hlavní předměty zájmu v enteprise aplikacích
zobrazuje jako kostku, jejíž tři dimenze jsou:
 Tiers
- aplikační vrstva, list(?)
 Layers - technologická vrstva, sloj(?)
 Systémové kvality (bezpečnost, dostupnost...)

Řeší se systémové kvality pro všechny kombinace
tier vs. layer
Tiers
44






Popisují, jak je distribuovaná aplikace rozložená do
modulů kvůli redukci provázanosti a lepší pružnosti
Client tier – web browser, standalone Java application,
web service clients
Web presentation tier – přijímá HTTP požadavky a
odpovídá např. HTML, obsahuje servlety a JSP
Business logic tier – obsahuje moduly s business logikou,
typicky EJB
Integration tier – obsahuje moduly pro připojování a
komunikaci s Enterprise resource tier, typicky JPA, JMS
Enterprise resource tier – typicky non-Java systémy,
databáze a mainframy
Tiers - obrázek
45
Převzato z http://java.sun.com/javaee/5/docs/tutorial/doc/bnaay.html
Layers
46







Popisují, jak je distribuovaná aplikace implementována na
vrcholu infrastruktury platformy
Aplikační vrstva – obsahuje všechny aplikační moduly, vývoj
probíhá zde
Virtuální platforma – obsahuje rozhraní k modulům z vrstvy
Aplikační infrastruktura, definováno JCP
Aplikační infrastruktura – obsahuje middleware produkty,
databáze, aplikační servery
Enterprise service layer – typicky operační systémy
Compute and storage layer – hardware, disky, paměť,
procesory
Network infrastructure – síťová infrastruktura, karty, routery,
load balancers,
Layers - obrázek
47

Příklad technologických vrstev v business tier
MyPetStoreApp EJB beans – aplikační vrstva
EJB 3.1 – virtuální platforma
Glassfish v3 – aplikační infrastruktura
Hot Spot Java 6 - virtuální platforma
Solaris 10 OS – enterprise service layer
Sun Blade X6440 – compute and storage layer
CISCO Network Infrastructure
Systémové kvality
48



Vlastnosti systému, které tvoří základ kvality služeb
poskytovaných systémem
Různé systémové kvality mají odlišný vliv na celkový
design systému, občas protichůdný
Čtyři skupiny
 Manifest
qualities –interakce uživatele se systémem
 Operational qualities – vlastnosti běžícího systému,
které bezprostředně nedotýkají uživatele
 Developmental qualities – vlastnosti vývoje systému
 Evolutionary qualities – jak se systém chová, když je
třeba jej upravit nebo povýšit (upgrade)
Systémové kvality - příklady
49











Výkonnost
Spolehlivost
Dostupnost
Bezpečnost
Snadná správa
Testovatelnost
Realizovatelnost
Plánovatelnost
Škálovatelnost
Rozšiřitelnost
Flexibilita
Role ve vývoji Java EE aplikací
50

Velkou výhodou Java EE aplikací je, že přirozeně
vedou k rozdělení vývoje do rolí, ve kterých se
uplatňují lidé s odlišnými dovednostmi. Např.
 EJB
Developer
 Web Component Developer
 Grafik
 Programátor
 Application
stránek a servletů
Client Developer
 Application Assembler
 Application Deployer and Administrator
Iterativní vývoj
51

Životní cyklus vývoje Java EE aplikací
Vývoj JEE
komponent
Sestavení
(assembly)
Testy
Nasazení
(deployment)
Java EE programovací vzory
52



Sada ověřených řešení opakovaně se vyskytujících
problémů při vývoji Java EE řešení
Vycházejí ze zkušenosti Java EE komunity
Výhody:
 Ověřená
řešení
 Znovupoužitelnost (reusability)
 Navrženy s ohledem na lepší výkon
 ... a další systémové kvality (maintainability)

V tomto kurzu se budeme věnovat hlavním vzorům
Java EE programovací vzory
53
SUN certifikace
54
Zdroj: http://www.sun.com/training/certification/java/index.xml