Analisi,Studio e Sperimentazione di Tecnologie Web Service

1
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 2007-08
2
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
  allimplementazione 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.

3
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
lesigenza di una rappresentazione che astragga
dalla loro implementazione e mostri semplicemente
il loro comportamento behavior.
Transition System
Un Transition System TS è un modello relazionale
astratto basato sulle nozioni primitive di stato
e transizione rappresentato dalla tupla T lt A,
S, So, d, Fgt dove A è linsieme delle
azioni S è linsieme degli stati So ? S è
linsieme degli stati iniziali d ? S x A x S è
linsieme delle transizioni - F ? S è linsieme
degli stati finali
4
Service Oriented Architecture(SOA)
5
SOA Web Services
UDDI Registry
Web Service interface
1. Publish the service (SOAP/HTTP)
2. Discovery (SOAP/HTTP)
Service Provider
Service Consumer
Service description
3. IP Address (SOAP/HTTP)
WSDL
Inquiry API
Publishers API
10. Invokes the local procedure of the service
implementation.
Service Implementation
Client Implementation
4. Invoke the service as a local call.
9. The router parses the message,identified the
appropriate stub,and delivers the parsed message.
Server Stub
Client Stub
5. Invoke SOAP engine to prepare SOAP message.
Network
SOAP router
SOAP engine
8. Passes the content of the HTTP messages to the
router
7. SOAP Request (XMLHTTP)
6. Packages SOAP into HTTP and passes it to an
HTTP client that sends it to the provider.
HTTP server
HTTP engine
11. SOAP Response (XMLHTTP)
Firewall
Firewall
6
Conclusioni
- Un servizio può essere definito come una
funzionalità di business realizzata tramite
componenti che rispettano uninterfaccia
standard. - Attualmente nelle architetture
applicative si ragiona in termini di componenti
che offrono servizi applicativi, sia verso
linterfaccia 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
larchitettura che li caratterizza ma accanto ad
essa nasce lesigenza 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 transizionii transition
system.
7
Web Services Standard
Statefull
Stateless (base features)
8
Protocollo SOAP
Informazione binaria 01010101 10011010 10101010 01
010100
HTTP Tunneling(HTTPProtocollo x)
JNP
Web Server
- COM/DCOM
IIOP-GIOP-ESOP
- CORBA
ORPC
- EJB
JMS
JRMP
- Java client applications
Web Server Apache Tomcat
- Windows/DCOM client applications
Web Services
RMI-IIOP
Bootstrap Name Service Port900
- CORBA client java
- CORBA client c
RMI/JRMP
Port1099
Apache Jakarta Protocol (AJP)
Engine SOAP
SOAPHTTPXML
Informazione testuale ltservicegt lt/servicegt
Microsoft SOAP Tolkit
Apache SOAP 2.2
IIS Apache HTTP Server Microsoft Personal Web
Server Netscape Enterprise Server
Port80
9
Web Services Description Language(WSDL)
10
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".
11
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

12
Apache Axis Message Path
Server-side
Client-side
13
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
dinteresse 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
dinteresse - getLoan()per richiedere un
prestito.
Microsoft/Windows
Network
Microsoft/Windows
SOAP (Port80)
Web Server Apache Tomcat
JDBC
HTTP Server
Network
Apache HTTP Server
Apache Tomcat
14
Apache Axis Web Service deployment descriptor
1. Costruire linterfaccia del servizio 2.
Generare il file WSDL 3. Generare lo skeleton 4.
Implementare i metodi 5. Compilare il progetto e
copiare la relativa cartella nellapplication
server 6. Effettuare il deploy del servizio
ltdeployment xmlns"http//xml.apache.org/axis/
wsdd/" xmlnsjava"http//xml.apache.org/axis/
wsdd/providers/java"gt ltservice
name"BancaDiRomaWS" provider"javaRPC"
style"rpc" use"encoded"gt ltparameter
name"wsdlTargetNamespace" value"http//banca_di_
roma"/gt ltparameter name"wsdlServiceElement"
value"BancaDiRomaWSService"/gt ltparameter
name"schemaUnqualified" value"http//To.banca_di
_roma"/gt ltparameter name"wsdlServicePort"
value"BancaDiRomaWS"/gt ltparameter
name"className" value"banca_di_roma.BancaDiRomaW
SSoapBindingSkeleton"/gt ltparameter
name"wsdlPortType" value"BancaDiRomaWS"/gt
ltparameter name"typeMappingVersion"
value"1.2"/gt ltparameter name"allowedMethod
s" value""/gt lttypeMapping
xmlnsns"http//To.banca_di_roma"
qname"nsBankQuoteRequest"
type"javabanca_di_roma.To.BankQuoteRequest"
serializer"org.apache.axis.encoding.ser.BeanS
erializerFactory" deserializer"org.apache
.axis.encoding.ser.BeanDeserializerFactory"
encodingStyle"http//schemas.xmlsoap.org/soap/e
ncoding/" /gt lt/servicegt lt/deploymentgt
15
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

ltparameter name"scope" value"RequestSessi
onApplication"/gt
Axis fornisce le seguenti modalità per gestire le
sessioni 1) HTTP Cookie 2) SOAP headers
gestito dal protocollo di trasporto
Cookie
JSESSIONID24562F7A98121217AF4B88BA6B0285F0
transport-independent
SimpleSessionHeader
ltsoapenvHeadergtltns1sessionID soapenvactor""
soapenvmustUnderstand"0" xsitype"xsdlong"xml
nsns1"http//xml.apache.org/axis/session"gt-1919
645576528915916lt/ns1sessionIDgtlt/soapenvHeadergt

16
Apache Axis2

• Apache Axis2 può essere considerato levoluzione
  di Axis1.
• Larchitettura su cui si basa Axis 2 è più
  flessibile,efficiente e configurabile rispetto a
  quella di Axis1.
• Eprogettato per semplificare laggiunta di nuovi
  moduli per garantire ad esempio maggiore
  affidabilità e
• sicurezza. I moduli attualmente disponibili o in
  fase di sviluppo sono
• WSReliableMessage Supported by Apache
  Sandesha2
• WS-Coordination e WSAtomicTransaction
  Supported by Apache Kandula2
• WSSecurity 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

17
Apache Axis2 - Architecture
18
Apache Axis2 Message path
19
Apache Axis2 services.xml
In Axis2 il Web Service Deployment Descriptor
corrisponde al file services.xml
lt?xml version"1.0" encoding"UTF-8"?gt ltserviceGro
upgt ltservice name"BancaDiCreditoCooperativoWS
"gt ltmessageReceiversgt
ltmessageReceiver mep"http//www.w3.org/ns/wsdl/in
-out" class"banca_di_credito_cooperativo.BancaDiC
reditoCooperativoWSMessageReceiverInOut"/gt
lt/messageReceiversgt ltparameter
name"ServiceClass"gtbanca_di_credito_cooperativo.B
ancaDiCreditoCooperativoWSSkeletonlt/parametergt
ltparameter name"useOriginalwsdl"gttruelt/param
etergt ltparameter name"modifyUserWSDLPortA
ddress"gttruelt/parametergt ltoperation
name"getLoanQuote" mep"http//www.w3.org/ns/wsdl
/in-out" namespace"http//banca_di_credito_cooper
ativo"gt ltactionMappinggturngetLoanQuot
elt/actionMappinggt ltoutputActionMapping
gturngetLoanQuoteResponselt/outputActionMappinggt
lt/operationgt ltoperation
name"getLoan" mep"http//www.w3.org/ns/wsdl/in-o
ut" namespace"http//banca_di_credito_cooperativo
"gt ltactionMappinggturngetLoanlt/actionM
appinggt ltoutputActionMappinggturngetLo
anResponselt/outputActionMappinggt
lt/operationgt lt/servicegt lt/serviceGroupgt
Il precedente file è relativo al servizio
BancaDiCreditoCooperativoWS deployato in Axis2.
20
Apache Axis2 Gestione delle sessioni

• Larchitettura 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

ltservice name"Service_name" scoperequestsoapse
ssiontransportsessionapplication"gt lt/servicegt
Axis2 fornisce le seguenti modalità per gestire
le sessioni 1) TransportSession 2) SOAPSession
gestito dal protocollo di trasporto(HTTP)
Cookie
JSESSIONID24562F7A98121217AF4B88BA6B0285F0
transport-independent
Per implementare il SOAPSession scope bisogna
abilitare il WS-Addressing sia client side che
server side.
21
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 BancaDiCreditoCoope
  rativoWS
• 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

listen on localhostlistenPort
listen on targethosttargetPort
1
2
3
client
tcpmon
Endpoint(router)
Web Service
6
4
5
client-side
server-side
22
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 wsaTo, wsaAction, wsa.MessageID,
wsaFrom, wsareplyTo, wsafaultTo
WS-Addressing è uno standard W3C che definisce un
set di header che consentono di specificare
lendpoint 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.
23
Servizi sincroni
Client sincrono(blocking)
User SOAP Node Blocking API
Service SOAP Node
User Application
Axis2 Service Framework
Web Service Logic
Axis2 ClientAPI
SOAP
Client sincrono(non-blocking)

User SOAP Node Non-Blocking API
Service SOAP Node
User Application
Axis2 Service Framework
Web Service Logic
Axis2 ClientAPI
SOAP
24
Servizi asincroni
Client asincrono(non-blocking,dual-transport)
1. stub2._getServiceClient().getOptions().setUseSe
parateListener(true) 2. stub2._getServiceClient()
.engageModule(new QName("addressing")) 3.
stub2._getServiceClient().getOptions().setTranspor
tInfo(Constants.TRANSPORT _HTTP,Constants.TRANS
PORT_HTTP, true)
25
Servizi stateful
Client
Target service
Community
CreditRiskWS
GetCustomerCredit
BancaDiRomaWS
getLoanQuote
OrchestratoreWS
getLoan
BancaDiCreditoCooperativoWS
doLogin
getLoanQuote
getList
getLoan
getSmallQuote
Client
getBankQuote
BancaDeiPaschiDiSienaWS
getLoan
getLoanQuote
getLoan
CreditAgencyWS
getCreditRisk
LoginWS
doLogin
26
Apache Axis OrchestratoreWS
Codice da pag.67 a pag.85 della Documentazione
S0-------------gtStato iniziale,OperazionedoLogout
S1-------------gtOperazionedoLogin S2------------
-gtOperazionegetSmallQuote S3-------------gtOperazi
onegetBankQuote S4-------------gtOperazionegetLis
t S5-------------gtOperazionegetLoan A
doLogin,getSmallQuote,getBankQuote,getList,getLoa
n S S0,S1,S2,S3,S4,S5 SoS0 d
(S0,doLogin,S1), (S1,getList,S4),
(S4,getSmallQuote,S2), (S4,getBankQuote,S3),
(S2,getLoan,S5), (S3,getLoan,S5),
F S5
ltparameter name"scope" value"Session"/gt
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()
27
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 limplementazione di
servizi stateful in grado di mantenere lo stato
della conversazioni con i client. E compito del
programmatore implementare tali tipologie di
servizinel 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
tecnologiain 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.
Implementazione manuale
Skeleton
Implementazione automatica
Transition System
Tool
TS.xml
28
EJB e Web Services
Presentation Tier
Business Tier
Data Tier
HTTP/SOAP
Web Service
Java Application
Web Server(Apache Tomcat)
RMI
RMI-IIOP
Session FacadeMySessionBean
JDBC
Logica Business
Application Container
29
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 allinerno di JBoss basta copiare
la cartella axis-1_4 allinterno 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 lapplication container su cui gira
lEJB tramite protocollo RMI.
Per effettuare il deploy dellEJB come Web
Service bisogna creare il file .wsdd ed eseguire
il comando java org.apache.axis.client.AdminClien
t lhttp//localhost8080/services/AdminService
deploy.wsdd
NotaAttualmente 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.
30
EJB e Web Services Axis e JBoss
Web Services Deployment Descriptor
ltdeployment xmlns"http//xml.apache.org/axis/wsdd
/" xmlnsjava"http//xml.apache.org/axis/wsdd/pro
viders/java"gt ltservice name"BancaDeiPaschiDiSiena
WS" provider"javaEJB"gt ltparameter
name"wsdlTargetNamespace" value"http//banca_dei
_paschi_di_siena"/gt ltparameter
name"schemaUnqualified" value"http//To.banca_de
i_paschi_di_siena"/gt ltparameter
name"typeMappingVersion" value"1.2"/gt ltparamete
r name"jndiURL" value"jnp//localhost1099"/gt ltp
arameter name"jndiContextClass"
value"org.jnp.interfaces.NamingContextFactory"/gt
ltparameter name"beanJndiName" value"BancaPaschiE
JB"/gt ltparameter name"homeInterfaceName"
value"banca_dei_paschi_di_siena.BancaPSEJBHome"/gt
ltparameter name"remoteInterfaceName"
value"banca_dei_paschi_di_siena.BancaPSEJB"/gt ltpa
rameter name"className" value"banca_dei_paschi_d
i_siena.BancaPSEJBBean"/gt ltparameter
name"allowedMethods" value""/gt ltparameter
name"scope" valueRequest"/gt lttypeMapping
xmlnsns"http//To.banca_dei_paschi_di_siena"
qname"nsBankQuoteRequest"
type"javabanca_dei_paschi_di_siena.To.BankQuoteR
equest" serializer"org.apache.axis.encodi
ng.ser.BeanSerializerFactory"
deserializer"org.apache.axis.encoding.ser.BeanDes
erializerFactory" encodingStyle"http//sc
hemas.xmlsoap.org/soap/encoding/"
/gt lt/servicegt lt/deploymentgt
31
Conclusioni
Business Tier
Presentation Tier
Data Tier
Microsoft/Windows
Web Service
HTTP/SOAP
Web Server(Apache Tomcat) BancaDeiPaschiDiSienaWS
Properties propsnew Properties()props.put(Conte
xt.INITIAL_CONTEXT_FACTORY,"org.jnp.interfaces.Nam
ingContextFactory")props.put(Context.PROVIDER_UR
L, "jnp//localhost1099")Context ctxnew
InitialContext(props) Object obj
ctx.lookup(BancaPaschiEJB) BancaPSEJBHome home
(BancaPSEJBHome) javax.rmi.PortableRemoteObject.
narrow(obj,BancaPSEJBHome.class) BancaPSEJB
bancahome.create()
RMI
BancaPaschiEJB
JDBC
BancaPSEJB
Application Container
32
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 rich
iede 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 è lunica
specifica in grado di fornire un sistema di
definizione dei tipi di event basato sul
concetto di topic.
33
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-BrokeredNotificati
on - 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
34
Apache Muse
Il progetto Apache Muse è unimplementazione Java
delle specifiche - WS-ResourceFramework(WSRF) -
WS-BaseNotification(WSN) - WS-DistributedManagemen
t(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 OSGiil progetto comprende
infatti una serie di tools che permettono di
generare tutto quello che occorre per la
costruzione di un ipotetico scenario.
Larchitettura di Apache Muse è la
seguente
35
Apache Muse-Deployment Descriptor
ltmusegt ltroutergt ltjava-router-classgtlt/java-route
r-classgt ltlogginggt ltlog-filegtlt/log-filegt lt
log-levelgtlt/log-levelgt lt/logginggt ltpersistence
gt ltjava-persistence-classgtlt/java-persistence-cl
assgt ltpersistence-locationgtlt/persistence-locati
ongt lt/persistencegt lt/routergt ltresource-typegt
ltcontext-pathgtlt/context-pathgt ltwsdlgt ltwsdl-f
ilegtlt/wsdl-filegt ltwsdl-port-typegtlt/wsdl-port-ty
pegt lt/wsdlgt ltjava-id-factory-classgtlt/java-id-f
actory-classgt ltjava-resource-classgtlt/java-resour
ce-classgt ltcapabilitygt ltcapability-urigtlt/capa
bility-urigt ltjava-capability-classgtlt/java-capab
ility-classgt lt/capabilitygt lt/resource-typegt
ltcustom-serializergt
ltjava-serializable-typegtlt/java-serializable-typegt
ltjava-serializer-classgtlt/java-seri
alizer-classgt lt/custom-serializergt lt/musegt
36
Apache Muse - Scenario
37
Publisher- Architettura
Codice da pag.173 a pag.188 della Documentazione
38
Consumer-Architettura
Codice da pag.188 a pag.202 della Documentazione
39
Apache Muse - Subscribe
Subscriber
NotificationProducer
SubscriptionManager
SubscriptionRequest
Update
Forward
Update
SubscriptionResponse
40
Apache Muse - Notify
wsn-producer
NotificationProducer
SubscriptionManager
NotificationConsumer
wsn-consumer
Nuovo Evento
Update
Forward
Update
NotifyRequest
Update
Forward
NotifyResponse
Forward
Update
41
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

42
Conclusioni
Lo scopo di questa tesina è stato quello di
approfondire lo studio sullimplementazione, la
compilazione, il deploy e lesecuzione 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. Lutente
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 luso di Bpel nelle interazioni tra Web
Services.