In questo articolo mostreremo un semplice esempio di BPEL e lo svilupperemo con due prodotti, uno JBI e l‘altro SCA: Glassfish ESB e Oracle SOA suite. Tutto ciò allo scopo di comprendere similitudini e differenze.
Nello scorso articolo abbiamo introdotto i principali concetti JBI e SCA [MOKA-JBI-SCA_I]. In questo, mostreremo un semplice esempio di BPEL e lo svilupperemo con due prodotti, uno JBI e l’altro SCA; l’esempio in chiave JBI verrà fatto con Glassfish ESB (il nuovo nome di Open ESB di SUN, l’ESB open source di SUN che è JBI-compliant), mentre per la versione SCA useremo Oracle SOA suite, la suite Oracle per SOA basata su SCA.
L’esempio proposto
Sviluppiamo ora un semplice BPEL che “orchestra” un Web Service. L’esempio è volutamente semplice: ci serve unicamente per evidenziare le principali differenze tra le due tecnologie. È interessante notare che BPEL è un fattore in comune per entrambi gli ambiti tecnologici per l’orchestrazione dei servizi (per esempi più significativi di BPEL, al di fuori dagli obiettivi di questo articolo, si vedano [MOKA_SOA_X], [JBI4CICS], [MOKA_BPEL]).
Figura 1 – Scenario dell’esempio
Tale esempio verrà implementato sia con l’ESB open source di SUN (JBI-compliant) [OPENESB] che con l’ Oracle SOA suite (basata su SCA) [ORASOA].
Figura 2 – Scenario dell’esempio
Il Web Service dell’esempio
Lo scenario d’esempio prevede l’invocazione del seguente semplice Web Service Jax-Ws di nome GreetingsService presente nel progetto WebApp MokaWebServices.
@WebService
public class GreetingsService {
@WebMethod
public String sayHello(String param) throws Exception{
String result = "Hello [" + param + "]!";
return result;
}
Il Servizio Orchestrato
Il BPEL si occuperà di invocare il WebService GreetingsService e ritornare il risultato ottenuto concatenando al risultato il nome dell’ESB in cui è deployato.
I passi sono quindi:
- Receive: ricezione di una stringa da parte dell’utente
- Invoke: invocazione del WS GreetingsService passandogli come input la stringa ricevuta
- Reply: ritorna come risultato la stringa restituita dal WS anteponendo la stringa “Result OpenESB:” nel BPEL deployato su Open ESB, “Result Oracle” nel BPEL deployato su Oracle.
Implementazione Open ESB
L’esempio sviluppato con NetBeans è disponibile nello ZIP scaricabile come allegato dal menu in alto a sinistra.
Per provare l’esempio è possibile vedere il pocast a partire da qui.
Il BPEL finale che si ottiene è rappresentato nella seguente figura:
Figura 3 – il processo BPEL fatto con OpenESB
Eseguendo il test SOAP-UI, il risultato che si ottiene è il seguente:
Figura 4 – Esecuzione test SOAP-UI dell’esempio fatto con Open ESB
Artefatti JBI
Vediamo quale artefatti vengono generati per questo semplice esempio nella versione “JBI”.
La Composite Application (CA) è uno ZIP (MokaSoaCompositeApp.zip) che contiene al suo interno i JAR delle Service Unit (SU) che la compongono (vedere [MOKA_JBI]).
Nel nostro esempio le Service Unit sono due:
- sun-http-binding.jar: la Service Unit che utilizza il Binding Component http
- MokaBpelModule.jar: la Service Unit che contiene il BPEL dell’esempio
Nello ZIP della Composite Application (MokaSoaCompositeApp.zip) è presente il descrittore (jbi.xml) che elenca le SU che compongono la CA e i nomi degli endpoint provider e consumer.
... ="http://java.sun.com/xml/ns/jbi ./jbi.xsd"> MokaSoaCompositeApp ... MokaSoaCompositeApp-MokaBpelModule ... MokaBpelModule.jar sun-bpel-engine MokaSoaCompositeApp-sun-http-binding ... sun-http-binding.jar sun-http-binding ="GreetingsWsRole_partnerRole" service-name ="ns1:GreetingsWsPartnerLink"/> ="ns2:GreetingsService"/> ="GreetingsProcessPort" service-name ="ns3:GreetingsProcessService"/> ="GreetingsProcessPortTypeRole_myRole" service-name ="ns1:ProcessGreetingsPartnerLink"/> ...
A sua volta, ogni Service Unit ha al suo interno un descrittore (sempre di nome jbi.xml) che specifica se il componente JBI è un Service Engine () e indica il nome degli endpoint.
Il deploy prevede di copiare l’archivio relativo al componente che si vuole installare nella directory “install” (nel nostro esempio servono il bpelserviceengine.jar e l’httpbc.jar) mentre lo ZIP della Composite Application nella directory deploy.
Figura 5 – Artefatti JBI
Implementazione con Oracle SOA Suite 10g
Si realizzerà ora lo stesso esempio in chiave SCA utilizzando Oracle SOA suite 10 g.
Figura 6 – Scenario dell’esempio con Oracle SOA
Eseguendo il test con SOAP-UI il risultato che si ottiene è il seguente
Figura 7 – Esecuzione test SOAP-UI dell’esempio fatto con Oracle
Artefatti SCA
La Composite Application SCA viene definita mediante il seguente file descrittore composite.xml:
... revision="1.0" label="2008-05-09_11-20-50_854" mode="active" state="on" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:orawsp="http://schemas.oracle.com/ws/2006/01/policy" xmlns:ui="http://xmlns.oracle.com/soa/designer/"> location="MokaBPELProcess.wsdl" importType="wsdl"/> importType="wsdl"/> ="http://xmlns.oracle.com/oracle/MokaSOAComposite /MokaBPELProcess#wsdl.interface(MokaBPELProcess)"/> ="http://xmlns.oracle.com/oracle/MokaSOAComposite /MokaBPELProcess#wsdl.endpoint(client/MokaBPELProcess_pt)"/> location="GreetingsService.wsdl"/> client MokaBPELProcess/client MokaBPELProcess/GreetingsService GreetingsService
Figura 8 – Composite Application dell’esempio
Nel descrittore component.xml vengono elencati:
- il servizio esposto
- il componente che rappresenta l’implementazione del servizio
- i reference che sono le dipendenze da altri servizi
- i collegamenti (wire) tra i componenti presenti in un dominio SCA (area di funzionalità business).
A sua volta, ciascun componente e reference sono descritti da un file WSDL. Il deploy viene effettuato impacchettando i componenti che fanno parte di un dominio SCA. La composite rappresenta l’unità minima installabile e il formato per l’impacchettamento è il JAR. Non è detto che questa estensione venga conservata dopo il deploy; per esempio, i runtime basati su Java EE potrebbero convertire l’estensione .jar in quella .ear.
Anche se i componenti impacchettati devono appartenere a un dominio SCA, questo non rappresenta un vincolo nell’inclusione di possibili componenti appartenenti a domini SCA differenti. In tal caso, le connessioni (wire) tra componenti appartenenti a domini SCA differenti devono implementare dei meccanismi specifici di binding per indirizzare i servizi.
In generale, il JAR di cui effettuare il deploy conterrà il descrittore .xml e tanti file WSDL quanti saranno i servizi indicati come reference all’interno del component.xml; inoltre, è presente il WSDL del componente che espone il servizio all’esterno.
- Il JAR per l’esempio proposto contiene:
- il descrittore component.xml
- il file WSDL MokaBPELProcess.wsdl del componente SCA
- tanti file WSDL quanti sono i servizi indicati come reference. In questo caso sarà presente il file GreetingsService.wsdl.
Per ulteriori informazioni fare riferimento alle specifiche riportate dal modello di assembly SCA [SCA].
Figura 9 – Artefatti SCA
Conclusioni
In questo articolo abbiamo visto un semplice esempio pratico sviluppato con un prodotto JBI-compliant (OpenESB di SUN) e SCA-compliant (Oracle SOA ). Nel prossimo articolo si concluderà questa mini-serie dedicata a JBI & SCA facendo alcune considerazioni dal punto di vista architetturale, tecnologico e di “mercato”.
Riferimenti
[MOKA-JBI-SCA_I] M. Piraccini, S. Rossini, V.Caranna: “Java Business Integration e Service Component Architecture – I parte: Introduzione”, MokaByte 131, Luglio/Agosto 2008
[OPENESB] OpenESB v2 Stable
https://open-esb.dev.java.net
[ORASOA] Oracle SOA Suite Technology Preview
http://www.oracle.com/technology/products/ias/bpel/techpreview/index.html
[MOKA-JBI-SCA-SAMPLE-ZIP] Lo ZIP dell’esempio proposto è scaricabile come allegato dal menu in alto a sinistra.
[MOKA-JBI-SCA-PODCAST] https://www.mokabyte.it/2008/10/PodcastArticoloJBI-SCA.htm
[MOKA_SOA]
• [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
• [MOKA_SOA_X] M. Piraccini, S. Rossini, “SOA (X) Esempio (II)”, MokaByte 108, Luglio/Agosto 2006
• [MOKA_SOA_XI] M. Piraccini, S. Rossini, “SOA (XI): Riuso e granularità dei servizi SOA”, MokaByte 108, Luglio/Agosto 2006
[MOKA_JBI]
• [MOKA_JBI_I] S. Rossini, Java Business Integration(I), Mokabyte 100, Ottobre 2005
• [MOKA_JBI_II] S. Rossini, Java Business Integration(II), Mokabyte 101, Novembre 2005
• [MOKA_JBI_II] S. Rossini, Java Business Integration(III), Mokabyte 102, Dicembre 2005
[MOKA_EAISOA_CAP5] “Architetture di integrazione. Dall’Enterprise Integration a SOA”, Capitolo 5: “Java Business Integration”
https://www.mokabyte.it/cms/article.run?articleId=6TB-7TJ-J6N-2C5_7f000001_21141690_7578477f
[JBI4CICS] S. Rossini, A. Cannone,
• it: JBI4CICS: “Integrare CICS con il Binding Component Jbi4Cics”, Mokabyte 118, Maggio 2007
• en: Integrating CICS with Jbi4Cics Component
http://www.theserverside.com/tt/articles/article.tss?l=IntegratingCICSwithJBI)
[JBI4CORBA] M. Piraccini, M. Casoni, “Jbi4Corba: Integrare CORBA con il Binding Component Jbi4Corba”, Mokabyte 117, Aprile 2007
[MOKA_ESB] S. Rossini, “Enterprise Service Bus”, MokaByte 96, Maggio 2005
[MOKA_BPEL] L. Rinaldi, “Business Process Execution Language”, Mokabyte 127, Marzo 2008
[WP_COBIS] Comparison of business integration software:
http://en.wikipedia.org/wiki/Comparison_of_business_integration_software
[JBI_WP] http://en.wikipedia.org/wiki/Java_Business_Integration
[JBI] http://jcp.org/en/jsr/detail?id=208
[SCA] http://www.osoa.org/display/Main/Service+Component+Architecture+Specifications
[SCA_WP] http://en.wikipedia.org/wiki/Service_component_architecture
[DCISCA] D. Chappel, Introducing SCA
http://www.davidchappell.com/articles/Introducing_SCA.pdf
Marco Piraccini è nato a Cesena il 09/10/1975. E‘ laureato in Ingegneria Informatica presso la facoltà di Bologna con una tesi sull‘assessment della maturità del processo di testing e
in Fisica Computazionale presso la facoltà di Udine con una tesi sull‘uso di GRID per le simulazioni Monte Carlo (nell‘ambito di un esperimento di astrofisica).
Attualmente lavora come Software Architect per una società di consulenza. Il suo Blog è disponibile al seguente indirizzo: http://darkav.blogspot.com/
Vittoria Caranna è nata a Rimini nel 1982. Lauretasi in Ingegneria Informatica presso l‘Università degli studi di Bologna nel dicembre del 2007, da gennaio 2008 lavora per il Gruppo Imola.
Svolge attività di consulenza, in particolare per quanto riguarda le tematiche architetturali e di processo.
Stefano Rossini è nato a Giussano (MI) il 29/10/1970 e ha conseguito il diploma universitario in Ingegneria Informatica presso il Politecnico di Torino. Ha maturato più di venti anni di esperienza in diversi progetti Enterprise mission-critical ricoprendo i ruoli di IT Program Manager, Project Manager & Software Architect presso importanti gruppi bancari, pubblica sanità, pubblica amministrazione e software house.
Attualmente ricopre il ruolo di Sofware Factory Manager, Lean Change Agent ed Enterprise Architect presso Capgemini.
Esperto in ambito di sanità pubblica come Project/Program Manager per la governance dei progetti IT strategici di Cartella Clinica Elettronica (CCE) e Fascicolo Sanitario Elettronico (FSE).
Esperto in ambito bancario dove ha ricoperto per una decina d'anni il ruolo di Project Manager e Leader Software Architect (BPM, IWBank e BPS) occupandosi della pianificazione e gestione del progetto, del coordinamento del gruppo di sviluppo software sia InHouse che Nearshore/Offshore. Esperto nella conduzione di progetti secondo metodologia di Project Management PMBok e metodologia agile Scrum.
Si occupa di Java dal 1999 arrivando da precedenti esperienze in C e C++ in ambito Telco (Alcatel & Siemens). Ha pubblicato più di un centinaio di articoli su argomenti di IT Governance, Project Management, architetture enterprise e problematiche di Integrazione e SOA. È coautore dei libri "Manuale pratico di Java" (2001) e "La programmazione della piattaforma J2EE" (2005) editi da Hops/Tecniche Nuove. Certificazioni IT Governance: COBIT V.4.1 Foundation Certificate; certificazioni IT Service Management: ITIL V.3 Foundation Examination; certificazioni Project Management: CSM - Scrum Master, CSPO - Scrum Product Owner, PMI: 35 contact hours.
Profilo linkedin: http://www.linkedin.com/pub/stefano-rossini/30/977/242