JMS e Web services nello sviluppo di architetture EDA e SOA. Jürgen Assfalg. 28 febbraio 2006

Transcript

1 JMS e WebServices nello sviluppo di architetture EDA e SOA 28 febbraio Contesto Temi Integrazione di applicazioni di scala enterprise caso di studio WS Applicazioni enterprise Architetture Evoluzione delle tecnologie SW EAI (Enterprise Applications Integration) SOA / EDA JMS 2

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 [ 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 percorso costi 4

3 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 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 6

4 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? 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,...) 8

5 Principali componenti SOAP ( definisce come avviene il trasporto dei messaggi Web Service Description Language - 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 9 Piattaforma Java Development Kit ( linguaggio Java, VM Tomcat 5.0.x ( application server Axis 1.2.x ( 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 10

6 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 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) 12

7 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...] 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(); } 14

8 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 ipotizzando che Tomcat sia in ascolto sulla porta della macchina da cui si accede, e che Axis sia installato nella cartella sopra indicata 15 Per consultare il file WSDL si può selezionare il collegamento ipertestuale riportato nella pagina sopra, oppure accedervi direttamente all'indirizzo 16

9 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 17 messaggi endpoint 18

10 19 Tutto sommato facile... ma... 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 quest'approccio non è sempre utilizzabile es. la classe deve appartenere al package predefinito manca il client per il servizio 20

11 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 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" -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) 22

12 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,...) 23 In generale, WSDL2Java può generare per ogni tipo: una classe Java ed eventuale holder per ogni porttype: un'interfaccia Java per ogni binding una classe stub una classe skeleton un modello (template) per l'implementazione per ogni service: un'interfaccia Java del servizio un'implementazione del servizio (locator) 24

13 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 26

14 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 ); return protocollo; } public String cerca( int numero ) throws java.rmi.remoteexception { return r.cerca( numero ); } static ProtocolloElementare r = new ProtocolloElementare(); } adattamento 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 28

15 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" [...] /> [...] 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 30

16 WSServizioService service = new WSServizioServiceLocator(); String endpointurl = " 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 ); } 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( " "numero"), XMLType.XSD_INT, ParameterMode.IN ); call.setoperationname( "cerca" ); call.setreturntype( XMLType.XSD_STRING ); 32

17 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> 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 il programma realizza un proxy TCP, che raccoglie tutto il traffico indirizzato alla porta locale 9080, lo registra, e quindi lo indirizza alla porta di localhost; analogamente per il traffico di ritorno è necessario cambiare l'indirizzo dell'endpoint fornito al client 34

18 Client richiesta risposta inolrata TCPMon richiesta inolrata risposta Server 35 Document - literal 36

19 ==== 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=" xmlns:xsd=" xmlns:xsi=" <soapenv:body> Corpo messaggio SOAP <in0 xmlns="urn:protocollo">prova 1</in0> </soapenv:body> </soapenv:envelope> 37 ==== Response ==== HTTP/ OK Server: Apache-Coyote/1.1 Content-Type: text/xml;charset=utf-8 Date: Mon, 27 Feb :42:38 GMT Connection: close <?xml version="1.0" encoding="utf-8"?> <soapenv:envelope xmlns:soapenv=" xmlns:xsd=" xmlns:xsi=" <soapenv:body> <registrareturn xmlns="urn:protocollo"> <anno>2006</anno> <numero>1</numero> </registrareturn> </soapenv:body> </soapenv:envelope> 38

20 RPC - encoded 39 ==== Request ==== [...] <ns1:registra soapenv:encodingstyle=" xmlns:ns1="urn:protocollo"> <in0 xsi:type="soapenc:string" xmlns:soapenc=" 1</in0> </ns1:registra> [...] 40

21 ==== Response ==== [...] <ns1:registraresponse soapenv:encodingstyle=" 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> [...] 41 Wrapped - literal 42

22 ==== Request ==== [...] <registra xmlns="urn:protocollo"> <in0>prova 1</in0> </registra> [...] <in0 xmlns="urn:protocollo">prova 1</in0> ==== Response ==== [...] <registraresponse xmlns="urn:protocollo"> <registrareturn> <anno>2006</anno> <numero>1</numero> </registrareturn> </registraresponse> [...] <registrareturn xmlns="urn:protocollo"> <anno>2006</anno> <numero>1</numero> </registrareturn> 43 Document-literal 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 supera limite di un solo parametro in document-literal, accorpando più parametri in uno solo RPC-encoded Obsoleto le altre combinazioni irrilevanti 44

23 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. 46

24 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(); 47 Client Service service = new Service(); call = (Call) service.createcall(); call.settargetendpointaddress( endpoint ); call.setoperationstyle( opstyle ); call.setoperationuse( opuse ); call.addparameter( new Qname( " "nome"), XMLType.XSD_STRING, ParameterMode.IN ); call.addparameter( new QName(" "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(); 48

25 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 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. 50

26 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 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à 52

27 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à interoperabilità secondo WS-I Basic Profile Applicazioni aziendali, o anche sistemi informativi, oppure ancora elaborazione dati [M.Fowler, PoEA] Grandi quantità di dati persistenti Accesso concorrente da parte di più utenti Numerose maschere per immissione dati Spesso sono integrate con altre applicazioni 54

28 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 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. 56

29 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 57 client/server, o a 2 livelli client: presentazione server: sorgente dati (DBMS) Database Server SQL Client Client GUI Business logic GUI Database logic Business logic Database logic 58

30 Vantaggi architettura semplice Svantaggi ridotta scalabilità richiede elevata larghezza di banda difficoltà di manutenzione 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 60

31 Client GUI Client GUI Middle-tier server Business logic Database logic Database Server RPC, DCOM, 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 62

32 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) 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 64

33 Protocolli e ed architetture client/server TCP/IP RPC Ambienti ad oggetti distribuiti da classi a componenti RMI DCOM CORBA EJB 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 66

34 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,...) 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 68

35 Integrazione di applicazioni (Enterprise Application Integration, o EAI) e sistemi distribuiti sono tematiche diverse, che tuttavia si possono incontrare 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 70

36 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 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 72

37 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 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 74

38 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 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 76

39 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) 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) 78

40 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 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. 80

41 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 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 82

42 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 84

43 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 85 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 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

44

45 89 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(); Topic publisher 90