Con questo articolo si conclude la serie dedicata a SOA: attraverso la seconda parte di un esempio pratico “ripassiamo” tutto quello che è stato illustrato nei numerosi articoli dedicati alla Service Oriented Architecture. Nel corso di circa un anno abbiamo parlato di SOA sia dal punto di vista architetturale che delle metodologie di analisi e di design, approfondendo i numerosi argomenti relativi a questo aspetto dell‘integrazione.

Introduzione

Nei precedenti articoli abbiamo parlato di SOA sia dal punto di vista architetturale [MOKA_SOA_I] che delle metodologie di analisi e di design [MOKA_SOA_II] .

Un‘azienda che decide di evolvere il proprio sistema informativo verso una architettura SOA deve fare diverse scelte e fronteggiare numerose sfide.

In [MOKA_SOA_III] e [MOKA_SOA_IV] abbiamo visto come sia indispensabile capire il livello di maturità  dell‘organizzazione e definire in base a questa una roadmap che definisca i passi aziendali (organizzativi, tecnici, metodologici e culturali) per definire un processo evolutivo ed incrementale con l‘obiettivo di una architettura SOA matura.

In [MOKA_SOA_V] abbiamo parlato di Service Oriented Integration (SOI): i principi Service Oriented applicati alle problematiche d‘integrazione.

In [MOKA_SOA_VII] si sono introdotte le caratteristiche principali di un Enterprise service BUS (ESB). I servizi SOA devono essere in grado di comunicare tra di loro attraverso un canale di comunicazione: il SOA bus. Da un punto di vista architetturale il SOA bus è un layer che deve mettere a disposizione uno strato di comunicazione tra i servizi: in [MOKA_SOA_VIII] si sono presentati alcuni ESB open-source.

In [MOKA_VIII] si sono introdotte alcune possibili strategie d‘adozione di SOA ed in particolare si è parlato dell‘importanza di un SOA Pilot.

In [MOKA_SOA_IX] abbiamo presentato uno scenario d‘esempio di analisi e design di un processo, utilizzando WSDL e BPEL.

In questo articolo, l‘ultimo della serie dedicata a SOA, concludiamo la presentazione dell‘esempio pratico con cui stiamo “ripassando” tutto quello che è stato presentato nei precedenti articoli.

Architettura implementata

Il caso d‘uso d‘esempio che avevamo preso in considerazione è quello della gestione di un ordine di acquisto che viene considerato valido se l‘acquirente presenta una email e una carta di credito validi.

L‘esempio proposto è stato sviluppato con SerivceMix 3.0 [SERVICEMIX].

ServiceMix è ad oggi l‘ ESB JBI-compliant open-source che, a nostro parere, è il più maturo tra quelli disponibili open-source.

Nel nostro esempio ci siamo attenuti alle specifiche JBI: dobbiamo quindi definire l‘applicazione come Composite Application. Coerentemente con JBI, i servizi saranno esposti al BUS in WSDL da Service Engine (SE) e accedibili dall‘esterno tramite Binding Component (BC) HTTP.

Lo scenario che verrà  implementato è il seguente:

• Un client (Java e C#) invoca il WSDL del BPEL accedendo al bus service mix mediante un JBI Binding Component SOAP

• L‘invocazione, arrivata al BC, viene inoltrata (routing) al SE BPEL che orchestra i seguenti servizi: il servizio di controllo della carta di credito (CheckCdC) e il servizio di controllo email (CheckMail)

• Il servizio, sulla base del risultati dei servizi invocati, restituisce la risposta al client

Configurazione ServiceMix e JBI

ServiceMix mette a disposizone una serie di componenti JBI già  pronti all‘uso, che devono essere installati per essere utilizzati. Questi componenti sono presenti nella directory “components” di ServiceMix, sotto forma di archivio (.zip). Per effettuare l‘installazione, è sufficente copiare l‘archivio relativo al componente che si vuole installare nella directory “install”.

Per fare funzionare il nostro esempio, installeremo i seguenti componenti:

• servicemix-jsr181: SE per i WS

• servicemix-bpe: SE per il processo BPEL

• servicemix-http: BC per l‘esposizione al di fuori del bus del processo BPEL

Le directory di installazione e deploy

Questi componenti serviranno per effettuare il deploy delle nostre Service Unit (SU), sia Binding Component (BC) che Service Engine (SE). L‘insieme delle SU assemblate in un Service Assembly produce la composite application che vogliamo costruire.
La composite application non è altro che un archivio contenente i .zip delle SU e il jbi.xml del SA. L‘archivio della SA va copiato nella directory “deploy” perchè ServiceMix poi proceda all‘installazione.

Quindi, coerentemente con le specifiche JBI, costruiremo una composite application formata da tre SU:

• SE JSR181 per la pubblicazione dei servizi CheckMail e CheckCdC sul BUS

• SE BPE per l‘orchestrazione dei servizi

• BC HTTP per l‘esposizione del servizio all‘esterno

Il Service Assembly descriptor (il file jbi.xml della SA) dell‘applicazione demo dell‘articolo prevede quindi:

MokaDemoSAMoka Demo service assembly

La definizione della Service Unit del SE JSR1818

jsr181sujsr181 service unitjsr181.zipservicemix-jsr181

La Service Unit del SE BPEL

bpesubpe service unitbpe.zipservicemix-bpe

La Service Unit del Binding Component HTTP

httpsuContains the binding of the bpe process on SOAP-HTTPhttp.zipservicemix-http

A questo punto occorre specificare il contenuto delle SU.

I Web Services

Le annotazioni sono una delle funzionalità  più recenti del linguaggio Java versione 5 e permettono di aggiungere marcatori al codice Java che indicano al container di seguire un determinato comportamento. Le annotazioni non sono codice, ma marcano il codice in modo che il container alteri il proprio comportamento di conseguenza. Questo meccanismo è stato utilizzato, fra le altre cose, per semplificare la definizione di oggetti e componenti, evitando la complessità  di complicate configurazioni tramite file XML.Per quanto riguarda i WS, sono state definite apositamente le specifiche JSR 181 [JSR181SPEC].

Di seguito si riporta un semplice esempio di annotazione per la definizione di un semplicissimo Web Service “Hello World”.

@WebServicepublic class HelloWorldService {@WebMethodpublic String helloWorld() {return "Hello World!";}}

Caricando questa classe in un container apposito, che ne riconosca il significato, si ottiene un servizio Web già  pronto, senza la necessità  di codificare parti di codice che supportino SOAP.

ServiceMix supporta lo standard JSR181 tramite il SE servicemix-jsr181. Noi comunque abbiamo utilizzato questo SE senza annotare la classe, dato che questo componente supporta la possibilità  di specificare l‘endpoint del servizio sulla configurazione della SU.

L‘immagine che segue riporta il semplice esempio di Web Service CheckEmailService costituito dalla classe Java CheckEmailService e dal file xbean.xml (per la configurazione della SU).

Il BPEL

L‘endpoint del processo per l‘accesso “esterno” è definito nel file xbean.xml di configurazione della SU HTTP:

La SU BPEL invece contiene i .wsdl del processo che stiamo definendo e il .bpel che esprime la logica del processo stesso.

La dichirarazione del servizio è:

All‘interno dello stesso file WSDL sono state inserite (ma non riportate nell‘articolo) anche le descrizioni WSDL dei servizi utulizzati (CheckEmailService e CheckCdCService).

Il BPEL corrispondente al servizio dichiara le variabili utilizzate:

Riceve il messaggio da elaborare:

Legge i valori che vengono utilizzati per chiamare i servizi

Esegue la chiamata ai servizi:

Decide se restituire true o false

    Restituisce la risposta

JMX Console

ServiceMix espone i servizi interni ed i componenti attraverso JMX come da specfica JBI. L‘MBeanServer del JBIContainer è raggiungibile mediante un JMXConnector che permette la connessione remota via protocollo RMI. Tramite JMX è quindi possibile ispezionare gli oggetti installati in ServiceMix.

String jndiPath = "jmxrmi";JMXServiceURL url = new JMXServiceURL ("service:jmx:rmi:///jndi/rmi://:/" + jndiPath) ;JMXConnector connector = JMXConnectorFactory.connect(url);

I parametri di default per la versione 3 di ServiceMix sono:

• namingPort:1099

• container name: jmxrmi

• JMX Service URL: service:jmx:rmi:///jndi/rmi://localhost:1099/jmxrmi

Con il JDK 1.5 si ha a disposizione il tool Console JMX che permette di monitorare applicazioni JMX-compliant.

Per mandarla in esecuzione per il monitoring ed il management di ServiceMix utilizzare il seguente comando:

%JAVA_HOME% injconsole service:jmx:rmi:///jndi/rmi://localhost:1099/jmxrmi

Una volta collegati è possibile visualizzare ed interagire con gli MBean selezionando la voce org.apache.servicemix.

Client

Avendo a disposizione l‘interfaccia di un servizio definita in WSDL, il modo più semplice per chiamare un WS è generare gli stub mediante opportuni tool di conversione da WSDL al linguaggio d‘interesse.

Ad esempio con Axis, partendo dal contratto WSDL, è possibile generare le classi da usare lato client utilizzando il tool WSDL2Java (java org.apache.axis.wsdl.WSDL2Java).
Il tool WSDL2Java è quindi utile poichè permette di semplificare notevolmente lo sviluppo di un client Java riducendo la quantità  di codice da scrivere e senza fare riferimento diretto alle API Axis o JAX-RPC.

Il codice del client Java che ci permette di invocare il nostro WebService diventa così semplice ed intuitivo ed è il seguente:

public class ProcessDemoTest {public static void main(String[] args) {try{TestProcess process = new TestProcessLocator();ProcessRequest correctRequest = new ProcessRequest();correctRequest.setCdC("123456");correctRequest.setEmail("email@email.it");ProcessResponse response = process.getTestProcessJBIPort().processExecution(correctRequest);System.out.println("Risultato:"+response.getResult());. . .

Con .NET è disponibile il programma analogo wsdl.exe che, dato il WSDL, genera la corrispondente classe Proxy C#.

Il codice client C# è di seguito riportato:

public class TestClient { public static void Main(string[] args) {new TestClient ().test(args[0], args[1];}public void test(string word1, String word2) {TestProcess service = new TestProcess();processRequest datoInput=new processRequest();datoInput.CdCId=word1;datoInput.email=word2;processResponse datoOutput = service.processExecution(datoInput);Console.WriteLine("Risultato:" + datoOutput.result);}

Mandando in esecuzione il client il processo ritorna false se la email o la carta di credito non sono valide e true nel caso in cui entrambi i dati siano corretti.

Nella nostra implementazione (semplificata) del processo, il Web Service CheckEmailService restituisce true nel caso in cui nella email sia presente la @ mentre il Web Service CheckCdCService restituisce true nel caso in cui il numero della Carta di Credito sia in formato numerico.

Lanciando quindi il processo con carta di credito “123456” ed email “aaa@bbb.it” il processo restituisce true. Nel caso in cui si invochi il servizio con email senza @ o con numero della carta di credito non numerica il processo restituisce false.

Conclusioni

Con questo articolo finisce questa lunga serie di articoli dedicati a SOA.
Il percorso che abbiamo affrontato è stato impegnativo e ha toccato alcuni degli aspetti per noi importanti, ma che (purtroppo) spesso non sono trattati con sufficiente chiarezza (anche per colpa di molti articoli “nebulosi” che si trovano in rete).
Abbiamo cercato di affrontare l‘argomento da molti punti di vista (architetturale, metodologico, organizzativo, tecnologico, pratico) in modo da offrire una visione il più possibile completa di questo tema complesso ma che è oggi è sempre più strategico nel mondo IT.

Riferimenti

[MOKA_SOA_I]
M. Piraccini – S. Rossini, “SOA: Introduzione”, MokaByte 100, Ottobre 2005

[MOKA_SOA_II]
M. Piraccini – S. Rossini, “SOA: Metodologia”, MokaByte 101, Novembre 2005

[MOKA_SOA_III]
M. Piraccini – S. Rossini, “SOA (III): Il Maturity Model”, MokaByte 102, Dicembre 2005

[MOKA_SOA_IV]
M. Piraccini – S. Rossini, “SOA (IV) Roadmap”, MokaByte 103, Gennaio 2006

[MOKA_SOA_V]
M. Piraccini – S. Rossini, “SOA (V) SOI”, MokaByte 104, Febbraio 2006

[MOKA_SOA_VI]
M. Piraccini – S. Rossini, “SOA (VI) ESB (I)”, MokaByte 105, Marzo 2006

[MOKA_SOA_VII]
M. Piraccini – S. Rossini, “SOA (VII) ESB (II)”, MokaByte 106, Aprile 2006

[MOKA_SOA_VIII]
M. Piraccini – S. Rossini, “SOA (VIII)”, MokaByte 107 ? Maggio 2006

[MOKA_SOA_IX]
M. Piraccini – S. Rossini, “SOA (IX) Esempio (I)”, MokaByte 108, Giugno 2006

[SERVICEMIX]
http://servicemix.org

[JSR208_SPEC]
R. Ten-Hove – P. Walker, Java Business Integration (JBI) 1.0 Final ReleaseMay 24, 2005
http://www.jcp.org/en/jsr/detail?id=208

[JBI_HOME]
http://java.sun.com/integration/

[JSR181SPEC]
JSR 181: Web Services Metadata for the Java Platform
http://www.jcp.org/en/jsr/detail?id=181

[WSBPEL]
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel