Logica e Session Beans

In questa sezione andremo ad occuparci delle Session Bean che gestiscono la logica del sistema e l’accesso alla banca dati.

Le session bean utilizzate sono tre PubSubLoggingBean, PubSubStoringBean e PubSubForwardingBean. Ognuna di queste session implementa la sua interfaccia remota; rispettivamente : PubSubLoggingRemote, PubSubStoringRemote e Pub- SubForwardingRemote. Di seguito analizzeremo ognuna di queste session bean e spiegheremo la logica al suo interno.

Nella session PubSubLoggingBean, si procede a salvare il messaggio in arrivo sulla banca dati nella tabella logging. Questa operazione consente di creare uno storico dei messaggi ricevuti dal sistema con una serie di operazioni che consen- tono di caratterizzare la tipologia di messaggio, il time stamp della ricezione e l’associazione con il client che ha prodotto il messaggio stesso.

Questa operazione qualora terminasse con successo restituisce l’identificatore della tupla che rappresenta il messaggio nella base di conoscenza.

Una nota va aggiunta sulla modalità di salvataggio del messaggio stesso: nel data base non viene salvato direttamente il DOM dell’XML, ottenuto dopo la ricezione, ma la corrispondente stringa.

Infatti per avere delle prestazioni migliori abbiamo preferito trasformare il DOM, utilizzato per la manipolazione del messaggio, in una stringa (UTF-8) e salvarla sulla banca dati, come flusso di byte.

In questo modo abbiamo evitato le onerose operazioni di serializzazione della classe DOM di Apache.

Dal punto di vista del codice sorgente Java questa Session Bean non mostra nessun aspetto particolarmente interessante.

Nella PubSubStoringBean si procede al salvataggio strutturato del messaggio ri- cevuto. Per salvataggio strutturato si intende la suddivisione del messaggio nei con- cetti elementari che lo compongono e successivamente, il loro relativo salvataggio sul data base.

Per ogni messaggio, in base al tipo, viene creato un Entiy Bean apposito che può essere uno dei seguenti:

• Advertisement: questo oggetto permette di salvare un messaggio di tipo advertise e consente il collegamento con i concetti fondamentali del messaggio stesso. Nel caso dell’operazione di advertise siamo in presenza di un unico concetto fondamentale: il namespace.

Al momento della creazione dell’oggetto Advertisement, viene estratto un entity Namespace che verrà poi collegato tramite il vincolo della relazione uno-a-molti all’oggetto Advertisement appena creato.

Dopo che la relazione tra le due entità è stata stabilita, l’Advertisement è salvato nella banca dati.

• Subscription: questo oggetto è utilizzato per salvare i messaggi di tipo Subscribe.

I concetti elementari contenuti in questo tipo di messaggio sono tre: il name- space, l’xpath e il valore. Quindi per ognuno di essi viene creato un oggetto rispettivamente Xpath, SubscriptionXpath e naturalmente Subscription. Questi oggetti collegati tra loro dalle relazioni che li accomunano vengono salvati sulla banca dati, prima del salvataggio viene estratto il Namespace corrispondente e associato al Subscription.

• Publish: l’oggetto Publish viene coinvolto nella fase di salvataggio dei mes- saggi di Notify che risulta essere la fase più complessa di tutte quante poiché coinvolge un grande numero di altri Entity Bean.

Oltre al Namespace è coinvolto anche l’oggetto Content con il quale viene salvato il contenuto effettivo del Publish, l’oggetto Subscription, l’oggetto Xpath ed anche l’oggetto Route.

L’Entity Bean Route viene utilizzato per creare una sorta di tabella di routing nella quale vengono associati destinatari e contenuto.

Nel caso dei messaggi di Publish viene eseguito una procedura detta di Replacement atta ad aggiornare eventuali versioni antecendenti del contenuto.

Nel listato seguente possiamo vedere il codice Java (semplificato) utilizzato per la fase di salvataggio di un messaggio di Publish.

1 p r i v a t e b o o l e a n s t o r e N o t ( D O M D o c u m e n t dom , L o n g Id ) t h r o w s j a v a . l a n g . E x c e p t i o n { 2 b o o l e a n r e p l a c e m e n t = f a l s e;

4.3 Logica e Persistenza 77 3 P u b l i s h pub = new P u b l i s h () ; 4 L o g g i n g log = g e t L o g g e r R e c o r d ( Id ) ; 5 pub . s e t L o g g i n g I d ( log ) ; 6 C l i e n t c l i e n t = log . g e t C l i e n t I d () ; 7 pub . s e t C l i e n t I d ( c l i e n t ) ; 8 S t r i n g url = n u l l; 9 try { 10 url = E J B U t i l s . s e t U r i ( dom . g e t R o o t E l e m e n t () . e l e m e n t (" N o t i f i c a t i o n M e s s a g e ") . e l e m e n t (" P r o d u c e r R e f e r e n c e ") . e l e m e n t (" M e t a d a t a ") . e l e m e n t (" A d d r e s s ") . g e t S t r i n g V a l u e () ) ; 11 } c a t c h ( E x c e p t i o n ex ) { 12 r e t u r n f a l s e; 13 } 14 N a m e s p a c e n a m e s p a c e = n u l l; 15 try { 16 n a m e s p a c e = ( N a m e s p a c e ) em . c r e a t e Q u e r y (" F R O M N a m e s p a c e n W H E R E n . uri L I K E (: uri ) ") . s e t P a r a m e t e r (" uri ", url ) . g e t S i n g l e R e s u l t () ; 17 } c a t c h ( E x c e p t i o n ex ) { 18 r e t u r n f a l s e; 19 } 20 pub . s e t N a m e s p a c e I d ( n a m e s p a c e ) ; 21 C o n t e n t c o n t e n t = new C o n t e n t () ; 22 D O M D o c u m e n t c o n t e n u t o = n u l l; 23 try { 24 c o n t e n u t o = E J B U t i l s . s t r i n g T o D o m ((( E l e m e n t ) dom . s e l e c t N o d e s (" / wsn : N o t i f y / wsn : N o t i f i c a t i o n M e s s a g e / wsn : M e s s a g e / n o d e () ") . get (1) ) . a s X M L () ) ; 25 } c a t c h ( E x c e p t i o n ex ) { 26 r e t u r n f a l s e; 27 } 28 c o n t e n t . s e t C o n t e n t ( c o n t e n u t o . a s X M L () . g e t B y t e s () ) ; 29 c o n t e n t . s e t N a m e s p a c e I d ( n a m e s p a c e ) ; 30 pub . s e t C o n t e n t I d ( c o n t e n t ) ; 31 X p a t h x p a t h = ( X p a t h ) n a m e s p a c e . g e t R e p l a c e m e n t X p a t h I d () ; 32 A r r a y L i s t l i s t = new A r r a y L i s t ( x p a t h . g e t A p p l i c a t i o n X p a t h L i s t () ) ; 33 A p p l i c a t i o n X p a t h ax = n u l l; 34 if ( l i s t . s i z e () == 0) { 35 r e p l a c e m e n t = f a l s e; 36 try { 37 em . p e r s i s t ( c o n t e n t ) ; 38 em . p e r s i s t ( pub ) ; 39 } c a t c h ( E x c e p t i o n ex ) { 40 r e t u r n f a l s e; 41 } 42 } e l s e { 43 I t e r a t o r i t e A p p l i c a t i o n = l i s t . l i s t I t e r a t o r () ; 44 w h i l e ( i t e A p p l i c a t i o n . h a s N e x t () ) { 45 ax = ( A p p l i c a t i o n X p a t h ) i t e A p p l i c a t i o n . n e x t () ; 46 if ( e x e c u t e X P a t h ( x p a t h . g e t S t a t e m e n t () , ax . g e t V a l u e s () , c o n t e n u t o ) ) { 47 r e p l a c e m e n t = t r u e; 48 b r e a k; 49 } e l s e { 50 try { 51 em . p e r s i s t ( c o n t e n t ) ; 52 em . p e r s i s t ( pub ) ; 53 } c a t c h ( E x c e p t i o n ex ) { 54 r e t u r n f a l s e; 55 } 56 } 57 } 58 } 59 L o n g id = c o n t e n t . g e t C o n t e n t I d () ; 60 if ( r e p l a c e m e n t ) { 61 id = d o R e p l a c e m e n t ( ax , n a m e s p a c e , c o n t e n u t o ) ; 62 if ( id == n u l l) { 63 r e t u r n f a l s e;

64 } 65 } e l s e { 66 em . f l u s h () ; 67 if (! i n s e r t A p p l i c a t i o n X P a t h ( pub , content , x p a t h ) ) { 68 r e t u r n f a l s e; 69 } 70 } 71 r e t u r n f o r w a r d ( id ) ; 72 } Listing 4.8: StoreNotify.java

Nella prima parte del codice fino alla riga 30 vengono creati gli Entity Bean necessari per l’archiviazione del messaggio ed in particolare un oggetto Publish nel quale verranno salvate appositamente le informazioni necessarie, un oggetto Namespace che viene recuperato dalla banca dati e un oggetto Content che servirà a salvare il contenuto effettivo del messaggio di Publish.

Dopo questa prima fase inizia il controllo per il Replacement. A partire dal namespace del contenuto viene recuperato un oggetto di tipo ReplacementXpath. Il ReplacementXpath consiste in un XPath associato al namespace che deve essere eseguito sul contenuto del messaggio.

Associato all’oggetto ReplacementXpath esiste anche una lista di valori che può essere vuota o meno. Se la lista è non vuota i risultati ottenuti vengono confrontati con quelli presenti, nel caso in cui la lista sia vuota l’operazione di Replacement termina.

Se i risultati ottenuti sono diversi da quelli presenti nella lista l’operazione termina; se invece i valori coincidono si procede ad aggiornare il contenuto presente sul data base con quello appena ricevuto.

In altri termini attraverso l’XPath di replacement si procede a controllare che il contenuto che si sta processando sia una nuova versione dei contenuti già presenti sulla banca dati, se così è i contenuti salvati in precedenza vengono aggiornati.

Questa parte di procedura viene eseguita nelle righe che vanno dalla numero 31 alla riga numero 70. Le procedure richiamate sono per il controllo e l’esecuzione dell’XPath (riga 46), la procedura di replacement alla riga 60 ed infine l’inserimento dei valori dell’XPath appena eseguito nella banca dati, (riga 67).

Quest’ultima operazione viene eseguita solamente nel caso in cui il replacement non sia necessario.

4.3 Logica e Persistenza 79

La procedura forward della riga 71 è molto importante e serve a creare l’as- sociazione tra client e contenuto. Dopo aver recuperato le sottoscrizioni per il namespace sul contenuto vengono eseguiti gli Xpath presenti nelle sottoscrizioni.

Se i risultati ottenuti coincidono con quelli specificati viene instanziato un nuovo oggetto Route, per creare la sopracitata associaziaone tra Subscriber e Content.

Il flag routed viene settato a false per indicare alla session di inoltro che il messaggio ancora non è stato inviato al client.

La procedura di forwarding viene richiamata anche nella procedura di Repla- cement, per preparare all’inoltro i contenuti appena aggiornati.

L’ultima Session Bean è la PubSubForwardBean che ha la funzione di andare a recuperare gli oggetti di tipo Route e controllare se sono da inoltrare oppure no. Questo controllo viene fatto consultando il flag dell’Entity Bean e se è settato a false il contenuto va inoltrato al rispettivo client. Al termine il flag va posto a true.

Questa operazione viene svolta ovviamente solo nel caso in cui il messaggio che ha attivato la catena di Service Engine è di tipo Publish.

Nel caso in cui il messaggio è di un tipo diverso la computazione termina dopo l’esecuzione del servizio del secondo engine, quindi la session PubSubForwardBean non viene richiamata.

Capitolo 5

Test e Performance

Introduzione

In questo capitolo tratteremo la fase di testing e i risultati ottenuti. In partico- lare abbiamo scelto di testare a fondo l’operazione di Publish in quanto operazione maggiormente invocata rispetto alle altre, in una tipica modalità di utilizzo del servizio. Il capitolo è stato suddiviso in quattro sezioni, dove si parlerà, rispettiva- mente, della configurazione dell’ambiente di test e dei test effettuati per accertare le performance e la robustezza del sistema.

5.1

Configurazione dei Test

I test sono stati eseguiti su un host Dell modello Optiplex SX280 dotato di due processori Intel Pentium 4 a 3.0 GHz e di 1GB di memoria RAM; il sistema operativo montato è Ubuntu versione 9.04 con kernel 2.6.28-15-generic.

La macchina virtuale Java utilizzata per i test è la versione 1.6.0_16 di Sun Microsystem, a cui erano riservati 768 MB di memoria RAM.

L’application server utilizzato è Glassfish nella versione 2.1 con OpenESB inte- grato; l’application server è configurato per mantenere un massimo di 600 connes- sioni alla banca dati e per gestire le connessioni HTTP secondo i parametri elencati sotto:

1 s e r v e r . http -s e r v i c e.c o n n e c t i o n- p o o l . max - pending - c o u n t = 4 0 9 6

2 s e r v e r . http -s e r v i c e.c o n n e c t i o n- p o o l . queue - size -in- b y t e s = 4 0 9 6

3 s e r v e r . http -s e r v i c e.c o n n e c t i o n- p o o l . receive - buffer - size -in- b y t e s = 4 0 9 6

4 s e r v e r . http -s e r v i c e.c o n n e c t i o n- p o o l . send - buffer - size -in- b y t e s = 8 1 9 2

5 6 s e r v e r . http -s e r v i c e. keep - a l i v e . max -c o n n e c t i o n s = 250 7 s e r v e r . http -s e r v i c e. keep - a l i v e . thread - c o u n t = 1 8 s e r v e r . http -s e r v i c e. keep - a l i v e . timeout -in- s e c o n d s = 30 9 10 s e r v e r . http -s e r v i c e. keep - a l i v e . c o u n t c o n n e c t i o n s - c o u n t = 1 8 6 9 11 s e r v e r . http -s e r v i c e. keep - a l i v e . c o u n t f l u s h e s - c o u n t = 0 12 s e r v e r . http -s e r v i c e. keep - a l i v e . c o u n t h i t s - c o u n t = 3 5 9 8 7 3 13 s e r v e r . http -s e r v i c e. keep - a l i v e . c o u n t r e f u s a l s - c o u n t = 1 4 2 8 14 s e r v e r . http -s e r v i c e. keep - a l i v e . c o u n t t i m e o u t s - c o u n t = 0 15 s e r v e r . http -s e r v i c e. keep - a l i v e . m a x c o n n e c t i o n s - c o u n t = 250 16 s e r v e r . http -s e r v i c e. keep - a l i v e . s e c o n d s t i m e o u t s - c o u n t = 30

Listing 5.1: Configurazione parametri HTTP

Per effettuare i test e prendere le misurazioni abbiamo utilizzato SoapUI in quanto JMeter non consente di invocare servizi web che fanno uso di attachments mime. SoapUI è un tool che consente, a partire da un file WSDL, di definire e implementare dei test su WebServices che fanno uso del protocollo SOAP via HTTP.

I test accertano le performance del sistema a fronte della ricezione di messaggi di tipo publish, in quanto l’operazione publish è l’operazione rilevante, sia come numero di invocazioni che come carico computazionale, per quanto riguarda i si- stemi di content notification. Ai fini di questo test abbiamo definito un publisher e un numero di subscriber che varia in base al tipo di test effettuato. I contenuti inviati si possono ripetere al fine di scatenare anche operazioni di aggiornamento delle versioni dei contenuti.

Per ogni invio di contenuti, SOAPUI colleziona il tempo dell’evento, il tempo medio di risposta, le transazioni per secondo e la dimensione del flusso di dati in termini di Kb/s.