JMS e WebServices nello sviluppo di architetture EDA e SOA

Transcript

JMS e WebServices nello sviluppo di
architetture EDA e SOA
Jürgen Assfalg
28 febbraio 2006
http://viplab.dsi.unifi.it/~assfalg/ - http://www.provincia.fi.it/
Jürgen Assfalg
JMS e Web services nello sviluppo di architetture EDA e SOA
1
Contesto
Integrazione di applicazioni di scala enterprise
caso di studio
Temi
●
●
●
●
●
●
●
Jürgen Assfalg
WS
Applicazioni enterprise
Architetture
Evoluzione delle tecnologie SW
EAI (Enterprise Applications Integration)
SOA / EDA
JMS
2
Per finalizzare l'uso della tecnologia alla
soluzione di un problema reale, si consideri
la gestione di un procedimento
amministrativo, quale il rilascio di
autorizzazione per trasporti eccezionali:
“La Provincia rilascia l'autorizzazione per il transito di
convogli eccezionali lungo gli itinerari delle strade
regionali e provinciali, nonché lungo le strade
comunali previa acquisizione di nulla-osta del
Comune territorialmente competente, se trattasi di
percorso misto che riguarda sia strade regionali e/o
provinciali sia comunali, oppure quando il percorso
richiesto interessi più comuni” [http://www.provincia.fi.it/]
Jürgen Assfalg
3
Front-office (interazione con l'utente)
Avvio del procedimento
presentazione dell'istanza tramite modulo
●
●
●
●
generalità del richiedente
periodo e percorso previsti per il trasporto
caratteristiche del mezzo
ulteriori dichiarazioni
Conclusione del procedimento
rilascio dell'autorizzazione
●
●
Jürgen Assfalg
percorso
costi
4
Nell'interazione tra Amministrazione e utente, un
aspetto importante nella gestione del
procedimento è la protocollazione di documenti
in arrivo e in partenza
●
registrazione del documento
oggetto, argomento, mittente, destinatari, ...
●
assegnazione di un numero di protocollo
numero progressivo (unico per ogni anno), data, classfica, ...
●
archiviazione del documento
–
–
del cartaceo
eventualmente anche digitalizzazione e archiviazione
elettronica
Jürgen Assfalg
5
Back-office
Le attività svolte “dietro le quinte” dagli addetti al
procedimento sono molteplici, e comprendono:
–
esame dell'istanza
–
verifica vincoli (ponti, gallerie, cantieri) sulle parti
di percorso di propria competenza
–
calcolo degli oneri
–
eventuale richiesta nulla-osta ad altri Enti (es.
Comuni interessati dal percorso)
–
produzione dell'autorizzazione
Jürgen Assfalg
6
Formalizzazione del problema: protocollo
Inizialmente si intende realizzare un servizio
software che consenta sia agli addetti allo
sportello (front-office) sia alle varie applicazioni
presenti nell'Amministrazione una
protocollazione unificata dei documenti
Tipicamente le Amministrazioni dispongono di
un'applicazione (il protocollo informatico) che,
raccogliendo i dati tramite opportune maschere,
consente agli addetti di registrare di documenti
Quali sono le tecnologie per rendere disponibile il
servizio anche alle applicazioni?
Jürgen Assfalg
7
Insieme di tecnologie software progettate per
consentire l'interazione tra applicazioni
Per garantire un'elevata interoperabilità, le
diverse componenti sono normate da
organismi di standardizzazione (es. W3C,
OASIS, WS-I, ...)
Jürgen Assfalg
8
Principali componenti
●
SOAP (http://www.w3.org/TR/soap/)
definisce come avviene il trasporto dei messaggi
●
Web Service Description Language - WSDL
(http://www.w3.org/TR/wsdl)
definisce il formato dei messaggi, ovvero la
struttura dell'informazione
●
UDDI
definisce indici e relativi criteri di ricerca per
catalogare e cercare web services
Jürgen Assfalg
9
Piattaforma
–
Java Development Kit 1.4.2
(http://java.sun.com/j2se/1.4.2/)
linguaggio Java, VM
–
Tomcat 5.0.x (http://tomcat.apache.org/)
application server
–
Axis 1.2.x (http://ws.apache.org/axis/)
insieme di strumenti per l'implementazione di WS e
relativi clients in Java
Nota: si sono volutamente prese in considerazione
versioni non troppo recenti, per garantire una
maggiore stabilità dell'intera piattaforma
Jürgen Assfalg
10
Axis prevede una modalità elementare per la
realizzazione di Web Services, che prevede i
seguenti passi:
–
definizione di una classe che realizza il servizio
–
installazione della classe su Axis
Una volta realizzato il servizio sarà possibile
–
consultarne il file WSDL
●
●
–
in questo caso generato automaticamente da Axis
descrive il formato dei messaggi accettati e prodotti
dal servizio, nonché le operazioni previste
accedervi tramite opportuno client
Jürgen Assfalg
11
Implementazione della logica del servizio
nel seguito è riportata una semplice classe, che
realizza la logica elementare del servizio di
protocollo, consentendo:
●
la registrazione di un documento
del documento si specifica l'oggetto
il servizio restituisce il numero di protocollo associatogli
la ricerca del documento, ovvero dell'oggetto
associato ad un determinato numero di protocollo
sono previsti meccanismi di sincronizzazione per
garantire che il registro di protocollo sia tenuto
correttamente anche in regime di concorrenza
(es. sequenza di numeri strettamente monotona)
●
Jürgen Assfalg
12
public class ProtocolloElementare {
public int registra( String oggetto ) {
return _registra( oggetto ); }
public String cerca( int numero ) {
return _cerca( numero ); }
private static int _registra( String oggetto ) {
int c;
synchronized ( registro ) {
contatore++;
registro.put(
new Integer( contatore ), oggetto );
c = contatore;
}
return c;
}
[...segue...]
Jürgen Assfalg
13
[...]
private static String _cerca( int numero ) {
String o;
synchronized ( registro ) {
o = (String) registro.get(
new Integer( numero ) );
}
return o;
}
private static int contatore = 0;
private static HashMap registro = new HashMap();
}
Jürgen Assfalg
14
Operativamente, una volta scritto il file con la classe
appena vista, per l'installazione è necessario
●
copiare il file sorgente nella cartella di Axis
%TOMCAT_HOME%\webapps\axis
dove %TOMCAT_HOME% è la cartella in cui è stato installato
Tomcat
●
cambiare l'estensione da .java a .jws
ProtocolloElementare.jws
Per verificare la corretta installazione del servizio è
sufficiente accedere alla pagina
http://localhost:10080/axis/ProtocolloElementare.jws
ipotizzando che Tomcat sia in ascolto sulla porta 10080 della
macchina da cui si accede, e che Axis sia installato nella
cartella sopra indicata
Jürgen Assfalg
15
Per consultare il file WSDL si può selezionare il
collegamento ipertestuale riportato nella pagina
sopra, oppure accedervi direttamente all'indirizzo
http://localhost:10080/axis/ProtocolloElementare.jws?wsdl
Jürgen Assfalg
16
WSDL è un formato XML per descrivere il
servizio in termini di
–
formato dei messaggi scambiati
utilizzando anche XML Schema
–
operazioni definite sull'endpoint (“terminale”)
–
binding, ovvero come avviene l'aggancio al
protocollo di trasporto (SOAP)
–
indirizzo a cui è raggiungibile il servizio
nel seguito è riportato il file WSDL prodotto
automaticamente da Axis per il servizio
elementare di protoccolo
Jürgen Assfalg
17
messaggi
endpoint
Jürgen Assfalg
18
Jürgen Assfalg
19
Tutto sommato facile...
–
la realizzazione del servizio si è ridotta alla
scrittura di una classe Java
–
il file WSDL, richiesto per ogni Web Service, è
stato prodotto automaticamente da Axis
ma...
–
quest'approccio non è sempre utilizzabile
es. la classe deve appartenere al package predefinito
–
Jürgen Assfalg
manca il client per il servizio
20
Il procedimento generale è diverso:
–
definizione di un servizio e delle operazioni, cioè
definizione di un'interfaccia:
+ registra( : String ) : Protocollo
+ cerca( : int ) : String
NOTA
Rispetto alla prima implementazione del protocollo, che
restituiva un intero, in questo caso si prevede un tipo definito
ad hoc (Protocollo), che oltre al numero conterrà anche
l'anno.
Un tale tipo di dato non è previsto dagli standards XML
Schema e SOAP (mentre lo sono, ad esempio, interi e
stringhe), e quindi dovrà essere adeguatamente trattato
Jürgen Assfalg
–
21
creazione del file WSDL
qualora non si sia ancora esperti di WSDL si può
sempre ricorrere a Java2WSDL (uno strumento
fornito insieme ad Axis), che crea un file WSDL a
partire da una classe o un'interfaccia Java
java org.apache.axis.wsdl.Java2WSDL
--style document --use LITERAL -o protocollo.wsdl
-l"http://localhost:10080/axis/services/WSServizio"
-n "urn:protocollo" -p"protocollo" "urn:protocollo"
protocollo.WSServizio
in generale, l'editing diretto di un file WSDL risulta
comunque essere un'attività abbastanza pesante, per
cui si raccomanda l'uso di un editor XML o degli
strumenti presenti negli ambienti di sviluppo integrati
(es. Eclipse, con i plugins del progetto WTP)
Jürgen Assfalg
22
–
generazione delle classi Java
java org.apache.axis.wsdl.WSDL2Java
-s -p protocollo.wsdl protocollo.wsdl
dato il file WSDL, il programma WSDL2Java del
pacchetto Axis provvede a generare tutte le classi
accessorie per realizzare, in maniera trasparente al
programmatore, il collegamento tra client e server,
secondo i protocolli previsti per lo specifico servizio
(es. SOAP, HTTP, ...)
Jürgen Assfalg
23
In generale, WSDL2Java può generare
–
per ogni tipo: una classe Java
ed eventuale holder
–
per ogni portType: un'interfaccia Java
–
per ogni binding
●
●
●
–
per ogni service:
●
●
Jürgen Assfalg
una classe stub
una classe skeleton
un modello (template) per l'implementazione
un'interfaccia Java del servizio
un'implementazione del servizio (locator)
24
Jürgen Assfalg
25
Server
disponendo già di una classe che realizza la logica
del registro di protocollo (la classe
ProtocolloElementare, vista in
precedenza), l'implementazione del Web Service
si riduce al completamento della classe
WSProtocolloSoapBindingImpl in maniera
tale da adattare la classe esistente alla nuova
interfaccia richiesta, cioè WSServizio
v. anche design pattern Adapter
Jürgen Assfalg
26
public class WSProtocolloSoapBindingImpl
implements WSServizio {
public Protocollo registra( String oggetto )
throws java.rmi.RemoteException {
int numero = r.registra( oggetto );
Protocollo p = new Protocollo();
p.setNumero( protocollo );
p.setAnno( 2006 );
adattamento
return protocollo; }
public String cerca( int numero )
throws java.rmi.RemoteException {
return r.cerca( numero ); }
static ProtocolloElementare r =
new ProtocolloElementare(); }
Jürgen Assfalg
27
Installazione del servizio
–
copiare le varie classi sull'application server
–
attivare il servizio su Axis
utilizzando gli strumenti forniti con il pacchetto Axis
java org.apache.axis.client.AdminClient deploy.wsdd
il formato WSDD (Web Sevice Deployment Descriptor),
specifico del pacchetto Axis, serve per indicare al
server informazioni utili per la configurazione
del servizio
operazioni e relativi parametri
classe che implementazione il servizio
mappatura dei parametri complessi
Jürgen Assfalg
28
WSDD
<deployment [...] >
<service name="WSProtocollo" provider="java:RPC" style="rpc" use="encoded">
[...] <parameter name="wsdlServiceElement" value="WSServizioService"/>
<parameter name="wsdlServicePort" value="WSProtocollo"/>
<parameter name="className"
value="protocollo.wsdl.WSProtocolloSoapBindingImpl"/>
<parameter name="wsdlPortType" value="WSServizio"/>
<operation name="registra" qname="operNS:registra" [...]
returnType="rtns:Protocollo">
<parameter qname="in0" type="tns:string"/>
</operation> [...]
<typeMapping
xmlns:ns="urn:protocollo"
qname="ns:Protocollo"
type="java:protocollo.wsdl.Protocollo"
serializer="org.apache.axis.encoding.ser.BeanSerializerFactory"
deserializer="org.apache.axis.encoding.ser.BeanDeserializerFactory"
[...]
/> [...]
Jürgen Assfalg
29
Client (statico)
l'accesso al servizio dal client richiede l'uso di un
oggetto WSServizioServiceLocator, (classe
generata automaticamente dallo strumento
WSDL2Java di Axis), che serve per ottenere il
riferimento al proxy locale del servizio
stabilito il contatto con il servizio attraverso un
oggetto locator, l'accesso al servizio avviene
semplicemente invocando i metodi di un oggetto
(il proxy, appunto) che implementa l'interfaccia
WSServizio, senza curarsi di ciò che sta dietro
Jürgen Assfalg
30
WSServizioService service =
new WSServizioServiceLocator();
String endpointUrl =
"http://localhost:10080/axis/services/WSProtocollo";
WSServizio port = service.getWSProtocollo(
new URL( endpointUrl ) );
for ( int i = 0; i < numeroProve; i++ ) {
String o = "prova " + i;
int n = port.registra( o ).getNumero();
numeri[ i ] = n; }
for ( int i = numeroProve; i > 0; i-- ) {
int n = numeri[ i - 1 ];
String o = port.cerca( n ); }
Jürgen Assfalg
31
Alternative al client statico
–
Dynamic Proxy
il proxy viene generato dinamicamente quando
si accede al servizio; funziona finché non
cambia la signature dei metodi usati dal client
–
Dynamic Invocation
si accede alle operazioni del servizio tramite
chiamate standard
Call call = (Call) service.createCall();
call.setTargetEndpointAddress( endpoint );
call.setOperationStyle( opStyle );
call.setOperationUse( opUse );
call.addParameter( new Qname( "http://ws", "numero"),
XMLType.XSD_INT, ParameterMode.IN );
call.setOperationName( "cerca" );
call.setReturnType( XMLType.XSD_STRING );
Jürgen Assfalg
32
Per definire un Web service è utile capire
alcuni dettagli relativi alla formattazione dei
messaggi, sia a livello di definizione in WSDL
che di trasmissione con SOAP
WSDL prevede due parametri
–
STILE (binding con SOAP)
RPC | DOCUMENT | WRAPPED
Java2WSDL: -y, --style <argument>
–
USE (nella codifica del messaggio SOAP)
ENCODED | LITERAL
Java2WSDL: -u, --use <argument>
Jürgen Assfalg
33
Per comprendere gli effetti delle diverse
combinazioni dei valori dei due parametri si
può esaminare sia il file WSDL, sia il traffico
SOAP tra client e server
Per l'analisi del traffico si può utilizzare un'altro
strumento di Axis: TCPMon
java org.apache.axis.utils.tcpmon 9080 localhost 10080
il programma realizza un proxy TCP, che raccoglie tutto
il traffico indirizzato alla porta locale 9080, lo registra,
e quindi lo indirizza alla porta 10080 di localhost;
analogamente per il traffico di ritorno
è necessario cambiare l'indirizzo dell'endpoint fornito al client
Jürgen Assfalg
34
Client
risposta
inolrata
richiesta
TCPMon
richiesta
inolrata
risposta
Server
Jürgen Assfalg
35
Document - literal
Jürgen Assfalg
36
==== Request ====
POST /axis/services/WSProtocolloDL HTTP/1.0
Header HTTP
Content-Type: text/xml; charset=utf-8
Accept: application/soap+xml, application/dime, multipart/related, text/*
User-Agent: Axis/1.2.1
Host: localhost:9080
Cache-Control: no-cache
Pragma: no-cache
SOAPAction: ""
Content-Length: 302
<?xml version="1.0" encoding="UTF-8"?>
Messaggio SOAP
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
Corpo messaggio SOAP
<in0 xmlns="urn:protocollo">prova 1</in0>
</soapenv:Body>
</soapenv:Envelope>
Jürgen Assfalg
37
==== Response ====
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: text/xml;charset=utf-8
Date: Mon, 27 Feb 2006 16:42:38 GMT
Connection: close
<?xml version="1.0" encoding="utf-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<registraReturn xmlns="urn:protocollo">
<anno>2006</anno>
<numero>1</numero>
</registraReturn>
</soapenv:Body>
</soapenv:Envelope>
Jürgen Assfalg
38
RPC - encoded
Jürgen Assfalg
39
==== Request ====
[...]
<ns1:registra
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:ns1="urn:protocollo">
<in0 xsi:type="soapenc:string"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/">prova
1</in0>
</ns1:registra>
[...]
Jürgen Assfalg
40
==== Response ====
[...]
<ns1:registraResponse
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:ns1="urn:protocollo">
<registraReturn href="#id0"/>
</ns1:registraResponse>
<multiRef id="id0" [...] xsi:type="ns2:Protocollo" [...]>
<anno href="#id1"/>
<numero href="#id2"/>
</multiRef>
<multiRef id="id1" [...] xsi:type="xsd:int" [...]>2006</multiRef>
<multiRef id="id2" [...] xsi:type="xsd:int" [...]>1</multiRef>
[...]
Jürgen Assfalg
41
Wrapped - literal
Jürgen Assfalg
42
==== Request ====
[...]
<registra xmlns="urn:protocollo">
<in0>prova 1</in0>
</registra>
[...]
<in0 xmlns="urn:protocollo">prova 1</in0>
==== Response ====
[...]
<registraResponse xmlns="urn:protocollo">
<registraReturn>
<registraReturn xmlns="urn:protocollo">
<anno>2006</anno>
<anno>2006</anno>
<numero>1</numero>
<numero>1</numero>
</registraReturn>
</registraReturn>
</registraResponse>
[...]
Jürgen Assfalg
–
Document-literal
●
●
●
●
–
Obsoleto
le altre combinazioni
●
Jürgen Assfalg
supera limite di un solo parametro in document-literal,
accorpando più parametri in uno solo
RPC-encoded
●
–
messaggi SOAP più leggeri
consente uso strumenti per XML (es. validazione)
flessibilità nella definizione del servizio
maggiori oneri per lo sviluppatore (XML Schema!)
Wrapped-literal
●
–
43
irrilevanti
44
alternative
●
SwA (SOAP with Attachments) con MIME
il messaggio che transita è composto da più parti
MIME multipart/related: la prima contiene la
busta SOAP, le altre gli allegati.
Buona interoperabilità
Axis lo supporta
JWSDP di SUN lo supporta
WS-I (“WS-I Attachments Profile 1.0”)
Microsoft NON prevede supporto per SwA in .NET.
Jürgen Assfalg
46
L’uso di SwA può essere descritta direttamente nel
documento WSDL che descrive il web service
che utilizza l’invio e la ricezione di allegati.
Server
Message req = MessageContext.getCurrentContext().getRequestMessage();
Attachments msgAtts = req.getAttachmentsImpl();
AttachmentPart parts[] =
new AttachmentPart[ msgAtts.getAttachmentCount() ];
Iterator it = msgAtts.getAttachments().iterator();
for ( int i = 0; it.hasNext(); i++) parts[ i ] = (AttachmentPart) it.next();
[...]
DataHandler dh = parts[ 0 ].getDataHandler();
InputStream in = dh.getInputStream();
Jürgen Assfalg
47
Client
Service service = new Service();
call = (Call) service.createCall();
call.setTargetEndpointAddress( endpoint );
call.setOperationStyle( opStyle );
call.setOperationUse( opUse );
call.addParameter( new Qname( "http://ws", "nome"), XMLType.XSD_STRING,
ParameterMode.IN );
call.addParameter( new QName("http://ws", "length"), XMLType.XSD_INT,
ParameterMode.IN );
call.setOperationName( "uploadAttachmentSwA" );
call.setReturnType( XMLType.AXIS_VOID );
DataHandler attachmentFile = new DataHandler( new FileDataSource( file ) );
call.setProperty( Call.ATTACHMENT_ENCAPSULATION_FORMAT,
Call.ATTACHMENT_ENCAPSULATION_FORMAT_MIME);
call.addAttachmentPart( attachmentFile );
call.invoke( new Object[] { "Allegato.pdf", new Integer( filesize ) } );
call.removeAllParameters();
Jürgen Assfalg
48
●
WS-Attachments con DIME (Direct Internet
Message Encapsulation)
–
unico formato supportato da Microsoft.
–
DIME prevede un meccanismo di
impacchettamento molto più efficiente del MIME.
più veloce di SwA.
–
Bassa interoperabilità
sia DIME che WS-Attachments sono delle IETF Internet
Drafts abbastanza datate (luglio 2002)
nessuno sta portando avanti il processo di
standardizzazione
Jürgen Assfalg
49
Microsoft supporta solo DIME in .NET
tramite il pacchetto WSE (Web Services
Enhancements).
SUN lo supporta con SAAJ
Axis lo supporta
L’uso di WS-Attachments può essere descritta
direttamente nel documento WSDL che descrive
il web service che utilizza l’invio e la ricezione di
allegati.
Jürgen Assfalg
50
●
MTOM (SOAP Message Transmission and
Optimization Mechanism)
–
si basa su XOP (XML-binary Optimized
Packaging)
Working Draft della W3C tratta l'ottimizzazione dell’invio
di dati binari in un documento XML
–
Jürgen Assfalg
MTOM è anch’essa una Working Draft della
W3C
51
L’invio di un documento come allegato è
conveniente
–
dimensione del documento non influisce su
quella del messaggio SOAP: i tempi di creazione
e parsing sono pressoché costanti con
l’aumentare della dimensione del documento
–
il documento non deve essere codificato (come
avviene invece con Base64 nel corpo)
Tuttavia la non compatibilità degli standard
SwA e WS-Attachments può limitare
l’interoperabilità
Jürgen Assfalg
52
●
Conformità
–
WSDL delle interfacce
–
messaggi SOAP
–
conforme con standards SwA e WS-Attachments
●
●
●
servizio sviluppato con Axis opera in modo
trasparente con entrambi gli standard
dalla interfaccia Java di un servizio che riceve
allegati, Axis non riesce a generare automaticamente
una descrizione WSDL corretta del servizio
Non conformità
–
Jürgen Assfalg
interoperabilità secondo “WS-I Basic Profile 1.1”
53
Applicazioni aziendali, o anche sistemi
informativi, oppure ancora elaborazione dati
[M.Fowler, PoEA]
–
–
–
–
Jürgen Assfalg
Grandi quantità di dati persistenti
Accesso concorrente da parte di più utenti
Numerose maschere per immissione dati
Spesso sono integrate con altre applicazioni
54
In molti casi le applicazioni nascono per
soddisfare ben precise necessità di
automazione di singole unità di
un'organizzazione (dipartimenti), ovvero
hanno lo scopo di replicare sul calcolatore
consolidate procedure manuali
Jürgen Assfalg
55
In questo scenario le applicazioni
rappresentano lo strumento attraverso il
quale si eseguono tutte le attività associate
alla diverse fasi lungo cui si sviluppa una
determinata procedura.
Poiché tali applicazioni affrontano in profondità
un determinato problema, si dice che hanno
natura “verticale”.
Jürgen Assfalg
56
Evoluzione delle architetture
–
monolitiche
incorporano tutte le routine per la gestione e la
manipolazione dei dati
non offrono altre “aperture” se non l'interfaccia utente
Jürgen Assfalg
–
57
client/server, o a 2 livelli
●
●
client: presentazione
server: sorgente dati (DBMS)
Client
GUI
ClientBusiness logic
GUI
Database logic
Business logic
Database
Server
Database logic
SQL
Jürgen Assfalg
58
Vantaggi
–
architettura semplice
Svantaggi
–
ridotta scalabilità
●
–
difficoltà di manutenzione
●
●
Jürgen Assfalg
richiede elevata larghezza di banda
logica applicativa distribuita (fat client)
logica applicativa nel DBMS (stored procedures)
59
Quando la complessità della logica applicativa
(regole, validazione, calcoli) è cresciuta, si
sono identificati 3 livelli:
–
Presentazione
dei dati all'utente, ma anche ad un programma
–
Dominio
incorpora la logica applicativa
–
Sorgente dati
gestisce la persistenza dei dati
Jürgen Assfalg
60
Client
Middle-tier
server
GUI
Database
Business logic
Client
Database logic
Server
GUI
RPC, DCOM, …
Jürgen Assfalg
SQL
61
Solo lo sviluppo del web, e quindi la necessità
di evitare la replicazione della logica di
dominio in diverse interfacce, ha fatto
decollare lo sviluppo delle architetture a 3 (o
più) livelli
In generale, si possono concepire applicazioni
a N livelli. Tuttavia, le architetture a 2 o 3
livelli coprono la maggior parte delle
applicazioni
Jürgen Assfalg
62
Componenti in esecuzione su differenti nodi in
maniera concorrente
Cooperazione tra i componenti per lo
svolgimento di compiti complessi
Vantaggi:
–
riusabilità dei componenti
–
scalabilità del sistema (load balancing)
–
condivisione di risorse
–
alta disponibilità (fail-over)
Jürgen Assfalg
63
La realizzazione di un sistema di applicazioni
distribuite richiede un approccio differente da
quello utilizzato per i sistemi centralizzati, in
termini sia di architetture che di tecnologie
Jürgen Assfalg
64
Protocolli e ed architetture client/server
● TCP/IP
● RPC
Ambienti ad oggetti distribuiti
da classi a componenti
●
●
●
●
RMI
DCOM
CORBA
EJB
Jürgen Assfalg
65
Oggetti/componenti distribuiti presentano
(anche solo per considerazioni relative alle
prestazioni)
●
una granularità meno fine rispetto alle classi
●
un'interfaccia definita e relativamente stabile
(non controllando sempre sia il client che il server)
Limitati ad una singola organizzazione (o
addirittura ad una sua sede) a causa di
●
prestazioni
●
sicurezza
Jürgen Assfalg
66
Nasce dalla necessità di
●
consolidare e aggregare il patrimonio informativo
(es. data mining, data warehousing, ...)
●
integrare le procedure
(es. cooperazione applicativa, ...)
●
adeguare i sistemi informativi alle misure
organizzative in atto
(es. fusioni, riorganizzazioni, ...)
●
maggiore competitività
(es. riduzione dei tempi, ...)
Jürgen Assfalg
67
Diversi scenari:
–
Business to consumer (B2C)
utilizzata da soggetti esterni all'organizzazione
es. commercio elettronico, prenotazione voli, ...
–
Business to business (B2B)
scambio dati senza intervento umano
es. gestione magazzino, pagamento elettronico
–
Back-end
eseguita periodicamente senza input diretto
es. telecomunicazioni, invio newletter
Jürgen Assfalg
68
Integrazione di applicazioni (Enterprise
Application Integration, o EAI) e sistemi
distribuiti sono tematiche diverse, che
tuttavia si possono incontrare
Jürgen Assfalg
69
Operazione complessa, che coinvolge ogni
livello di un sistema informativo
●
l'integrazione dei processi che realizzano le
logiche aziendali deve guidare l'integrazione delle
applicazioni
le applicazioni devono agevolare lo scambio e
l'elaborazione delle informazioni necessarie allo
svolgimento dei processi
●
punto di partenza è quindi un'attività di BPE/BPR
modellazione e gestione dei processi (combinazione di
attività, procedure, organizzazioni, informazioni richieste
e prodotte, strumenti richiesti in ogni fase
Jürgen Assfalg
70
●
A livello delle applicazioni, lo scopo è quello
di mettere insieme dati e funzionalità di
un'applicazione con quelli di un'altra.
●
Per consentire l'integrazione delle
applicazioni è necessario realizzare, oltre a
quella dei processi, l'integrazione dei dati
Identificazione, catalogazione e modelllazione dei
dati, quindi possono essere condivisi/distribuiti
tra DBMS
Jürgen Assfalg
●
71
Per raggiungere una completa integrazione
dei dati è necessario adottare degli
standards, che promuovano la condivisione e
la distribuzione dell'informazione
COM+/DCOM, CORBA, EDI, JavaRMI, XML
●
Per completare l'integrazione dei sistemi,
devono essere integrate le piattaforme,
ovvero le architetture, l'hardware, il software
e l'infrastruttura telematica
Processi e strumenti che consentano ai sistemi di
comunicare in maniera ottimale e sicura
Jürgen Assfalg
72
Principali architetture per la realizzazione di
sistemi distribuiti:
–
Service-Oriented Architecture (SOA)
–
Event-Driven Architecture (EDA)
Le architetture SOA ed EDA definiscono
–
Quali sono i componenti ed i loro ruoli
–
Le interfacce presentate da ogni componente
–
Le modalità di interazione
Jürgen Assfalg
73
SOA è un approccio alla progettazione
client/server che prevede un accoppiamento
lasco fra fornitori di servizi (service providers)
e consumatori di servizi (service consumers).
–
come anche per classi e componenti, l'obiettivo
di SOA è il riuso di software, ad un livello di
granularità ancora meno fine (riducendo quindi
ulteriormente le dipendenze), ovvero ad un
livello di astrazione più alto.
–
netta separazione fra l'interfaccia e
l'implementazione del servizio
Jürgen Assfalg
74
–
l'interfaccia definisce un contratto tra fornitore e
consumatore, e deve essere pubblica e
vincolante per le parti
definita a livello sintattico tramite un apposito linguaggio
(IDL nel caso di Corba, WSDL nel caso di Web
Services, ...)
progettazione per interfacce non è un concetto nuovo
(può essere efficacemente applicato anche alla
programmazione OO, ma nel momento in cui si
travalicano i limiti di un'applicazione—o addirittura di
un'organizzazione—esso è molto più vincolante
–
Jürgen Assfalg
l'implementazione realizza la logica applicativa
(“business logic”), seguendo un approccio di tipo
black-box
75
Nella pratica i servizi possono essere
implementati:
●
sviluppando un modulo ex-novo
●
incapsulando un modulo software preesistente
v. pattern Adapter
●
componendo una serie di moduli preesistenti
v. pattern Facade
gli ultimi due consentono riuso di componenti
Jürgen Assfalg
76
●
Ruoli: consumatore, fornitore e registro
–
Fornitore espone una interfaccia documentata
–
Interazioni sono tipicamente di tipo “request / reply”
–
Interazioni 1:1 tra fornitore e consumatore
●
delega dei ruoli
(un fornitore può essere a sua volta un consumatore)
●
utile un maggiore disaccoppiamento client/server
find-bind-invoke (o Client-Dispatcher-Server)
Jürgen Assfalg
77
Vantaggi:
–
sviluppo incrementale di un sistema informativo
–
riuso di componenti esistenti
–
sviluppo a basso costo di nuove applicazioni (se
esistono già i servizi è sufficiente comporli)
–
chiarezza della topologia dell'applicazione (la
trasparenza è imposta ad un livello più basso)
Jürgen Assfalg
78
Limitazioni
–
maggiore complessità (progetto interfaccia,
stub/skeleton, ... => non è vero che SOA è
ingegneria del software semplice)
–
altri falsi miti: indipendenza dalla tecnologia (per
i singoli servizi, ma non per l'infrastruttura!) o dal
venditore
–
non ha senso per applicazioni in ambito locale
che hanno vita breve
–
non è raccomandato per applicazioni che
richiedono un'interazione asincrona ed
unidirezionale
Jürgen Assfalg
79
Web Services sono lo strumento oggi più usato
per la realizzazione di sistemi distribuiti con
architettura SOA
Web Services applicano i principi SOA:
–
impongono Web Services Description Language
(WSDL) per la definizione delle interfacce
–
impongono SOAP come standard per il formato
dei messaggi
–
lasciano libertà nella scelta dei
protocolli di comunicazione:
HTTP, SMTP, FTP, etc.
Jürgen Assfalg
80
–
Web Services rappresentano la soluzione che
garantisce maggiore interoperabilità, e
comportano oneri di gestione ridotti
–
esistono implementazioni per numerosi linguaggi
e piattaforme, e quindi consentotno il riuso di
componenti già esistenti
–
comunque, la relazione tra SOA e Web Services
non è biunivoca
WS rappresentano una possibile tecnologia per SOA,
ma non sono l'unica; viceversa, possono essere
utilizzati per implementare anche architetture diverse
–
Jürgen Assfalg
i WS hanno avuto e avranno ancora un ruolo
non indifferente nella diffusione di SOA
81
Publish & Subscribe
– pubblicatore rileva cambiamenti di stato
– notifica i
cambiamenti
direttamente
ai sottoscrittori
Jürgen Assfalg
82
Message Oriented Middleware (MOM)
●
consente la cooperazione applicativa
secondo un modello EDA
●
funzionalità di un Message Server
–
scambio dei messaggi
–
persistenza (database o file testuali)
–
affidabilità del trasferimento
–
filtraggio dei messaggi per ottimizzare la
distribuzione
Jürgen Assfalg
84
–
richiede standardizzazione dei messaggi
–
realizza collegamenti 1:m (senza binding)
–
il modulo sorgente (source) non fa (non può
fare) alcuna ipotesi sulla destinazione (sink)
–
il routing è determinato dalla destinazione e dal
contenuto del messaggio
–
per implementare nuove logiche è sufficiente
aggiungere/rimuovere sorgenti e/o destinazioni
Jürgen Assfalg
SOA
●
●
●
●
●
●
●
●
●
●
Interazione req[/res]
(bidirezionale)
sincrona
tipico, non necessario
transazioni
un nodo fa una richiesta per
chiedere un'elaborazione
il nodo chiamante conosce il
chiamante (comunicazione
diretta) e dipende da questo
relazione 1:1
routing gestito dal client
flusso lineare in una gerarchia di
moduli
interrogazione
transazione composta
Jürgen Assfalg
85
EDA
●
●
●
●
●
●
●
●
●
●
pubblicazione evento
(unidirezionale)
asincrona
elaborazioni che si sviluppano
nel tempo
nodo genera un evento a seguito
completamento elaborazione
il nodo che genera evento non
conosce chi lo processerà
(comunicazione indiretta)
relazione m:n
routing determinato dal
destinatario
flussi asincroni e paralleli
aggiornamento
elaborazione multi-fase
86
Jürgen Assfalg
89
Topic publisher
ctx = new InitialContext();
Topic topic = (Topic) ctx.lookup( "topic" );
TopicConnectionFactory tcfactory = (TopicConnectionFactory)
ctx.lookup( "tcf" );
ctx.close();
TopicConnection tconn = tcfactory.createTopicConnection();
TopicSession tsession = tconn.createTopicSession( true, 0 );
TopicPublisher tpublisher =
tsession.createPublisher( topic );
TextMessage m = tsession.createTextMessage();
for ( int i = 0; i < N; i++ ) {
m.setText( "Messaggio " + i );
tpublisher.publish( m );
}
tsession.commit();
Jürgen Assfalg
90
TopicSession tsession =
Topic subscriber
tconn.createTopicSession(false,
(asincrono)
javax.jms.Session.AUTO_ACKNOWLEDGE);
TopicSubscriber tsubscriber =
tsession.createSubscriber( topic );
tsubscriber.setMessageListener( new MsgListener() );
tconn.start();
...
tconn.close();
public class MsgListener implements MessageListener {
...
public void onMessage( Message m ) {
try {
if ( m instanceof TextMessage )
System.out.println( ((TextMessage) m).getText() );
else if ( m instanceof ObjectMessage )
System.out.println(((ObjectMessage) m).getObject());
} catch (JMSException jE) {...}
... } }
Jürgen Assfalg
91
Queue sender
ctx = new InitialContext();
Queue queue = (Queue) ctx.lookup("queue");
QueueConnectionFactory qcfactory = (QueueConnectionFactory)
ctx.lookup( "qcf" );
ctx.close();
QueueConnection qconn = qcfactory.createQueueConnection();
QueueSession qsession = qconn.createQueueSession( true, 0 );
QueueSender qsender = qs.createSender( queue );
TextMessage m = qsession.createTextMessage();
for( int i = 0; i < N; i++ ) {
msg.setText( "Messaggio numero " + i );
qsender.send( m );
}
qsession.commit();
...
qconn.close();
Jürgen Assfalg
92
Queue receiver
(sincrono)
QueueConnection qconn = qcfactory.createQueueConnection();
QueueSession qsession = qconn.createQueueSession( true, 0 );
QueueReceiver qreceiver =
qsession.createReceiver( queue );
Message m;
qconn.start();
for( int i = 0; i < N; i++ ) {
m = qreceiver.receive();
if (msg instanceof TextMessage)
System.out.println( "Ricevuro: " +
((TextMessage) m).getText());
}
Jürgen Assfalg
93
Queue queue = (Queue) ctx.lookup("queue");
Topic topic = (Topic) ctx.lookup("topic");
ConnectionFactory cfactory =
(ConnectionFactory) ctx.lookup("cf");
ctx.close();
Topic publisher
Queue sender
Connection conn = cfactory.createConnection();
Session session = conn.createSession( true, 0 );
MessageProducer producer = session.createProducer( null );
TextMessage m = session.createTextMessage();
for( int i = 0; i < N; i++ ) {
m.setText( "Messaggio numero " + i );
producer.send( queue, m );
producer.send( topic, m );
}
session.commit();
Jürgen Assfalg
94
Messaggio
–
Header
destination, delivery mode, id, time stamp, expiration,
redelivered, prioriti, reply to, correlation id
–
Properties
consentono la defnizione di message selectors (filtri
definiti dal singolo client)
–
Payload
Jürgen Assfalg
95
Delivery mode
–
persistent (once-and-only-once)
–
non persistent (at-most-once)
Acknowledge
●
●
produttore: publish() / send() sono sincrone
consumatore
–
–
–
Jürgen Assfalg
AUTO_ACKNOWLEDGE
lo fa il sistema; non garantisce avvenuta elaborazione
DUPS_OK_ACNOWLEDGE
può ridurre costi
CLIENT_ACKNOWLEDGE (msg.acknowledge())
ricezioni batch
96
Durable subscriber
session.createDurableSubscriber(<topic>, <name>)
Temporary topics
replyTo
Persistenza
fr.dyade.aaa.util.NTransaction
Jürgen Assfalg
97
JORAM (http://joram.objectweb.org/)
–
Open Source
–
Conforme specifica JMS 1.1
–
Progetto attivo
–
Documentazione dettagliata
–
Supporta TCP, SOAP, JNDI, clustering
–
Strumenti di amministrazione
–
Dimensione massima del messaggio (12MB)
Jürgen Assfalg
98
Server
–
Connection manager service
–
TCP proxy service
–
JNDI service
<?xml version="1.0"?>
<config>
<property name=”Transaction” value=”fr.dyade.aaa.util.NullTransaction”/>
<server id="0" name="S0" hostname="localhost">
<service class="org.objectweb.joram.mom.proxies.ConnectionManager"
args=”root root”/>
<service class="org.objectweb.joram.mom.proxies.tcp.TcpProxyService"
args="16010"/>
<service class="fr.dyade.aaa.jndi2.server.JndiServer" args="16400"/>
</server>
</config>
Jürgen Assfalg
99
Client
file di configurazione (jndi.properties)
java.naming.factory.initial
fr.dyade.aaa.jndi2.client.NamingContextFactory
java.naming.factory.host
localhost
java.naming.factory.port
16400
Jürgen Assfalg
100
jAMT
JORAM Administration & Monitoring Tool
–
server
configurazione, arresto
–
connection factories
creazione, eliminazione
–
destinations
creazione, configurazione, monitoraggio, eliminazione
–
utenti
creazione, eliminazione, cambio password
Jürgen Assfalg
101
Jürgen Assfalg
102
Altre caratteristiche interessanti:
–
possibilità di usare SOAP
–
API di amministrazione
Jürgen Assfalg
103
AdminModule.connect("root", "root", 60);
Queue queue = (Queue) Queue.create("queue");
Topic topic = (Topic) Topic.create("topic");
User user = User.create("anonymous", "anonymous");
queue.setFreeReading();
topic.setFreeReading();
queue.setFreeWriting();
topic.setFreeWriting();
javax.jms.ConnectionFactory cf =
TcpConnectionFactory.create("localhost", 16010);
javax.jms.QueueConnectionFactory qcf =
QueueTcpConnectionFactory.create("localhost", 16010);
javax.jms.TopicConnectionFactory tcf =
TopicTcpConnectionFactory.create("localhost", 16010);
javax.naming.Context jndiCtx = new javax.naming.InitialContext();
jndiCtx.bind("cf", cf);
jndiCtx.bind("qcf", qcf);
jndiCtx.bind("tcf", tcf);
jndiCtx.bind("queue", queue);
jndiCtx.bind("topic", topic);
jndiCtx.close();
AdminModule.disconnect();
Jürgen Assfalg
104
Stato attuale
–
Ricezione istanza: carta/fax
–
Protocollo: applicazione verticale distribuita, con
architettura a 2/3 livelli (Web ASP.NET)
–
Determinazione percorso: cartine stradali
–
Verifica vincoli: uffici competenti
–
Calcolo degli oneri: applicazione monolitica
(programma Access)
–
Nulla-osta altri Enti: fax
–
Trasmissione autorizzazione: carta/fax
Jürgen Assfalg
105
Scenario per il (prossimo) futuro
–
Presentazione istanza tramite
carta/fax/portale/PEC
–
Gestione informatizzata dei procedimenti
avvio e avanzamento iter, interrogazione stato
–
Applicazione verticale per trasporti eccezionali
gestione dati, calcolo percorso, verifica vincoli
–
Integrazione con s.i. del catasto strade
grafo stradale, pertinenze, ...
Jürgen Assfalg
106
Ipotesi di lavoro
–
protocollazione
la necessità di restituire un numero di protocollo
all'utente che presenta l'istanza allo sportello
suggerisce la realizzazione del registro di protocollo
come servizio sincrono
la registrazione è realizzata tramite Web Services
–
collegamento gateway PEC
periodicamente gateway si collega, trasmettendo i
messaggi di PEC da protocollare e leggendo le
registrazioni di protocollo dei messaggi già protocollati
non richiedendo una risposta immediata per i messaggi
trasmessi, è indicato un approccio asincrono
Jürgen Assfalg
107
la molteplicità delle elaborazioni che possono
essere associate ad un documento protocollato
suggeriscono un approccio basato su messaggi
–
avvio del procedimento
i messaggi vengono instradati verso il sistema integrato
per la gestione dei documenti
–
archiviazione ottica
i tempi lunghi associati a quest'operazione, così come
la necessità di usare con giudizio le risorse di rete
conferma la scelta di un approccio asincrono basato
su messaggi
Jürgen Assfalg
108
JMS
2
WS
<<Queue>>
da protocollare
<<Topic>>
protocollati
send
receive
Gateway
PEC
Jürgen Assfalg
notify
<<WS>>
Protocollo
publish
notify
Avvio
procedimento
request/
response
receive
Archiviazione
ottica
request/
response
altra
applicazione
●
OASIS (http://www.oasis-open.org/)
●
Presentazione su Architectural Patterns
(http://viplab.dsi.unifi.it/~assfalg/documenti/apea.pdf)
●
E.Gamma, R.Helm, R.Johnson, J.Vlissides, Design
Patterns, Addison Wesley, 1994
M.Fowler, Patterns of Enterprise Application
Architecture, Addison Wesley, 2003
F.Buschmann et al., Pattern-Oriented Software
Architecture: A System of Patterns, J. Wiley, 1996
D. Schmidt et al., Pattern-Oriented Software
Architecture: Patterns for Concurrent and
Networked Objects, J. Wiley, 2000
●
●
●
Jürgen Assfalg
109
110

JMS e WebServices nello sviluppo di architetture EDA e SOA

Transcript

Documenti analoghi

I.P.S.S.A. NINO BERGESE

Finale 2006 - [Makoma So Adea]

sarah becchio_cv - studioerrante architetture

Un film per l`Europa

Author Index

Displasia ectodermica ipoidrotica legata al cromosoma X

Metodo di stima del moto in una sequenza video mediante

LARUS Business Automation s.r.l.

Displasia ectodermica ipoidrotica legata al

LE INNOVAZIONI