Università di Roma "La Sapienza"
Facoltà di Ingegneria
Corso di Laurea Specialistica in Ingegneria Informatica
Analisi,Studio e Sperimentazione di
Tecnologie Web Service
Tesina di Seminari di Ingegneria del software
Prof. Giuseppe De Giacomo
Supervisore:
Ing.Massimo Mecella
A cura di:
Alessandro Gabrielli
Anno accademico 2007-08
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 WSNotification;
Realizzare uno scenario publish/subscribe attraverso il quale analizzare lo
standard del WS-Notification.
Rappresentazione astratta di un servizio
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.
S2
getLoan
getSmallQuote
Transition System
doLogin
S0
getList
S1
S4
S5
getBankQuote
getLoan
S3
Un Transition System TS è un modello relazionale astratto basato sulle nozioni primitive di stato
e transizione rappresentato dalla tupla T = < A, S, So, δ, F> 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
Service Oriented Architecture(SOA)
SOA – Web Services
UDDI Registry
Web Service interface
1. Publish the service
2. Discovery
Service Consumer
Service description
(SOAP/HTTP)
(SOAP/HTTP)
3. IP Address (SOAP/HTTP)
Service Provider
WSDL
Inquiry API Publishers API
Service
Implementation
Client
Implementation
4. Invoke the service as a
local call.
Client Stub
Server Stub
5. Invoke SOAP engine to
prepare SOAP message.
Network
SOAP engine
10. Invokes the local
procedure of the service
implementation.
9. The router parses the
message,identified the
appropriate stub,and
delivers the parsed
message.
SOAP router
6. Packages SOAP into
HTTP and passes it to an
HTTP client that sends it
to the provider.
HTTP engine
8. Passes the content of
the HTTP messages to the
router
7. SOAP Request
(XML+HTTP)
HTTP server
11. SOAP Response
Firewall
(XML+HTTP)
Firewall
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
Informazione binaria
01010101
HTTP Tunneling(HTTP+Protocollo x)
10011010
10101010
Web Server
01010100
JNP
- COM/DCOM
IIOP-GIOP-ESOP
- CORBA
ORPC
- EJB
JMS
- Java client applications
JRMP
- Windows/DCOM client applications
- CORBA client java
- CORBA client c++
Web Server Apache Tomcat
RMI-IIOP
Bootstrap Name Service
Port:900
RMI/JRMP
Port:1099
SOAP=HTTP+XML
Informazione testuale
<service>
</service>
Port:80
Web Services
Apache Jakarta Protocol
(AJP)
Engine SOAP
Microsoft SOAP Tolkit
Apache SOAP 2.2
IIS
Apache HTTP Server
Microsoft Personal Web Server
Netscape Enterprise Server
Web Services Description Language(WSDL)
Conclusioni
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".
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.
Microsoft/Windows
Microsoft/Windows
Network
HTTP Server
SOAP
(Port:80)
Network
Apache HTTP Server
Apache Tomcat
Web Server Apache Tomcat
JDBC
Apache Axis – Web Service deployment descriptor
1.
2.
3.
4.
5.
6.
Costruire l’interfaccia del servizio
Generare il file WSDL
Generare lo skeleton
Implementare i metodi
Compilare il progetto e copiare la relativa cartella nell’application server
Effettuare il deploy del servizio
<deployment
xmlns="http://xml.apache.org/axis/wsdd/"
xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
<service name="BancaDiRomaWS" provider="java:RPC" style="rpc" use="encoded">
<parameter name="wsdlTargetNamespace" value="http://banca_di_roma"/>
<parameter name="wsdlServiceElement" value="BancaDiRomaWSService"/>
<parameter name="schemaUnqualified" value="http://To.banca_di_roma"/>
<parameter name="wsdlServicePort" value="BancaDiRomaWS"/>
<parameter name="className" value="banca_di_roma.BancaDiRomaWSSoapBindingSkeleton"/>
<parameter name="wsdlPortType" value="BancaDiRomaWS"/>
<parameter name="typeMappingVersion" value="1.2"/>
<parameter name="allowedMethods" value="*"/>
<typeMapping
xmlns:ns="http://To.banca_di_roma"
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="http://schemas.xmlsoap.org/soap/encoding/"
/>
</service>
</deployment>
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:
<parameter name="scope" value="Request|Session|Application"/>
Axis fornisce le seguenti modalità per gestire le sessioni:
gestito dal protocollo di trasporto
1) HTTP Cookie
2) SOAP headers
Cookie: JSESSIONID=24562F7A98121217AF4B88BA6B0285F0
transport-independent
SimpleSessionHeader:
<soapenv:Header>
<ns1:sessionID soapenv:actor=""
soapenv:mustUnderstand="0" xsi:type="xsd:long"
xmlns:ns1="http://xml.apache.org/axis/session">
-1919645576528915916
</ns1:sessionID>
</soapenv:Header>
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à
•
Stabilità
•
AXIOM
•
Component-oriented Deployment
•
Hot Deployment
•
Transport Framework
•
Asynchronous Web Services
•
WSDL Support
•
MEP Support
•
Composition and Extensibility
•
Flexibility
•
Data Binding
Apache Axis2 - Architecture
Apache Axis2 – Message path
Apache Axis2 – services.xml
In Axis2 il Web Service Deployment Descriptor corrisponde al file services.xml:
<?xml version="1.0" encoding="UTF-8"?>
<serviceGroup>
<service name="BancaDiCreditoCooperativoWS">
<messageReceivers>
<messageReceiver mep="http://www.w3.org/ns/wsdl/in-out"
class="banca_di_credito_cooperativo.BancaDiCreditoCooperativoWSMessageReceiverInOut"/>
</messageReceivers>
<parameter
name="ServiceClass">banca_di_credito_cooperativo.BancaDiCreditoCooperativoWSSkeleton</parameter>
<parameter name="useOriginalwsdl">true</parameter>
<parameter name="modifyUserWSDLPortAddress">true</parameter>
<operation name="getLoanQuote" mep="http://www.w3.org/ns/wsdl/in-out"
namespace="http://banca_di_credito_cooperativo">
<actionMapping>urn:getLoanQuote</actionMapping>
<outputActionMapping>urn:getLoanQuoteResponse</outputActionMapping>
</operation>
<operation name="getLoan" mep="http://www.w3.org/ns/wsdl/in-out"
namespace="http://banca_di_credito_cooperativo">
<actionMapping>urn:getLoan</actionMapping>
<outputActionMapping>urn:getLoanResponse</outputActionMapping>
</operation>
</service>
</serviceGroup>
Il precedente file è relativo al servizio BancaDiCreditoCooperativoWS deployato in Axis2.
Apache Axis2 – Gestione delle sessioni
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:
<service name="Service_name"
scope=“request|soapsession|transportsession|application">
</service>
Axis2 fornisce le seguenti modalità per gestire le sessioni: gestito dal protocollo di trasporto(HTTP)
1) TransportSession
2) SOAPSession
Cookie: JSESSIONID=24562F7A98121217AF4B88BA6B0285F0
transport-independent
Per implementare il SOAPSession scope bisogna abilitare il WS-Addressing sia client side che
server side.
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:
1
listen on
localhost:listenPort
client
2
tcpmon
6
client-side
5
listen on
targethost:targetPort 3
Endpoint(router)
4
server-side
Web Service
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
WS-Addressing è uno standard W3C che definisce un set di header che consentono di specificare
l’endpoint destinatario all'interno del messaggio SOAP stesso.
• 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.
Servizi sincroni
Client sincrono(blocking)
User SOAP Node
Service SOAP Node
User Application
Axis2
ClientAPI
SOAP
Axis2
Service
Framework
Web
Service
Logic
Blocking API
Client sincrono(nonblocking)
User SOAP Node
User Application
Service SOAP Node
Axis2
ClientAPI
Non-Blocking API
Axis2
Service
Framework
SOAP
Web
Service
Logic
Servizi asincroni
Client asincrono(non-blocking,dual-transport)
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);
Servizi stateful
Client
Target service
Community
CreditRiskWS
GetCustomerCredit
BancaDiRomaWS
getLoanQuote
OrchestratoreWS
getLoan
BancaDiCreditoCooperativoWS
doLogin
getList
Client
getSmallQuote
getLoanQuote
getLoan
getBankQuote
getLoan
BancaDeiPaschiDiSienaWS
getLoanQuote
getLoan
CreditAgencyWS
getCreditRisk
LoginWS
doLogin
Apache Axis – OrchestratoreWS
S2
Codice da pag.67 a pag.85 della Documentazione
getLoan
getSmallQuote
doLogin
S0
getList
S1
S4
S5
getBankQuote
S0------------->Stato iniziale,Operazione:doLogout
S1------------->Operazione:doLogin
S2------------->Operazione:getSmallQuote
S3------------->Operazione:getBankQuote
S4------------->Operazione:getList
S5------------->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}
getLoan
S3
<parameter name="scope" value="Session"/>
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();
}
Conclusioni
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
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.
Implementazion
e manuale
Transition
System
Skeleton
Implementazion
e automatica
Tool
TS.xml
EJB e Web Services
Presentation Tier
Business Tier
Data Tier
HTTP/SOAP
Web Service
Java Application
Web Server(Apache Tomcat)
RMI-IIOP
RMI
Session Facade:MySessionBean
JDBC
Logica Business
Application Container
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
Web Services Deployment Descriptor
<deployment xmlns="http://xml.apache.org/axis/wsdd/"
xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
<service name="BancaDeiPaschiDiSienaWS" provider="java:EJB">
<parameter name="wsdlTargetNamespace" value="http://banca_dei_paschi_di_siena"/>
<parameter name="schemaUnqualified" value="http://To.banca_dei_paschi_di_siena"/>
<parameter name="typeMappingVersion" value="1.2"/>
<parameter
<parameter
<parameter
<parameter
<parameter
<parameter
<parameter
<parameter
name="jndiURL" value="jnp://localhost:1099"/>
name="jndiContextClass" value="org.jnp.interfaces.NamingContextFactory"/>
name="beanJndiName" value="BancaPaschiEJB"/>
name="homeInterfaceName" value="banca_dei_paschi_di_siena.BancaPSEJBHome"/>
name="remoteInterfaceName" value="banca_dei_paschi_di_siena.BancaPSEJB"/>
name="className" value="banca_dei_paschi_di_siena.BancaPSEJBBean"/>
name="allowedMethods" value="*"/>
name="scope" value=“Request"/>
<typeMapping
xmlns:ns="http://To.banca_dei_paschi_di_siena"
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="http://schemas.xmlsoap.org/soap/encoding/"
/>
</service>
</deployment>
Conclusioni
Business Tier
Presentation Tier
Data Tier
Microsoft/Windows
HTTP/SOAP
Web Service
Web Server(Apache Tomcat)
BancaDeiPaschiDiSienaWS
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();
RMI
BancaPaschiEJB
JDBC
BancaPSEJB
Application Container
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 broker
Scenario 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
<muse>
<router>
<java-router-class></java-router-class>
<logging>
<log-file></log-file>
<log-level></log-level>
</logging>
<persistence>
<java-persistence-class></java-persistence-class>
<persistence-location></persistence-location>
</persistence>
</router>
<resource-type>
<context-path></context-path>
<wsdl>
<wsdl-file></wsdl-file>
<wsdl-port-type></wsdl-port-type>
</wsdl>
<java-id-factory-class></java-id-factory-class>
<java-resource-class></java-resource-class>
<capability>
<capability-uri></capability-uri>
<java-capability-class></java-capability-class>
</capability>
</resource-type>
<custom-serializer>
<java-serializable-type></java-serializable-type>
<java-serializer-class></java-serializer-class>
</custom-serializer>
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
:Subscriber
:NotificationProducer
:SubscriptionManager
SubscriptionRequest
Update
Forward
Update
SubscriptionResponse
Apache Muse - Notify
:wsn-producer
:NotificationProducer
:SubscriptionManager
:NotificationConsumer
:wsn-consumer
Nuovo Evento
Update
Forward
Update
NotifyRequest
Update
Forward
NotifyResponse
Forward
Update
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 wsnconsumer-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:
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.
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.