Prezentace se nahrává, počkejte prosím

Prezentace se nahrává, počkejte prosím

VÝVOJ PODNIKOVÝCH APLIKACÍ NA PLATFORMĚ JAVA EE Zbyněk Šlajchrt Část 1. 1.

Podobné prezentace


Prezentace na téma: "VÝVOJ PODNIKOVÝCH APLIKACÍ NA PLATFORMĚ JAVA EE Zbyněk Šlajchrt Část 1. 1."— Transkript prezentace:

1 VÝVOJ PODNIKOVÝCH APLIKACÍ NA PLATFORMĚ JAVA EE Zbyněk Šlajchrt Část 1. 1

2 Historické ohlédnutí – 5 revolucí  60. léta  První multitaskingový OS  70. léta  On-line pořizování dat  80. léta  Osobní počítače  SQL  90. léta  Client-server aplikace  Třívrstvé aplikace v druhé polovině desetiletí  2000  Java Enterprise Edition 2

3 60. léta  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 3

4 60. léta Zdroj: Zdroj: 4

5 70. léta  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í 5

6 80. léta  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 6

7 90. léta  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: 7

8 Přelom tisíciletí  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 8

9 Přehled Java EE  První specifikace , 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 9

10 Referenční implementace (RI)  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) 10

11 Compatibility Test Suite  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 11

12 APM Blueprint  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 12

13 Schéma Java EE aplikací Zdroj: 13

14 Typický scénář Zdroj: 14

15 Dosavadní certifikované implementace  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 15

16 Aplikační rozhraní v Java EE  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 16

17 Aplikační rozhraní – část 2.  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í 17

18 Aplikační rozhraní – část 3.  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 18

19 Aplikační rozhraní – část 4.  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 19

20 Aplikační rozhraní – část 5.  Java Naming and Directory Service (JNDI)  API pro přístup k adresářovým službám (např. LDAP)  Java Transaction API (JTA)  API pro řízení distribuovaných transakcí  JavaMail  API 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) 20

21 Aplikační rozhraní – část 6  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 ) 21

22 Aplikační rozhraní – část 7  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) 22

23 Kontejnery v Java EE  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 23

24 Klíčové pojmy  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 24

25 SoC - Separation of Concerns  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 25

26 SoC – Separation of Concerns  Příklad: Bankovní aplikace-Založení bankovního účtu  Příjem HTTP dotazu – dříve (procedurálně) 1. poslouchej na TCP portu analyzuj HTTP dotaz 3. přečti z konf. souboru parametry db připojení 4. otevři spojení 5. sestroj SQL příkaz pro založení účtu 6. zadej příkaz 7. vyhodnoť odpověď 8. ukonči spojení (commit) 9. předej odpověď klientovi Aplikace 26

27 SoC – Separation of Concerns  Příklad: E-Shop-Nákup  Příjem HTTP dotazu – dříve (procedurálně) 1. poslouchej na TCP portu analyzuj HTTP dotaz 3. přečti z konf. souboru parametry db připojení 4. otevři spojení 5. sestroj SQL příkaz aktualizaci skladu 6. zadej příkaz 7. proveď platbu kreditní kartou 8. ukonči spojení (commit) 9. předej odpověď klientovi Aplikace 27

28 SoC – Separation of Concerns  Příklad: Založení bankovního účtu  Příjem HTTP dotazu – oddělení zájmů 1. poslouchej na TCP portu analyzuj HTTP dotaz 3. přečti z konf. souboru parametry db připojení 4. otevři spojení 5. sestroj SQL příkaz pro založení účtu 6. zadej příkaz 7. vyhodnoť odpověď 8. ukonči spojení (commit) 9. předej odpověď klientovi Kontejner Aplikace (Business Logic) 28

29 Separation of Concerns ss Aplikace Kontejner

30 SoC – Separation of Concerns  Zpracování požadavku klienta 1. Příjem požadavku a příprava komponenty 2. Aplikační logika 3. 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í. 30

31 IoC – Inversion of Control  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) 31

32 DI - Dependency Injection  Řeší konfigurační aspekt IoC  nastavování parametrů, připojení a služeb  Dotaženo v Java EE 5  Inspirace: Spring, NanoContainer, Avalon A A B B C C new A() new B() A A B B C C new A() new B() new C() setB(B) setA(A) Container Tradiční styl: DI: 32

33 Lookup Service  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 A A B B C C lookup(A) lookup(B) Look up 33

34 Klientský kontejner  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 34

35 Kontejner appletů  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 35

36 Webový kontejner  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. 36

37 EJB kontejner  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. 37

38 Integrace s dřívějšími aplikacemi  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  38

39 Novinky v Java EE 6  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. 39

40 Novinky v Java EE 6 – část 2.  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 40

41 Novinky v Java EE 6 – část 3.  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 41

42 SunTone AM Methodology Převzato ze SUNTONE ARCHITECTURE METHODOLOGY A 3-DIMENSIONAL APPROACH TO ARCHITECTURAL DESIGN 42

43 SunTone AM Methodology  Architektonická metodologie pro vývoj mission- crtical 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 43

44 Tiers  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 44

45 Tiers - obrázek Převzato z 45

46 Layers  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, 46

47 Layers - obrázek  Příklad technologických vrstev v business tier Sun Blade X6440 – compute and storage layer Solaris 10 OS – enterprise service layer Hot Spot Java 6 - virtuální platforma Glassfish v3 – aplikační infrastruktura MyPetStoreApp EJB beans – aplikační vrstva EJB 3.1 – virtuální platforma CISCO Network Infrastructure 47

48 Systémové kvality  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) 48

49 Systémové kvality - příklady  Výkonnost  Spolehlivost  Dostupnost  Bezpečnost  Snadná správa  Testovatelnost  Realizovatelnost  Plánovatelnost  Škálovatelnost  Rozšiřitelnost  Flexibilita 49

50 Role ve vývoji Java EE aplikací  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 stránek a servletů  Application Client Developer  Application Assembler  Application Deployer and Administrator 50

51 Iterativní vývoj  Životní cyklus vývoje Java EE aplikací Vývoj JEE komponent Sestavení (assembly) Nasazení (deployment) Testy 51

52 Java EE programovací vzory  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 52

53 Java EE programovací vzory 53

54 SUN certifikace Zdroj: 54


Stáhnout ppt "VÝVOJ PODNIKOVÝCH APLIKACÍ NA PLATFORMĚ JAVA EE Zbyněk Šlajchrt Část 1. 1."

Podobné prezentace


Reklamy Google