Architettura j2ee e webservices con ejb

 7 
realizzano infatti dei templates o dei moduli software personalizzabili per imprese diverse 
.Ma qui si vuole portare  avanti un  idea ancora piø forte: clienti diversi che acquistano 
da venditori diversi per formare e gestire la loro unica business application! Tutto ci  
potrebbe sembrare impossibile, per quanto detto sopra riguardo il software, ma in realt  Ł 
proprio il software che Ł cambiato e sta cambiando. Si potrebbe definirlo ora come un  
assemblaggio  di componenti diversi che riescono a comunicare e ad utilizzarsi a vicenda 
per l esecuzione di vari business services. 
Un componente Ł semplicemente un pezzo di codice in un linguaggio di programmazione , 
che implementa un ben definito set di interfacce verso il mondo esterno e che permette di 
gestire piø facilmente una porzione della Logic Application. 
Un componente pu  essere riusato in altri contesti , in altre business solutions ed essere 
utilizzato insieme a differenti componenti di altrettanti diversi produttori. 
Ad esempio, un componente per la gestione del prezzo di un servizio o di un prodotto  pu  
essere utilizzato da una compagnia di servizi postali o da un produttore di automobili per 
gestire e determinare dinamicamente il costo di un automobile o del servizio di spedizione 
in base a diverse condizioni come il tipo di cliente, il tipo di acquisto ecc  
Un possibile esempio di doppio utilizzo dello stesso componente Ł illustrato nella fig1 : 
 
 
Fig1 
L idea delle applicazioni basate su componenti  non va confusa assolutamente con la 
realizzazione di sistemi a componenti non portabili e non openness.  
In questa fase di transizione infatti molti produttori di software hanno iniziato a proporre 
delle soluzioni individuali di sviluppo a componenti su specifici Application Server 
 8 
impedendo al customer di combinare nel proprio sistema componenti  di differenti 
Application Server.. 
Successivamente ci si Ł resi conto che mancava un agreement, un accordo tra le parti , 
mancava , se si utilizza un termine piø consono al vocabolario informatico, un set di 
interfacce tra Application Server e componenti. Mancava uno standard , proprio come 
quello per i cd audio. Che successo avrebbero avuto questi ultimi se bisognava dotarsi di 
diversi cd player per avere la possibilit  di ascoltarli tutti? 
Tutto questo si riflette anche economicamente :piø venditori, piø concorrenza, prezzi piø 
bassi, piø domanda, maggior valore del prodotto. 
Quale azienda non vorrebbe acquistare e vendere in questo mercato. 
Oggi qualcuno ha finalmente inventato e pubblicato questo  standard , e chi poteva farlo 
se non la famosissima Sun , che ha realizzato JAVA, ormai conosciuto in tutto il mondo 
come un linguaggio universale per la realizzazione di sofware portabile !? 
La Sun ha definito una specifica , denominata J2EE , di cui si parler  piø avanti, che 
comprende tra i piø importanti lo standard di riferimento per la realizzazione di 
componenti Enterprise Java Beans(EJB). 
EJB definisce proprio un architettura a componenti per il deployment di business 
application server-side in java. 
EJB porta con se tre virtø fondamentali:  
1)Ł in sintonia con il mondo dell industria (tutti , dal customer  al developer , all impresa 
potranno beneficiarne) 
2)la portabilit  delle applicazioni Ł  molto  facilitata 
3)lo sviluppo del software Ł piø rapido (non si devono conoscere i vari middleware degli 
application server sul quale realizzare i componenti) 
 
Quasi inutile poi chiedersi perchØ EJB Ł stato implementato in JAVA, semplicemente 
perchØ i concetti di class e interface sono ormai noti al mondo dei programmatori Sun,  
perchØ Java Ł sostenuta da un  architettura potente, robusta, sicura, perchØ Java Ł cross-
platform (non sar  richiesto nessun altro investimento aggiuntivo pe r le imprese che non 
vogliono gettare via tutto il denaro speso per l acquisto di HW potente) 
Alternative come CORBA e .NET di Microsoft che propongono il managed di business  
components non sono comunque assolutamente da scartare. Infatti dopo l analisi di alcuni 
benchmark tra le varie tecnologie a confronto basate sulla solita architettura a tre livelli,  
nessuna di esse , si pu  dire, risulti vincitrice in manier a assoluta. 
 9 
1. .Net di Microsoft , con ASP e ADO.NET su sistemi operativi Windows e 
linguaggio di programmazione C,  sicuramente offrono una soluzione abbastanza 
performante, se si utilizza come metrica il numero di richieste che possono essere 
soddisfatte in un tempo limitato. D altra parte Ł una tecnologia che Ł vincolata dalla 
natura della macchina sulla quale gira. 
2. J2EE  , con EJB, JDBC sotto Linux(ma anche Windows) offrono una soluzione che 
con l aumentare del numero di richieste sicuramente non Ł tanto efficiente in 
termini di velocit  di risposta ma Ł certamente migliore in termini di rapidit  di 
sviluppo , di management e di portabilit . 
J2EE , se poi ci si trova a lavorare in un mixed environment Ł preferibile soprattutto 
perchØ le caratteristiche di sicurezza paltform-indipendent potrebbero riverlarsi 
senza ombra di dubbio piø potenti. 
3. Per quanto riguarda Corba, non si pensi ci sia molto da dire , semplicemente un 
tentativo di creare applicazioni ,su sistemi distribuiti, indipendenti non solo dalla 
piattaforma ma anche dal linguaggio. 
Questo se prima poteva sembrare l ultima frontiera per una portabilit  e 
compatibilit  globale si Ł poi rivelata una soluzione complessa, piena di specifiche 
e implementazioni difficili da comprendere anche per programmatori esperti. Un 
sistema ad oggetti che Ł stato trattato come un linguaggio object-oriented ignorando 
il fatto che gli oggetti comunicano soprattutto attraverso la rete. 
In realt  poi Corba alla versione 3.0 ha promesso compatibilit  con EJB .Si 
potrebbero avere quindi oggetti EJB e CORBA insieme sullo stesso sistema. 
 
Continuando ancora con EJB, questo standard, come si Ł gia anticipato Ł nato e si sta 
sviluppando per risolvere business problems e in particolare per: 
-migliorare la logica di business 
-migliorare l accesso al livello dati (se si utilizzano Database per lo storage dei dati , 
l utilizzo insieme con JDBC permette di liberarsi dal tipo di DB utilizzato ) 
-agevolare l accesso al Legacy System tramite JCA 
 
Si tenga ora come riferimento una delle architetture piø semplici , ma allo stesso tempo 
efficienti nel panorama dei sistemi informatici come quella in figura 2 sotto e si rifletta 
ancora su EJB. 
 10 
 
Fig2 
 
E  necessario specificare che gli EJB components non sono GUI components. La loro 
funzione principale Ł legata alla tecnologia server-side e  principalmente al livello Logico e 
dati. Sono completamente  estranei al livello presentazione. Di quest ultimo se ne 
occupano le tecnologie client-side come JSP,Servlet e JavaBean che trattano direttamente 
con end-user o business-partner. 
Ejb nasce per migliorare le operazioni su lato server, per eseguire algoritmi complessi e 
migliorare le business transactions. Ultimamente una delle funzionalit  piø interessanti per 
gli EJB Ł quella di WebServices Wrapper. Un EJB potrebbe gestire la logica di acquisto 
all interno di un application server di un  azienda (la intel ad ese mpio) che vende ad 
un altra (la Dell) prodotti (cpu) tramite transazioni sotto forma di WebServices, senza user-
interface.La figura 3 ne illustra lo schema : 
 
 
Fig.3 
 
 11 
Si spiegher   nella quarta parte cosa sono i WebServices e si proporr  come sia possibile 
implementarli con l architettura J2EE e quindi con EJB.  
E  interessante prima di addentrarci in dettaglio negli Enterprise Java Beans distinguere 
meglio questi ultimi da altri oggetti ,denominati JavaBean, presenti anche nell architettura 
Sun non enterprise (J2SE). I JavaBean  sono classi Java con metodi get/set riusabili per la 
realizzazione di applicazioni di tipo visuali. Sono development components , non hanno 
bisogno di vivere in un ambiente runtime, nŁ di essere instanziati,caricati o rimossi da 
un application server. Sono componenti che compongono un  applicazioni piø gr ande di 
cui Ł possibile poi il deployment. 
Gli EJB sono invece dei veri e propri deployment components che gestiscono ,forniscono 
un servizio e necessitano singolarmente di un runtime environment. 
 
In realt  gli EJB necessitano di un intero ecosistema per funzi onare ed essere gestiti.Un 
insieme di ruoli sono definiti nella specifica.La figura 4 illustra i vari actors e le 
funzionalit  di ognuno: 
 
Fig 4. 
 
Ultimamente si sta portando avanti  un nuovo ruolo chiamato Persistence Manager che 
avr  la funzione di mappare i business data in una storage unit , proprio come si mappano 
gli oggetti in un database relazionale. 
In questo lavoro di tesi Ł proposta una sintesi delle principali caratteristiche 
dell architettura J2EE , e della specifica EJB. Viene inoltre presentata l architettura dei 
Web Service, proponendo un particolare realizazione basata sull ut ilizzo di Enterprise Java 
Bean. PEr meglio esporre e rendere comprensibili gli argomenti trattati si fa riferimento ad 
un applicazione nel dominio bancario. 
 12 
Prima Parte :  J2EE e fondamenti di EJB 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 13 
Capitolo 1-L architettura J2EE 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 14 
J2EE, acronimo di Java 2 Platform Enterprise Edition , Ł un insieme di standard e 
tecnologie prodotte dalla Sun che comprendono diverse API distribuite e condivise tra i tre 
livelli fondamentali dell architettura : il livello client, il livello web, il livello business. 
 
In fig 1 Ł illustrata l intera architettura J2EE 1.4 dove Ł interessante notare i vari tipi di 
Container che gestiscono in livelli diversi i componenti Java e le novit  rispetto alla 
versione 1.3. 
La J2SE che si trova a livello 0 nei blocchi Ł la piattaforma java standard che contiene solo 
alcune delle API principali. 
 
fig 1 
Nella figura 2 si pu  ancora osservare l architettura J2EE con particolare riferimento 
all intereopereabilit  con il mondo esterno. 
 15 
 
Fig 2 
 
In questo elaborato si far  comunque riferimento alla versione J2EE 1.3. 
Seguir  ora la discussione sulle varie API J2EE. 
Le Api Standard( vers. 1.3) 
Provengono da J2SE e racchiudono: 
RMI : Remote Method Invocation 
JDBC : Java Database Connectivity 
 
Le Api Enterprise (vers 1.3) 
Cercando di non tralasciarne nessuna sono elencate di seguito le API J2EE: 
 
JSP: Java Server Pages 
SERVLET: Servlet API 
EJB: sono gli Enterprise Java Beans, ne parleremo in tutto l elaborato. 
JNDI: Java Naming and Directory Interface 
JDBC 2.0 EXT: : Java Database Connectivity Extensions 
RMI-IIOP:RMI over Internet Inter Orb Protocol 
 16 
JMS: Java Message Service 
JAVA MAIL  
JAF: Javabean Activation Framework 
JTA-JTS: Java Transaction Api , Java Transaction Service 
JAXP: Java API for XML Parsing 
JCA:J2EE Connector Architecture 
JAAS: The Java Authentication and Authorization Service 
JMX: Java Management Extension 
JAVA-IDL:Java to Interface Definition Language 
JSF: Java Server Faces (ultima tecnologia nel campo dei framework per la realizzazione di 
applicazioni web che si Ł deciso di non trattare in questa sede perchØ ancora in fase di 
testing)  
 
Ci si riferir  sempre alla versione 1.3 di J2EE e J2SE per  la descrizione delle API e delle 
tecnologie elencate sopra ,  poichØ l implementazione di queste Ł tuttora resa disponibile 
da i piø famosi AS presenti in giro. 
I punti di forza dell architettura J2EE che durante lo sviluppo di un AS si cerca di non 
trascurare sono ben sei: 
• Distribuibilit  
• Scalabilit  
• Sicurezza 
• Affidabilit  
• Portabilit  
• Transazionalit  
 
Tra i piø famosi AS commerciali troviamo Bea WebLogic Server , SiverStream 
Server,IBM WebSphere,Oracle OC4J e SUN J2EE(utile per gli sviluppatori) 
 
Ottimo ma non commerciale anche JBoss (Open Source) 
 
Per assicurare la portabilit  di tutte le nostre applicazioni J2EE Ł necessario affidarsi ad AS 
certificati scegliendo in anticipo la versione giusta di specifica. 
In questo elaborato ci si riferir  alla versione J2EE 1.3 e s i utilizzer  Bea WebLogic 8.1 
Server come AS. 
 17 
La specifica J2EE 1.3 fa riferimento alla specifica EJB 2.0 ma non tanto recente Ł l uscita 
della specifica EJB 3.0. 
 
Prima di procedere con una descrizione breve di ognuna di queste J-Tecnologie Ł proposto 
in fig 3 lo schema generale per livelli  J2EE: 
 
 
Fig 3 
 
Analisi delle API 
 
JNDI: 
 
 E  usato come Naming System per accedere a risorse sul sistema. Ricopre un ruolo molto 
importante in un AS, infatti tutte le operazioni tipiche che si possono compiere passano 
 18 
prima di tutto attraverso JNDI. L obiettivo Ł cercare di rendere trasparente l accesso ad una 
risorsa indipendentemente dalla sua locazione fisica. 
Esempi di utilizzo di JNDI: 
-Transazioni 
-Pool di connessioni a DB 
-Pool di connessioni transazionali a Database 
-Connettersi a JMS e utilizzare Queue e/o Topic 
-Connettersi ad EJB 
-Sicurezza 
 
JNDI si basa semplicemente sul concetto di tabella Hash. Nomi che identificano 
univocamente risorse. In figura 4 lo schema con le possibili implementazioni: 
 
Fig 4. 
 
Per l utilizzo di JNDI si scrive un  applicazione JAVA e tra mite le JNDI API ci si connette 
ad un Naming Manager , una sorta di registro che mantiene le associazioni nomi-risorse 
discusse in precedenza  e si effettuano lookup e bind per recuperare e collegare risorse. 
La JNDI SPI (Service Provider Interface) rappresenta invece il punto di ancoraggio di tutti 
gli oggetti che s intende rendere disponibili tramite il servizio di naming. 
 
 19 
JDBC: 
 
Un API per accedere a Database relazionali. Il punto di forza Ł l indipendenza 
dell applicazione java dal tipo di DB. Una volta a disposizione il driver JDBC fornito dal 
produttore del DB, il modo di accedere attraverso queste API  Ł sempre lo stesso, pertanto 
l applicazione diventa compatibile con tutti i DBMS. 
In figura 5 lo schema di funzionamento JDBC 2.0: 
 
Fig 5 
 
Un  applicazione java usa la classe  Driver Manager per accedere ad un driver JDBC che 
precedentemente si registra. 
I driver JDBC sono divisi in 4 classi: 
 
1. JDBC-ODBC Driver: sono driver da utilizzare per connettersi tramite ODBC ad 
altri DB. 
Questi driver sono gia disponibili sotto classi JAVA nella distribuzione J2EE e 
J2SE. 
2. Native-API partly- Java Driver: sono driver che si aspettano di trovare sulla 
macchina su cui sono utilizzati uno strato di software, scritto in un linguaggio 
nativo per quella macchina/piattaforma,che si preoccupa di connettersi al DB 
3. JDBC-Net pure JavaDriver: sono i driver che si aspettano di trovare un Gateway o 
in generale un server a cui connettersi che provvede a ritornare una connessione dal 
DB.(es.JDBC-RMI driver)