Università degli Studi del Sannio

Transcript

1 Università degli Studi del Sannio Facoltà di Ingegneria Relazione di Fine Master SVILUPPO DI UNA APPLICAZIONE JAIN SLEE COMPLIANT Relatore Prof. Eugenio Zimeo Candidato Compagno Giancarlo Anno Accademico 2003/

2 Alla mia famiglia 2

3 Capitolo 1: Il Project Work Aziendale Introduzione Contesto di riferimento Strutturazione del lavoro Capitolo 2: JAIN SLEE Introduzione I Modelli di JSLEE Modello a componenti Modello ad eventi SBB Activity e Activity Context Resource adaptors Capitolo 3: Service Delivery Platform di riferimento Introduzione La SDP di riferimento Capitolo 4: L applicazione Delivery & Charging di SMS Introduzione L Architettura della applicazione JSLEE Scelte di progetto Il Sistema Proposto Il ruolo dell Activity e Activity Context Gestione degli eventi provenienti dall esterno Appendice A: La piattaforma J2EE...39 A.1 Introduzione A.2 La piattaforma Java 2 Enterprise Edition A.2.1 Enterprise Java Beans A Session Bean A Entity Bean A Message-Driven Bean A.2.2 Servlet A.2.3 Interazione tra J2EE e JSLEE Appendice B: Come installare l applicazione...50 B.1 Introduzione B.2 Materiale di supporto per L Application Server J2EE e il Client http B.3 Processo di installazione dell Application Server J2EE e del Client HTTP B.4 Materiale di supporto per L Application Server Rhino_sdk B.5 Processo di installazione dell Application Server Rhino_sdk Ringraziamenti...74

4 Capitolo 1: Il Project Work Aziendale 1.1 Introduzione Lo scopo di questo PWA è affrontare, attraverso la realizzazione di un prototipo di SDP (Service delivery platform) per il Delivery di Short Message, problematiche inerenti alle realizzazione di servizi per TLC, in particolare all ambito dei Servizi a Valore Aggiunto, utlizzando il paradigma di progettazione e programmazione delle specifiche JAIN SLEE. A tal fine si è potuto usufruire del contributo dell operatore telefonico Wind, attraverso le documentazioni fornite e l interessamento dimostrato per questo lavoro. L architettura di riferimento offerta da Wind, ha permesso di evidenziare alcune delle principali problematiche che presenta un prodotto come un SDP. Si è quindi cercato di realizzare un prototipo che corrispondesse alle interfacce della SDP fornita da Wind, concentrandosi sulla realizzazione di alcune funzionalità principali. I test svolti su tale lavoro sono stati di natura funzionale, e non prestazionale, in quanto non era questo lo scopo dell applicazione. Questa applicazione software ha come obbiettivo, quello di presentare una applicazione basata su specifiche JAIN SLEE. Per la realizzazione si è utilizzata l infrastruttura software JAIN SLEE compliant e la documentazione messa a disposizione da OpenCloud (compagnia alla guida, insieme a Sun, del working group che lavora alle specifiche JAIN SLEE). Il contesto di riferimento è il mercato italiano delle telecomunicazioni, che sta vivendo un intensa fase di

5 competizione tra operatori. Da un lato vi è infatti battaglia tra operatori fissi e mobili per le quote di mercato dei tradizionali servizi voce; dall altro entrambi i segmenti si sfidano nello sviluppo di strategie di crescita per aumentare l incidenza dei servizi a valore aggiunto (VAS). 1.2 Contesto di riferimento Per capire meglio quelli che sono i numeri e le motivazioni che spingono gli operatori di telefonia mobile verso la ricerca di nuove architetture per l implementazione e il rilascio di servizi a valore aggiunto, utilizzeremmo lo studio condotto dalla scuola di ingegneria gestionale del Politecnico di Milano sulla diffusione in Italia dei servizi, tramite i telefoni, Mobile VAS. Uno scenario complesso, del quale il Politecnico ha analizzato da un lato i principali fenomeni di trasformazione in atto e, dall'altro, ha tentato di delineare alcune possibili direzioni di sviluppo. Per servizi a valore aggiunto in realtà, sono semplicemente di tutte quelle applicazioni, differenti dal tradizionale servizio voce, che i possessori di telefonini utilizzano. Tra queste, SMS, MMS, video, giochi Java, suonerie polifoniche, screensaver e browsing su Internet. I semplici messaggi di testo, gli SMS, rappresentano ancora la killer application per i telefoni cellulare. Tuttavia, l'osservatorio, che ogni anno, a partire dal 2000, tiene sotto controllo il mercato, ha registrato una riduzione di quelle aziende che offrono servizi basati su questo media, che sono passate da 339 dell'anno 2002 a 143 dell anno

6 2003. Il fatto è dovuto principalmente all'interruzione di servizi basati sui cosiddetti dialer, quelli che si attivano tramite pc e che consentono di scaricare applicazioni una volta installato un software. La maggior parte dei servizi offerti dagli SMS, inoltre, oggi, è a pagamento (91%). Tra questi fondamentalmente gli utenti scaricano servizi di personalizzazione del proprio cellulare (loghi e suonerie) e di intrattenimento, tutti offerti più che altro dagli operatori di telefonia mobile (Telecom Italia Mobile, Vodafone Omnitel, Wind, 3). Figura 1.1: Tipologia di contenuto per gli sms

7 I contenuti più apprezzati sono l'infotainment (servizi che offrono informazione ed entertainment) e tutti quelli riconducibili sotto la voce Personalizzazione (loghi, suonerie e wallpaper). Il loro peso è, rispettivamente, del 34% e del 27%. Seguono, in terza posizione, i servizi di comunicazione e di community (chat, contenuti da inviare ecc., 17%). I giochi (15%) e i servizi di voting (4%) pure rappresentano quote interessanti. Se guardiamo alla tecnologia utilizzata, la maggior parte di questo mercato è costituito dai servizi basati su Sms (64%). Iniziano tuttavia a far sentire il loro peso altre tipologie di servizi, in particolar modo quelli di Micro-Browsing (20%) e i servizi di Download, in cui rientrano suonerie polifoniche, wallpaper, video e giochi Java (14%, di cui il 3% fa capo ai giochi Java). Gli MMS stentano ancora a decollare (2%) benché molti siano convinti che un domani saranno sfruttati per tutte le loro potenzialità, in particolare quelle legate al video. I servizi via MMS attualmente esistenti nel nostro Paese sono 101, contro i degli SMS e sono offerti quasi esclusivamente dagli operatori. Gli MMS sono tutti a pagamento e costano tra i quattro centesimi e i due euro. Forse è il costo ancora troppo elevato a indurre gli utenti a farne un utilizzo limitato. Il download di suonerie, screensaver, video e giochi Java, tutti servizi a pagamento, stranamente sta riscontrando grande successo. Sono i giochi disponibili, mentre solo 64 i servizi di suonerie e 50 di video. La maggior parte di questi servizi vengono attivati tramite telefono fisso e non via cellulare e costano tra i due e i sei euro

8 ciascuno. Ultimamente, però, vi si accede anche attraverso il mobile portal (come quello di 3, per esempio). E' proprio grazie al portale mobile che sono esplosi i servizi di browsing, basati cioè sulla navigazione dei portali di 3 e Vodafone Live! dell'omonimo gestore. I servizi di questo tipo nell'ultimo anno si sono triplicati, passando da 353 a Nel 2003 sono nati anche i primi servizi di consultazione a pagamento (14%), un obiettivo che gli operatori si erano prefissati fin dai tempi del Wap. Un altro trend in crescita nel corso del 2003 è stato l'utilizzo dei numeri brevi (es di TIM, di Vodafone ecc) da parte di molte aziende che offrono servizi via cellulare. Il numero breve è stato ampiamente sfruttato per iniziative di diverso genere, dal televoto, per esempio, al versamento di un contributo per venire in aiuto ai connazionali, e via dicendo. Un servizio in forte espansione nei prossimi anni, prevedono gli esperti. Il volume d'affari dei servizi a valore aggiunto è stimato a circa 400 milioni di euro, con un incremento del 61% rispetto al 2003 e un aumento del fatturato degli operatori di telefonia mobile del 100%. Il futuro è condizionato dall'evoluzione dei terminali, ai quali gli operatori imputano colpe e responsabilità per qualsiasi cosa non funzioni, e dal costo dei servizi che attualmente è troppo elevato perché sia sfruttato dalla massa. C'è ancora spazio per ulteriori applicazioni, come i sistemi di localizzazione (GPS) e lo sviluppo di servizi per le auto.

9 Figura 1.2: Mobile VAS Rapporto 2003 Intanto, però, ogni operatore ha e continua a credere nella propria filosofia, consentendo sì all'utente di scegliere la linea che più preferisce, ma creando al contempo, ancora più confusione dovuta alla mancanza di interazione e di compatibilità l'una con l'altra. Pertanto, Vodafone Omnitel ha e promuove il suo Vodafone Live!, un portale mobile che offre servizi a pagamento, un Wap abbellito, insomma. TIM punta su MMS e sul nuovo servizio di Tv sul cellulare - servizio che ha già sollevato polemiche per il timore di dover pagare un canone Tv per la visione di programmi televisivi sul cellulare -, mentre 3 regala il videofonino - la sua filosofia è cellulare gratis per tutti -per usufruire dei servizi video (videochiamata, videomessaggio, videogoal) che differenziano il quarto operatore italiano dai restanti competitor. Wind, infine, ha importato il sistema i-mode dal Giappone, puntando tutto sul traffico telefonico.

10 1.3 Strutturazione del lavoro Il lavoro svolto ha richiesto essenzialmente - una fase di studio delle API JAIN SLEE, cioè le API del Service Logic Execution Enviroment, l ambiente dedicato ad ospitare la logica dei servizi di cui verranno riportate le principali caratteristiche del modello di programmazione utilizzato da JAIN SLEE e le motivazioni che hanno portato alla sua definizione. - una fase di studio delle problematiche da prendere in considerazione durante lo sviluppo di una SDP utilizzando come spunto le soluzioni proprietarie di un operatore di TLC. - una fase per lo sviluppato un servizio di messaggistica, in particolare un servizio di gestione degli Short Message di tipo Application-To-Person, che tenesse conto di un contesto architetturale reale in cui potrebbe essere collocato, conforme alle specifiche JAIN SLEE, per poter testare da un punto di vista funzionale il modello di programmazione utilizzato da un Application Server JAIN SLEE compliant.

11 Capitolo 2: JAIN SLEE 2.1 Introduzione La nascita della piattaforma JSLEE deriva dalla esigenza degli sviluppatori di affidare, alcuni aspetti non strettamente legati all implementazione del servizio, ma dipendenti dalla natura intrinseca di servizio asincrono e con bassi livelli di latenza al Container. La piattaforma JSLEE, Jain Service Logic Execution Environmet, può essere basata su un Application Server standard come J2EE oppure su un AS proprietario specializzato in applicazioni di TLC o ancora può essere realizzato un AS compliant con le specifiche JSLEE. JAIN JSLEE è un set di specifiche Java pubbliche, facenti parte delle API JAIN. Come ogni prodotto basato su Java, un applicazione conforme alle specifiche JAIN SLEE segue la filosofia di Java Write Once, Run Anywhere La sua funzione è di importanza centrale in quanto esso costituisce l ambiente logico e di esecuzione in cui le applicazioni sono impiegate per utilizzare le varie risorse di rete definite da altre API JAIN. Le specifiche SLEE sono pensate per Application Server scalabili, che possano girare su un cluster al fine di migliorare le prestazioni e sostenere grandi carichi di lavoro. Le applicazioni possono così essere distribuite su più macchine, ma questo risulta del tutto trasparente allo sviluppatore, il quale dovrà preoccuparsi solo ed esclusivamente della 11

12 logica del servizio, mentre l ambiente si occuperà di tutto il resto. L ambiente gestisce tutti gli aspetti legati alle performance, alla concorrenza, alle transazioni, ai fallimenti, alla persistenza, all indipendenza dalla locazione, per cui gli sviluppatori non devono comprendere dettagli come il multi-threading, il connection-pooling e altre complesse API di basso livello, così che lo sviluppo di applicazioni sia il più semplice e veloce possibile. Il modello definito è un modello a componenti, per strutturare la logica applicativa dei servizi come una collezione di componenti object-oriented riusabili, e per poterli comporre in servizi di più alto livello e più sofisticati. Ciascun componente contiene solo la logica applicativa, mentre tutto il resto, compresa la gestione del suo ciclo di vita, è a carico del contenitore. Figura 2.1: I livelli dell architettura JAIN SLEE Il livello più alto è quello di gestione (management layer) e specifica il meccanismo tramite cui un amministratore gestisce l ambiente e i servizi (il ciclo di vita del sistema,

13 l installazione dei servizi nella piattaforma, la loro attivazione, etc.) e uno sviluppatore di servizi definisce dei dati necessari ad un particolare servizio. Al livello sottostante si trovano i servizi applicativi veri e propri, cioè i componenti e tutto ciò che li riguarda strettamente, in un contesto in cui l ambiente gestisce in automatico tutto ciò che serve alla loro esecuzione. Il livello sottostante è quello in cui sono collocate le componenti messe a disposizione dello sviluppatore da parte dell ambiente: questo comprende il servizio di routing degli eventi, un set di facilities, dei meccanismi per definire e utilizzare profili, etc. Al livello più basso ci sono i resource adaptors, che sono i componenti attraverso i quali è realizzata effettivamente l interazione tra le applicazioni e l esterno. I resource adaptors adattano le risorse esterne ai requisiti di SLEE, facendo in modo che queste comunichino con l ambiente tramite eventi e mettendo a disposizione delle applicazioni le API per comunicare con le risorse esterne. In tal modo si realizza l indipendenza del modello di programmazione dal particolare protocollo di rete, dalla particolare API o topologia di rete. 2.2 I Modelli di JSLEE La definizione delle richieste sotto forma di eventi ha permesso di progettare e ottimizzare le specifiche di SLEE per applicazioni orientate agli eventi. La differenza tra sistemi orientati agli eventi e sistemi così detti enterprise ha motivato la definizione delle specifiche JAIN SLEE nell ambito del Java Community Process.

14 Queste differenze hanno portato alla definizione delle caratteristiche principali di JAIN SLEE: - Modello a componenti - Modello ad eventi Il modello a componenti di SLEE richiama il modello degli Enterprise JavaBeans, EJB, ma, oltre alla fondamentale differenza che la programmazione degli EJB non è basata su eventi, SLEE non ne eredita tutte le caratteristiche della J2EE poiché deve essere un ambiente leggero, specializzato in elaborazioni veloci, a bassa latenza e ad alte prestazioni che non richiedono le complete funzionalità offerte dalla piattaforma Enterprise Modello a componenti Il principio fondamentale su cui si basa il modello a comportamento è la possibilità di definire e comporre servizi semplici per realizzare servizi complessi. Con tale approccio è possibile riutilizzare e estendere facilmente i servizi semplici per comporre servizi nuovi. Un componente in SLEE, che permette di implementare un servizio, è chiamato Service Building Block (SBB) ed è ospitato da un contenitore, il quale a tempo di esecuzione si occupa della gestione del suo ciclo di vita, dell interazione con le risorse esterne e degli aspetti che riguardano la concorrenza, la sicurezza, la persistenza e le transazioni. Affinché l ambiente possa fornire questo supporto, l SBB deve rispettare precisi vincoli di programmazione (ad esempio deve implementare una specifica interfaccia, la sintassi

15 dei nomi dei metodi che gestiscono gli eventi deve rispettare un particolare formato etc.) e deve essere accompagnato da un deployment descriptor (un file XML conforme ad una specifica DTD), destinato a contenere delle informazioni che servono all ambiente nel momento in cui avviene l installazione del componente per poter generare il codice che implementa la logica di supporto. Un applicazione è realizzata componendo un insieme di SBB, e mostra verso l esterno un interfaccia costituita dal set di eventi che essa è in grado di gestire tramite i suoi componenti. Chiaramente ciascun SBB può essere composto con altri in modo diverso, e questo permette un riuso facile dei componenti preesistenti e lo sviluppo veloce di servizi nuovi tramite la composizione di vecchie componenti con altre, eventualmente sviluppate ad hoc Modello ad eventi Un SBB è in grado di riceve e gestire richieste che si presentano sotto forma di eventi, che contengono informazioni legate alla sorgente dell evento. Ogni SBB è in grado di gestire gli eventi di cui è a conoscenza e per il quale è legato una richiesta di elaborazione. Gli eventi sono inoltre utilizzati dagli SBB per comunicare tra di loro in modalità asincrona. Quindi ciascun SBB è in grado di gestire un certo insieme di eventi, tramite dei metodi appositi, ed è in grado di generare un altro insieme di eventi. Un applicazione basata su eventi tipicamente non ha un thread di esecuzione attivo ma ha dei metodi che sono invocati quando occorrono gli eventi ed un handler che riceve tutti gli eventi e, tramite un ampia sezione di switch, smista il particolare evento occorso in

16 base al tipo di evento. Nel caso di SLEE esiste un event router che, in maniera del tutto trasparente, si occupa dello smistamento degli eventi ai consumatori che dovranno gestirli; lo smistamento consiste nell invocazione del metodo, di ciascun consumatore, dedicato alla gestione dell evento. Il modello ad eventi utilizzato da SLEE è del tipo publish/subscribe (simile a quello utilizzato da JMS), in base al quale un entità che si sottoscrive per ricevere gli eventi di un certo tipo, riceverà automaticamente questi eventi nel momento in cui un altra entità li pubblica. La caratteristica fondamentale del modello publish/subscribe è il forte disaccoppiamento che c è tra il produttore e il consumatore dell evento. 2.3 SBB Ogni SBB identifica una componente di servizio che è caratterizzata principalmente dal tipo di eventi che è in grado di gestire e dal tipo di eventi che è in grado di generare. Per ciascun evento che è in grado di gestire possiede un metodo handler ad hoc, che implementa la logica da eseguire in seguito all occorrenza dell evento; per ciascun evento che è in grado di generare ha un metodo astratto che sarà poi implementato automaticamente dal sistema in fase di installazione. Un SBB può avere anche un interfaccia locale, che specifica un insieme di metodi invocabili sincronamente dall istanza di un altro componente SBB interno allo stesso albero di istanze (vd. Paragrafo successivo). E importante distinguere tra SBB Entities e SBB Objects:

17 - Una SBB Entity è una istanza di un componente SBB; è una entità logica, che rappresenta lo stato persistente di un SBB (tramite i campi CMP, Container Managed Persistent) e che mantiene le relazioni con le altre entità. La sua rappresentazione potrebbe essere nella memoria del processo in esecuzione, in una memoria replicata, in un disco di storage, etc. - Un SBB Object è un istanza di una classe astratta SBB; è un oggetto Java che si può trovare in diversi stati del suo ciclo di vita (ad es. not exist, pooled e ready). Esso è legato ad una particolare SBB entity per la durata di una invocazione di metodo, nella quale opera per conto della SBB entity e può accedere al suo stato persistente (come se facesse da cache), ma dopo l invocazione del metodo è possibile che l SBB entity esista ancora ma che non abbia un SBB object legato ad essa. Più SBB objects possono rappresentare la stessa SBB entity, ma, pur potendo risiedere nella stessa JVM o in JVM diverse, essi devono operare sulla stessa SBB entity. 2.4 Activity e Activity Context Un Activity è l astrazione di un flusso di eventi generato da una risorsa; questi eventi occorrono in seguito al cambiamento dello stato interno all entità o alla risorsa. Per esempio una chiamata telefonica può essere un Activity. n oggetto Activity è un oggetto Java che può generare eventi e che può mettere a disposizione metodi da usare per interagire con l Activity stessa; tipicamente esso rappresenta una risorsa esterna, infatti ciascun tipo di resource adaptor può definire uno o più tipi di oggetti Activity. Per esempio, un oggetto JccCall è un oggetto Activity che rappresenta una chiamata

18 telefonica (che è l Activity). Un Activity Context è un entità logica all interno di JSLEE che rappresenta ed incapsula al suo interno un oggetto Activity sottostante. Esso funge da bus, su cui vengono generati e da cui vengono ricevuti gli eventi e conserva implicitamente le relazioni tra i produttori e i consumatori che interagiscono con esso. Gli SBB consumatori si sottoscrivono per ricevere gli eventi attaccandosi ad un Activity Context; per cui se un certo SBB gestirà eventi relativi a quel particolare Activity Context 2.5 Resource adaptors Per permettere a SLEE di comunicare con l esterno, (come già avviene per l Application Server J2EE) la platform mette a disposizione una serie di resource adaptors che adattano le risorse esterne ai requisiti di SLEE: la comunicazione dall esterno verso SLEE avviene tramite la generazione di eventi a seguito dei cambiamenti dello stato della risorsa e tramite la consegna di questi eventi all event router; nel senso opposto avviene tramite l invocazione da parte dell applicazione dei metodi messi a disposizione dalla risorsa per usufruire delle sue funzionalità. Esistono diversi tipi di risorse, diverse implementazioni di ciascun tipo e possono essere rese operative in SLEE diverse istanze di uno stesso tipo di risorsa; a tal proposito definiamo i seguenti concetti: - Resource adaptor type: definisce le caratteristiche comuni ad un insieme di resource adaptors, cioè definisce le interfacce Java implementate dai resource adaptors dello stesso tipo e i tipi di eventi generati dai resource adaptors dello stesso tipo.

19 - Resource adaptor: è un implementazione di un resource adaptor type (possono esistere più implementazioni dello stesso resource adaptor type). Un resource adaptor consiste di un insieme di classi Java e di un deployment descriptor. - Resource adaptor entity: è una istanza di un resource adaptor. Possono essere istanziate più istanze dello stesso resource adaptor nella stessa piattaforma. La funzione importante del resource adaptor entity è di propagare a SLEE un evento originato dalla risorsa che rappresenta.

20 Capitolo 3: Service Delivery Platform di riferimento 3.1 Introduzione La applicazione che si è implementata è quella relativa alla gestione del servizio di Short Message di tipo application-to-person. La scelta di implementare questo tipo di servizio deriva dalla necessità di realizzare un sistema concettualmente semplice che servisse principalmente a testare le specifiche JAIN SLEE da un punto di vista funzionale. Il modello di programmazione di JSLEE è ottimizzato per applicazioni nell ambito delle telecomunicazioni, per cui la versione commerciale di un AS conforme ad esse, dovrebbe garantire delle performance migliori rispetto agli AS attualmente utilizzati L implementazione a disposizione è stata fornita sotto Non Disclosure Agreement da Open Cloud, l azienda che, insieme a Sun, è alla guida del gruppo di esperti che ha definito le specifiche JSLEE. Questa versione non può essere utilizzata in un ambiente operativo reale, ma hanno il solo scopo di rendere possibile lo sviluppo di un servizio testandone il comportamento da un punto di vista funzionale. L implementazione che è stata utilizzata è la Rhino_Sdk, Rhino Single node Development Kit. Rhino è il nome dell implementazione commerciale di Open Cloud della piattaforma JSLEE 20

21 Tale piattaforma mette a disposizione dei Resource Adaptor aggiuntivi rispetto alla JSLEE Reference Implementation, in particolare il RA per J2EE. 3.2 La SDP di riferimento L infrastruttura utilizzata come riferimento per lo sviluppo dell applicazione è mostrata a grandi linee nella Figura 3:1 External Provider SOAP (https) Internal services Access & Authentication layer SOAP HTTP-XML Front End layer Operation & management Sistema post-pagato Magistratura Service Execution Platform SNMP NFS Revenue Assurance Service Assurance Rendicontazione SQL FTP Logging system Middleware Core: Network delivery adapters Billing Adapter CORBA SQL Borsellino elettronico OSA Partay gateway SMS-GW MMS-GW Delivery Server Gaming Platform IVR Streaming HTTP, EAIF, UCP, LDAP, GSM - GPRS NETWORK GSM GPRS mobile users Figura 3:1: SDP di riferimento

22 La componente centrale è la Service Execution Platform della SDP mentre il Front End layer è il Service Exposure Layer. Il sistema interagisce con i componenti di rete veri e propri tramite i Gateway, che hanno il compito di semplificare questa interazione, traducendoi protocolli di basso livello in protocolli più accessibili allo sviluppatore dei servizi Le componenti a destra rappresentano gli apparati di tariffazione, quelle a sinistra i sistemi di post-elaborazione dei dati di traffico, mentre in alto a destra è riportata la componente per la gestione dei servizi implementati nella piattaforma. I blocchi in alto rappresentano le componenti che effettuano la richiesta di servizio alla SDP: possono essere componenti di servizio interne o esterne. Nel caso in cui siano esterne, i Provider esterni dovranno utilizzare un interfaccia apposita, tipicamente basata su Web Services, per accedere alle funzionalità messe a disposizione dal sistema. La componente di Front End è strettamente collegata alla Service Execution Platform poiché è la sua interfaccia verso l esterno ed ha essenzialmente il compito di rendere l accesso alla SDP indipendente dal sistema operativo e dal linguaggio di programmazione del client Infine in basso è visibile il Gataway, componente che si occupa dell invio fisico dell SMS. E da notare come sia il Front End, sia il Gataway presentino una interfaccia che utilizza il protocollo HTTP per la comunicazione con le componenti esterne.

23 Capitolo 4: L applicazione Delivery & Charging di SMS 4.1 Introduzione In questo capitolo si presenteranno i dettagli dell applicazione, in particolare gli SBB che realizzano la logica del servizio e gli altri elementi che entrano in gioco nello sviluppo di un applicazione conforme a JSLEE. Prima comunque verrà fornita una architettura di massima dell applicazione conforme con la descrizione della SDP del capitolo 3

24 4.2 L Architettura della applicazione JSLEE L architettura utilizzata per realizzare il servizio può essere rappresentata su grandi linee con la Figura 4.1. Figura 4:1 Architettura JAIN per SMS Application-to-person E composta da un Application Server J2EE e da un Application Server JSLEE che comunicheranno, attraverso un Resource Adaptor per le informazioni da J2EE a JSLEE e attraverso richieste HTTP per il viceversa. Il Container J2EE è utilizzato per installare le Servlet,che si occupano di comunicare con le applicazioni esterne attraverso il protocollo HTTP, e gli EJB, che attraverso il Resource Adaptor J2EE, comunicheranno con l Application Server JSLEE.

25 Il Front End dedicato appositamente alle funzionalità di interfaccia con l esterno presenta verso le applicazioni una interfaccia http semplice, è in stallato nell Applicaiton Server J2EE. A seguito di una richiesta HTTP, il Front End affida ad un EJB il compito di interagire con la piattaforma JSLEE per avviare effettivamente il servizio corrispondente alla richiesta. Ciò è possibile utilizzando l AS J2EE per ospitare gli EJB e sfruttando due componenti, indispensabili per l interazione tra EJB ed SBB: un Connector installato sull AS J2EE e un Resource Adaptor installato sull AS JSLEE (forniti insieme alla piattaforma Rhino_Sdk). L ambiente JSLEE riceve, dunque, gli eventi dagli EJB e li consegna agli SBB destinati ad elaborarli che, di conseguenza, interagiscono con i componenti di rete per soddisfare la richiesta di servizio. Lo scopo di questo lavoro è quello di realizzare una Service Execution Platform (SEP) integrabile con la architettura della SDP vista nel capitolo precedente., per cui l architettura generale utilizzata è composta dagli stessi elementi della SDP di riferimento, ma con i componenti centrali, legati alla logica del servizio sostituiti dagli analoghi elementi realizzati con le tecnologie JAIN. E importante notare che è stato necessario sviluppare anche il Front End in quanto, anche se rappresentato come una componente esterna rispetto al SEP, è fortemente legato all architettura del SEP. Quindi i componenti che si occupano della tariffazione, della trasmissione degli SMS e del ogging conservano le stesse interfacce e gli stessi comportamenti.

26 Anche la comunicazione tra il SEP e l SMS GW è basata sul protocollo HTTP pertanto la soluzione ideale per la comunicazione verso l esterno sarebbe stato un Resorce Adaptor http secondo il modello JSLEE Non avendo a disposizione né un http Resource Adaptor, né le specifiche dell architettura dei RA, si è risolto il problema della comunicazione con l esterno tramite il J2EE RA. Analizzando i dettagli delle interazioni http, gli SBB dovrebbero reagire agli eventi provenienti dalla sessione http tramite il RA; in direzione opposta, invece, è possibile per un SBB effettuare direttamente e ogging amente (cioè senza dover, per esempio, generare un evento che l ambiente traduca poi in richiesta sincrona) una richiesta http verso una risorsa esterna. Per questo motivo si è scelto che le richieste http dall interno verso l esterno siano effettuate direttamente dagli SBB, mentre le richieste provenienti dall esterno, in questo caso dal SMS GW, siano ricevute da una Servlet apposita, che ricorre agli EJB per inviare l evento corrispondente a JSLEE.

27 In definitiva l architettura rappresentata in Figura 4.1 si modifica assumendo l aspetto riportato in Figura 4:2 Figura 4.2: Architettura definitiva per SMS Application-to-person Il comportamento del SMS GW è stato emulato facilmente tramite una Servlet per poter testare l applicazione Per quanto riguarda il componente di tariffazione (Charging), come detto sopra, si è preferito evitare la sua emulazione, pur tenendolo presente in fase di progettazione dell applicazione. Per quanto riguarda la fase finale, di memorizzazione dell esito di ciascuna richiesta in un sistema di ogging, è stato considerato un database dedicato alla registrazione dei dati