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]).

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.

 

Implementazione con Oracle SOA Suite 10g

Si realizzerà ora lo stesso esempio in chiave SCA utilizzando Oracle SOA suite 10 g.

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].

 

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