Analisi,Studio e Sperimentazione di Tecnologie Web Service Università di Roma "La Sapienza" Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria.

Slides:



Advertisements
Presentazioni simili
XmlBlackBox La presentazione Alexander Crea 11 Aprile 2010 La presentazione Alexander Crea 11 Aprile 2010.
Advertisements

UNIVERSITÀ DEGLI STUDI DI MODENA E REGGIO EMILIA
Architetture dei sistemi distribuiti Prof
© 2007 SEI-Società Editrice Internazionale, Apogeo Unità D1 Architetture di rete.
Web Services.
Java Enterprise Edition (JEE)
P. Sanna 1 I web services TICO Corso di laurea in Informatica Università di Pisa a.a Pierluigi Sanna.
una interfaccia internet per il sistema Momis
UNIVERSITA DEGLI STUDI DI MODENA E REGGIO EMILIA Facoltà di Ingegneria – Sede di Modena Corso di Laurea in Ingegneria Informatica Progetto e sviluppo di.
Università degli Studi di Modena e Reggio Emilia Facoltà dIngegneria - sede di Modena Corso di Laurea in Ingegneria Informatica Interoperabilità di componenti.
UNIVERSITÀ DEGLI STUDI DI MODENA E REGGIO EMILIA
IN QUESTA PRESENTAZIONE…
OUTLINE Riprogettazione del database del portale Web della Facoltà di Ingegneria Sviluppo di una applicazione WEB DB : HOMEPAGE DOCENTI Architettura multilivello.
Usare Apache Axis.
Java2 Esercitazioni del corso di Sistemi Informativi Marina Mongiello
Introduzione ai Web Services. E' un nuovo meccanismo RPC ottimizzato per l'uso in Internet Un qualunque Client su una generica piattaforma deve poter.
XmlBlackBox La presentazione Alexander Crea 7 Giugno 2010 La presentazione Alexander Crea 7 Giugno 2010.
LABIS-SD Antonio Cuomo393/121 Clelio Quattrocchi393/127 Emanuele Zuzolo393/136 Fabio Melillo393/141 Stefano Mastrocinque393/135 Valerio Vincenzo Guarino393/155.
I modelli di riferimento OSI e TCP/IP
Distributed Object Computing
Ambiente di Invocazione Dinamica dei Servizi Enrico Mussi - WP2.
Perché.Net e non più COM/DCOM ? Superamento dei problemi di COM: Richiede una infrastruttura "non semplice" da ogni applicazione (ad esempio Class Factory.
Integrazione di una piattaforma IPTV in un’architettura SOA
L'innovazione Tecnologica Per Il Federalismo Efficiente Roma 30 Giugno 2005 Sistema Pubblico di Cooperazione Applicativa.
Struttura dei sistemi operativi (panoramica)
Integrazione Software via Web-Services
Struts. Framework open source per lo sviluppo di applicazioni web su piattaforma J2EE. Progetto inizialmente sviluppato come sotto-progetto di Apache.
Architettura Java/J2EE
Modello di replicazione attivo e di supporto alla tolleranza ai guasti in ambito MOM Autore: Claudio Fusconi Matricola: Esame: Reti di calcolatori.
Delay Tolerant Networking Service per SAMOA. Il framework SAMOA SAMOA è un framework che consente di gestire e popolare la rete sociale e propagare a.
A Reliable Message Oriented Middleware based on Publish and Subscribe paradigm Mirko Matoffi a.a. 2003/2004.
Progetto di Reti di Calcolatori LS a cura di Gesualdi Marco Miniello Giuseppe Vukovic Veljko.
Distributed File System Service Dario Agostinone.
PROGETTAZIONE E REALIZZAZIONE DI UN MIDDLEWARE CLIENT-SERVER
Grid monitoring: sviluppi futuri
Corso di Informatica per Giurisprudenza Lezione 7
Progetto di Reti di Calcolatori L-S Orchestrazione di servizi WEB
Il modello di riferimento OSI
Servizi Grid ed agenti mobili : un ambiente di sviluppo e delivering
Basi di Dati e Sistemi Informativi
Sistemi Informativi sul Web
Presentazione del problema Obiettivo: Lapplicazione di Search of Sematic Services permette di ricercare sevizi semantici, ossia servizi a cui sono associati.
Corso di Web Services A A Domenico Rosaci 1. Introduzione
Java Enterprise Edition
Reti di Calcolatori ed Internet Fabio Massimo Zanzotto.
Distributed System ( )7 TCP/IP four-layer model.
Università degli Studi di Bologna FACOLTA’ DI INGEGNERIA Corso di Laurea in Ingegneria Informatica I web services come soluzione per l’interoperabilità.
Java Enterprise Edition
Nemesi Creazione e pubblicazione di una rivista online tramite l’utilizzo di Java Message Service.
Architetture a componenti Java per la realizzazione di DSS distribuiti Giordano Vicoli - ENEA 28 Ottobre 2003.
TW Asp - Active Server Pages Nicola Gessa. TW Nicola Gessa Introduzione n Con l’acronimo ASP (Active Server Pages) si identifica NON un linguaggio di.
Producer – Consumer System Di Carlo Matteo CdLS Ingegneria Informatica (0234) Reti di Calcolatori LS A.A. 2004/2005.
Università degli Studi di Roma “Tor Vergata”
Progetto di Ingegneria del Web Anno Accademico 2007/2008 Stefano Pigiani Bruno Ricci Marco Ruzzon.
Relatore: Ing. Francesco Lo Presti Correlatore: Ing. Stefano Salsano UPMT: progetto e realizzazione di una soluzione di mobilità verticale e overlay networking.
Supporto per la replicazione attiva di servizi Progetto per il corso di Reti di Calcolatori LS Montanari Mirko Matr:
Lucia Melotti 1/14 Bologna, 7 luglio 2004 Aspetti di sicurezza nello scambio di messaggi XML tra un partner ebXML ed un Web Service di Lucia Melotti Relatore:
Java Distributed Event Service Bringing events to J2EE platform Università degli studi di Bologna Corso di Laurea Specialistica in Ingegneria Informatica.
Servizi Internet Claudia Raibulet
Ingegneria del software Modulo 3 -Tecniche d’implementazione Unità didattica 1 -Ingegneria dei componenti Ernesto Damiani Università degli Studi di Milano.
Mobile Agent and Enterprise Architecture Integration Il Gestore di Librerie e Servizi Lambertini Riccardo.
Mots, programmazione collaborativa di Ettore Ferranti.
Business Process Management Orchestrazione di Web Service basata su standard BPEL per la realizzazione di un servizio di tour operator Università degli.
Le basi di dati.
Architetture software
Sistemi distribuiti Sistema distribuito indica una tipologia di sistema informatico costituito da un insieme di processi interconnessi tra loro in cui.
1 Il livello transport. Concetti fondamentali - Canale logico e canale fisico 2 Quando un segnale deve essere trasmesso, viene inviato su un Canale, cioè.
Open City Platform è un progetto finanziato da Application Store Tutorial 30/09/2015.
Framework di sicurezza della piattaforma OCP (Identity & Access Management) Smart Cities and Communities and Social Innovation Bando MIUR D.D. 391/Ric.
Transcript della presentazione:

Analisi,Studio e Sperimentazione di Tecnologie Web Service Università di Roma "La Sapienza" Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica Tesina di Seminari di Ingegneria del software Prof. Giuseppe De Giacomo Supervisore: A cura di: Ing.Massimo Mecella Alessandro Gabrielli Anno accademico

Obiettivi Analizzare il legame tra il concetto di servizio, architettura orientata ai servizi(SOA) e Web Services; Approfondire lo studio sui Web Services e i relativi standard; Realizzare servizi con tecnologie differenti come Axis1.4 ed Axis2; Esporre un EJB via Web Service; Realizzare Web Services sincroni ed asincroni; Studiare le problematiche relative all’implementazione di servizi stateless in grado di mantenere lo stato della conversazione con i client e fornire alcune possibili implementazioni; Introdurre gli standard per la notifica di eventi nei Web Services; Trovare un framework che permetta di implementare la specifica WS- Notification; Realizzare uno scenario publish/subscribe attraverso il quale analizzare lo standard del WS-Notification.

Rappresentazione astratta di un servizio Un Transition System TS è un modello relazionale astratto basato sulle nozioni primitive di stato e transizione rappresentato dalla tupla T = dove: – A è l’insieme delle azioni – S è l’insieme degli stati – So  S è l’insieme degli stati iniziali – δ  S x A x S è l’insieme delle transizioni - F  S è l’insieme degli stati finali I servizi possono essere realizzati attraverso differenti tecnologie,implementati in diversi linguaggi di programmazione e distribuiti su piattaforme eterogenee. Per questo motivo abbiamo l’esigenza di una rappresentazione che astragga dalla loro implementazione e mostri semplicemente il loro comportamento: behavior. S0S1S4S5 S2 S3 doLogingetList getSmallQuote getBankQuote getLoan Transition System

Service Oriented Architecture(SOA)

1. Publish the service (SOAP/HTTP) 2. Discovery (SOAP/HTTP) 3. IP Address (SOAP/HTTP) 7. SOAP Request (XML+HTTP) 11. SOAP Response (XML+HTTP) Service Provider Service Consumer UDDI Registry Server Stub SOAP router Service Implementation HTTP server Client Stub SOAP engine Client Implementation HTTP engine 4. Invoke the service as a local call. 5. Invoke SOAP engine to prepare SOAP message. 6. Packages SOAP into HTTP and passes it to an HTTP client that sends it to the provider. 8. Passes the content of the HTTP messages to the router 9. The router parses the message,identified the appropriate stub,and delivers the parsed message. 10. Invokes the local procedure of the service implementation. Web Service interface Service description Inquiry APIPublishers API Network Firewall SOA – Web Services WSDL

Conclusioni - Un servizio può essere definito come una funzionalità di business realizzata tramite componenti che rispettano un’interfaccia standard. - Attualmente nelle architetture applicative si ragiona in termini di componenti che offrono servizi applicativi, sia verso l’interfaccia utente sia verso altre applicazioni e componenti. - Questo è il concetto che sta alla base di SOA (Service Oriented Architecture) e COM,DCOM,CORBA e Web Services rappresentano le tecnologie per realizzarla. - I servizi possono essere quindi realizzati attraverso differenti tecnologie,implementati in diversi linguaggi di programmazione e distribuiti su piattaforme eterogenee. - Con SOA viene definita l’architettura che li caratterizza ma accanto ad essa nasce l’esigenza di una rappresentazione che astragga dalla loro implementazione e mostri semplicemente il loro comportamento: behavior. Questo si può fare mediante una rappresentazione sotto forma di stati e transizioni:i transition system.

Web Services Standard Statefull Stateless (base features)

Protocollo SOAP - Windows/DCOM client applications - Java client applications - CORBA client java - CORBA client c++ JNP IIOP-GIOP-ESOP JMS Engine SOAP HTTP Tunneling(HTTP+Protocollo x) Port:80 Microsoft SOAP Tolkit Apache SOAP 2.2 SOAP=HTTP+XML ORPC JRMP Informazione binaria Informazione testuale Web Server Apache Tomcat Web Services IIS Apache HTTP Server Microsoft Personal Web Server Netscape Enterprise Server Bootstrap Name Service Port:900 RMI-IIOP Port:1099 RMI/JRMP - COM/DCOM - CORBA - EJB Web Server Apache Jakarta Protocol (AJP)

Web Services Description Language(WSDL)

Ecco riassunti i principali motivi per utilizzare o sviluppare un Web service. - I Web service permettono l'interoperabilità tra diverse applicazioni software e su diverse piattaforme hardware/software. - Utilizzano un formato dei dati di tipo testuale, quindi più comprensibile e più facile da utilizzare per gli sviluppatori (esclusi ovviamente i trasferimenti di dati di tipo binario). - Normalmente, essendo basati sul protocollo HTTP, non richiedono modifiche alle regole di sicurezza utilizzate come filtro dai firewall. - Sono semplici da utilizzare e possono essere combinati l'uno con l'altro (indipendentemente da chi li fornisce e da dove vengono resi disponibili) per formare servizi "integrati" e complessi. - Permettono di riutilizzare applicazioni già sviluppate.. - Fintanto che l'interfaccia rimane costante, le modifiche effettuate ai servizi rimangono trasparenti. - I servizi web sono in grado di pubblicare le loro funzioni e di scambiare dati con il resto del mondo. - Tutte le informazioni vengono scambiate attraverso protocolli "aperti". Conclusioni

Apache Axis Axis (Apache eXtensible Interaction System) è un'implementazione del protocollo SOAP definito da W3C. AXIS è essenzialmente un motore SOAP in grado di processare messaggi SOAP e permette di sviluppare client, server e gateway SOAP. In realtà AXIS non è propriamente un semplice engine SOAP,ma piuttosto un framework per realizzare sistemi di integrazione basati su SOAP. Le caratteristiche più importanti del framework sono: Supporto parziale delle specifiche SOAP 1.2 Supporto per la pubblicazione automatica dei servizi(Java Web Service) Supporto serializzazione/de-serializzazione Generazione automatica del documento WSDL per un servizio pubblicato Tool WSDL2Java e Java2WSDL Soap Monitor e TCP Monitor Diversi metodi per l'invocazione dei WS: Dynamic Invocation Interface, Stub generato dal WSDL e Dynamic Proxy

Apache Axis – Message Path Server-side Client-side

Apache Axis – Web Service La Banca di Roma ha deciso di esporre come Web Service alcuni servizi che offre alla sua clientela,come ad esempio il calcolo del tasso d’interesse associato ad un determinato prestito e la possibilità in un momento successivo da parte del cliente di richiedere il prestito stesso. BancaDiRomaWS è quindi un Web Service progettato appositamente per la Banca di Roma e i metodi esposti,che corrispondono ai servizi che la banca intende offrire,sono: - getLoanQuote():per il calcolo del tasso d’interesse; - getLoan():per richiedere un prestito. Network SOAP (Port:80) JDBC Microsoft/Windows Web Server Apache Tomcat HTTP Server Apache HTTP ServerApache Tomcat Network

<deployment xmlns=" xmlns:java=" <typeMapping xmlns:ns=" qname="ns:BankQuoteRequest" type="java:banca_di_roma.To.BankQuoteRequest" serializer="org.apache.axis.encoding.ser.BeanSerializerFactory" deserializer="org.apache.axis.encoding.ser.BeanDeserializerFactory" encodingStyle=" /> Apache Axis – Web Service deployment descriptor 1. Costruire l’interfaccia del servizio 2. Generare il file WSDL 3. Generare lo skeleton 4. Implementare i metodi 5. Compilare il progetto e copiare la relativa cartella nell’application server 6. Effettuare il deploy del servizio

Cookie: Axis fornisce le seguenti modalità per gestire le sessioni: 1) HTTP Cookie 2) SOAP headers Apache Axis – Gestione delle sessioni In Axis1.4 sono disponibili i seguenti tipi di scope: Request(stateless) Session(stateful) Application(singleton) Tale informazione va inserita nel file.wsdd di deploy del servizio: SimpleSessionHeader: JSESSIONID=24562F7A AF4B88BA6B0285F0 transport-independent gestito dal protocollo di trasporto

Apache Axis2 Apache Axis2 può essere considerato l’evoluzione di Axis1. L’architettura su cui si basa Axis 2 è più flessibile,efficiente e configurabile rispetto a quella di Axis1. E’progettato per semplificare l’aggiunta di nuovi moduli per garantire ad esempio maggiore affidabilità e sicurezza. I moduli attualmente disponibili o in fase di sviluppo sono: WS–ReliableMessage – Supported by Apache Sandesha2 WS-Coordination e WS–AtomicTransaction – Supported by Apache Kandula2 WS–Security – Supported by Apache Rampart WS-Addressing. Apache Axis2 è costruito al di sopra di AXIOM,un nuovo pull-based XML object model e presenta le le seguenti caratteristiche: Velocità AXIOM Hot Deployment Asynchronous Web Services MEP Support Flexibility Stabilità Component-oriented Deployment Transport Framework WSDL Support Composition and Extensibility Data Binding

Apache Axis2 - Architecture

Apache Axis2 – Message path

banca_di_credito_cooperativo.BancaDiCreditoCooperativoWSSkeleton true urn:getLoanQuote urn:getLoanQuoteResponse urn:getLoan urn:getLoanResponse Apache Axis2 – services.xml In Axis2 il Web Service Deployment Descriptor corrisponde al file services.xml: Il precedente file è relativo al servizio BancaDiCreditoCooperativoWS deployato in Axis2.

Apache Axis2 – Gestione delle sessioni Per implementare il SOAPSession scope bisogna abilitare il WS-Addressing sia client side che server side. L’architettura di Axis2 supporta quattro tipi di scope: Request session scope(stateless) SOAPSession scope(stateful) Transport Session scope(stateful) Application scope(singleton) Da indicare nel relativo parametro nel file services.xml: Cookie: Axis2 fornisce le seguenti modalità per gestire le sessioni: 1) TransportSession 2) SOAPSession JSESSIONID=24562F7A AF4B88BA6B0285F0 gestito dal protocollo di trasporto(HTTP) transport-independent

Conclusioni Al termine di questa fase ho raggiunto i seguenti obiettivi: Analizzato le architetture alla base di Axis1.4 e Axis2 Individuato le differenze tra i due engine SOAP Effettuato deploy ed invocazione di servizi sincroni stateless; Implemento i servizi LoginWS, CreditAgencyWS, CreditRiskWS, BancaDiRomaWS, e BancaDiCreditoCooperativoWS Descritto i Web Service Description Language(WSDL) generati dai relativi tools Analizzato i messaggi SOAP scambiati durante la comunicazione tra client e servizi attraverso il tool Tcp Monitor: clienttcpmonEndpoint(router)Web Service client-sideserver-side listen on localhost:listenPort listen on targethost:targetPort

WS-Addressing SOAP non è completamente neutrale rispetto al trasporto – Ad esempio il destinatario non è incluso nel pacchetto ma è l'indirizzo del canale di trasporto Questi problemi rendono difficile gestire profili asincroni in cui la risposta non arriva sulla stessa connessione http della richiesta. WS-Addressing risolve queste problematiche tramite l'introduzione di appositi header: wsa:To, wsa:Action, wsa.MessageID, wsa:From, wsa:replyTo, wsa:faultTo To: (obbligatorio)indica l'endpoint a cui e' destinato il messaggio; Action: (obbligatorio) indica l'operazione o l'azione che deve esser presa per questo messaggio;. ReplyTo: (opzionale) specifica la locazione a cui inviare la risposta. Se non specificato o settato ad anonymous usa il canale previsto dal livello trasporto; FaultTo: (opzionale) Simile al replyTo, ma per i messaggi di errore; MessageId: (opzionale nei Oneway) indica un identificatore univoco del messaggio; RelatesTo: (obbligatorio nelle risposte) nei messaggi di risposta indica il MessageId della richiesta. Con WS-Addressing è possibile quindi relizzare sia servizi stateful che comunicazioni asincrone utilizzando due canali di trasporto differenti per il messaggio di richiesta e quello di risposta. WS-Addressing è uno standard W3C che definisce un set di header che consentono di specificare l’endpoint destinatario all'interno del messaggio SOAP stesso.

Servizi sincroni SOAP User SOAP Node Blocking API User Application Axis2 ClientAPI Service SOAP Node Web Service Logic Web Service Logic Axis2 Service Framework Axis2 Service Framework SOAP User SOAP Node Non-Blocking API User Application Axis2 ClientAPI Service SOAP Node Web Service Logic Web Service Logic Axis2 Service Framework Axis2 Service Framework Client sincrono(blocking) Client sincrono(non- blocking)

Client asincrono(non-blocking,dual-transport) Servizi asincroni 1. stub2._getServiceClient().getOptions().setUseSeparateListener(true); 2. stub2._getServiceClient().engageModule(new QName("addressing")); 3. stub2._getServiceClient().getOptions().setTransportInfo(Constants.TRANSPORT _HTTP,Constants.TRANSPORT_HTTP, true);

doLogin getLoan OrchestratoreWS getSmallQuote getBankQuote getList CreditRiskWS CreditAgencyWS BancaDiRomaWS BancaDiCreditoCooperativoWS BancaDeiPaschiDiSienaWS getLoanQuote getLoan getCreditRisk GetCustomerCredit Client LoginWS doLogin ClientTarget serviceCommunity Servizi stateful

S0S1S4S5 S2 S3 doLogingetList getSmallQuote getBankQuote getLoan S >Stato iniziale,Operazione:doLogout S >Operazione:doLogin S >Operazione:getSmallQuote S >Operazione:getBankQuote S >Operazione:getList S >Operazione:getLoan A = {doLogin,getSmallQuote,getBankQuote,getList,getLoan} S = {S0,S1,S2,S3,S4,S5} So={S0} δ = {(S0,doLogin,S1), (S1,getList,S4), (S4,getSmallQuote,S2), (S4,getBankQuote,S3), (S2,getLoan,S5), (S3,getLoan,S5), } F = {S5} Apache Axis – OrchestratoreWS package orchestratore; import java.util.*; public interface OrchestratoreWS{ public String doLogin(String user); public Vector getList(); public String getSmallQuote(); public String getBankQuote(String banca); public String getLoan(String banca); public String getStato(); } Codice da pag.67 a pag.85 della Documentazione

Conclusioni OSSERVAZIONE Una cosa importante da sottolineare è che nessuna delle tecnologie analizzate in questo contesto supporta l’implementazione di servizi stateful in grado di mantenere lo stato della conversazioni con i client. E’ compito del programmatore implementare tali tipologie di servizi:nel caso del Web Service OrchestratoreWS ho infatti prima rappresentato il servizio con il relativo TS e successivamente scritto il codice che concretamente implementa i metodi esposti. In effetti ho realizzato un servizio statefull che mantiene lo stato della conversazione ma per il procedimento seguito non si può parlare di tipologia di sviluppo supportata dalla tecnologia:in quel caso,ad esempio,Axis o Axis2 dovrebbero fornire un qualche tool che analizzando il file xml che descrive il TS costruisce automaticamente la classe che implementa il servzio. Skeleton Tool Transition System TS.xml Implementazion e automatica Implementazion e manuale In questa fase ho approfondito lo studio sui seguenti concetti: Servizi sincroni ed asincroni in Axis1.4 e Axis2 WS-Addressing Servizi stateless e stateful in Axis1.4 e Axis2 Per concludere con la realizzazione del servizio stateful OrchestratoreWS

EJB e Web Services Web Service Web Server(Apache Tomcat) RMI Logica Business Session Facade:MySessionBean Application Container Java Application HTTP/SOAP RMI-IIOP JDBC Presentation TierBusiness TierData Tier

EJB e Web Services – Axis e JBoss Per implemetare Web Services in JBoss sfruttando le funzionalità offerte da Axis bisogna innanzitutto configurarli correttamente. Per installare Axis all’inerno di JBoss basta copiare la cartella axis-1_4 all’interno di C:\Programmi\jboss-4.0.3SP1\server\default\deploy rinominandola axis.war. La cartella axis-1_4 deve essere rinominata in axis.war per permettere a JBoss di riconoscerla come web application e quindi al web container di effettuarne il deploy a run-time. Sotto: WEB-INF\lib Occorre, invece inserire le librerie: - jboss-client.jar - jboss-j2ee.jar - jbossmq-client.jar - jbosssx-client.jar - jndi.jar - jnp-client.jar con cui Axis è in grado di interrogare l’application container su cui gira l’EJB tramite protocollo RMI. Per effettuare il deploy dell’EJB come Web Service bisogna creare il file.wsdd ed eseguire il comando: java org.apache.axis.client.AdminClient –lhttp://localhost:8080/services/AdminService deploy.wsdd Nota:Attualmente solo gli Stateless Bean possono essere utilizzati come endpoint per un Web Services come specificato in JSR-109. JSR-109 onsente di definire i requisiti di deploy per EJB che vogliono essere esposti come Web Service.

EJB e Web Services – Axis e JBoss <deployment xmlns=" xmlns:java=" <typeMapping xmlns:ns=" qname="ns:BankQuoteRequest" type="java:banca_dei_paschi_di_siena.To.BankQuoteRequest" serializer="org.apache.axis.encoding.ser.BeanSerializerFactory" deserializer="org.apache.axis.encoding.ser.BeanDeserializerFactory" encodingStyle=" /> Web Services Deployment Descriptor

Conclusioni Web Service Web Server(Apache Tomcat) BancaDeiPaschiDiSienaWS RMI BancaPSEJB BancaPaschiEJB Application Container HTTP/SOAP JDBC Presentation Tier Business Tier Data Tier Microsoft/Windows Properties props=new Properties(); props.put(Context.INITIAL_CONTEXT_F ACTORY,"org.jnp.interfaces.NamingCo ntextFactory"); props.put(Context.PROVIDER_URL, "jnp://localhost:1099"); Context ctx=new InitialContext(props); Object obj = ctx.lookup(“BancaPaschiEJB”); BancaPSEJBHome home = (BancaPSEJBHome) javax.rmi.PortableRemoteObject. narrow(obj,BancaPSEJBHome.class); BancaPSEJB banca=home.create();

Standard per la notifica di eventi nei Web Services Attualmente per i web-services esistono tre differenti specifiche in grado di supportare scenari di tipo publish/subscribe: 1. WS-Events; 2. WS-Eventing; 3. WS-Notification. Queste specifiche sono tra loro molto simili e presentano in realtà pochissime differenze (spesso di carattere puramente terminologico). Ciascuna specifica si appoggia a specifiche web già esistenti: in particolare WS-Notification richiede per il suo funzionamento che vengano implementate numerose altre specifiche, a differenza di come accade nel caso di WS-Events e WS-Eventing. Un forte limite di WS-Events e WS_Eventing è quello di non riuscire a modellare scenari che consentano ai servizi di interagire con degli intermediari. Tolta WS-Notification, nessuna delle altre due specifiche standardizza infatti il ruolo dei broker. Altri limiti riscontrati nelle specifiche sono: - Non definiscono dei protocolli sicuri per lo scambio di informazioni tra servizi. - Non hanno tra i loro obiettivi quello di garantire affidabilità nello scambio di messaggi. - Non consentono di definire un timeout sulle richieste di recupero di notifiche se si è in modalità pull. - Tutte le specifiche assumono che il canale di comunicazione per lo scambio di messaggi sia affidabile. - Non consentono di definire particolari policy per la gestione delle sottoscrizioni. Nonostante le tre specifiche si assomiglino moltissimo, WSNotification offre in generale maggiore espressività. Un differenza significativa tra le tre specifiche risiede nel modo con cui ciascuna permette di definire categorie di eventi (topics o più generalmente tipi di evento). WS-Notification è l’unica specifica in grado di fornire un sistema di definizione dei tipi di event basato sul concetto di topic.

WS-Notification WS-Notification è una famiglia di specifiche per web-services che definisce un approccio di tipo publish/subscribe alla notifica di eventi. Le specifiche che compongono WS-Notification sono tre: - WS-BaseNotification - WS-BrokeredNotification - WS-Topics WS-Notification distingue ben cinque possibili attori di sistema: - Notification Producer - Notification Consumer - Subscriber - Subscription Manager - Notification Broker Scenario di funzionamento in assenza di un brokerScenario di funzionamento in presenza di un broker

Apache Muse Il progetto Apache Muse è un’implementazione Java delle specifiche: - WS-ResourceFramework(WSRF) - WS-BaseNotification(WSN) - WS-DistributedManagement(WSDM) Si tratta di un framework attraverso il quale è possibile sia costruire interfacce Web Services per la gestione di risorse che effettuare il deploy di applicazioni in Apache Axis2 e in ambienti OSGi;il progetto comprende infatti una serie di tools che permettono di generare tutto quello che occorre per la costruzione di un ipotetico scenario. L’architettura di Apache Muse è la seguente:

Apache Muse-Deployment Descriptor

Apache Muse - Scenario

Publisher- Architettura Codice da pag.173 a pag.188 della Documentazione

Consumer-Architettura Codice da pag.188 a pag.202 della Documentazione

Apache Muse - Subscribe Update Forward SubscriptionResponse SubscriptionRequest Update :Subscriber :NotificationProducer :SubscriptionManager

Apache Muse - Notify :wsn-producer Nuovo Evento NotifyRequest NotifyResponse :NotificationProducer :SubscriptionManager :NotificationConsumer :wsn-consumer Forward Update Forward Update Forward

Apache Muse-Conclusioni Per quanto riguarda la parte sul WS-BaseNotification gli obiettivi raggiunti sono stati: Analisi e studio del framework Apache Muse Implementazione della specifica WS-BaseNotification Realizzazione e deploy del Publisher wsn-producer e dei Consumer wsn-consumer-JBoss e wsn- consumer-Tomcat in JBoss e Tomcat Analisi dei messaggi scambiati durante la comunicazione

Conclusioni Lo scopo di questa tesina è stato quello di approfondire lo studio sull’implementazione, la compilazione, il deploy e l’esecuzione Web Services sincroni, asincroni, stateless e stateful analizzando funzionalità offerte ed approcci seguiti da differenti tipi di tecnologie. Per comprendere meglio quanto esposto a livello teorico ho presentato uno scenario che ha previsto la creazione di un servizio stateful, un orchestratore,che permette agli utenti di richiedere un prestito ad una banca. L’utente contatta di conseguenza questo servizio stateful senza sapere che in realtà per il task che ha richiesto ne vengono effettivamente utilizzati n(stateless). Per realizzare tale scenario ho implementato i seguenti servizi: Sviluppi futuri Si potrebbe sostituire il servizio OrchestratoreWS con un processo Bpel utilizzando quindi lo standard BPEL4WS o WS-BPEL che definisce l’uso di Bpel nelle interazioni tra Web Services. Ho infine studiato ed utilizzato un framework,Apache Muse,attraverso il quale ho costruito uno scenario publish/subscribe che implementa la specifica del WS-BaseNotification dello standard WS-Notification.