Mokabyte

Dal 1996, architetture, metodologie, sviluppo software

  • Argomenti
    • Programmazione & Linguaggi
      • Java
      • DataBase & elaborazione dei dati
      • Frameworks & Tools
      • Processi di sviluppo
    • Architetture dei sistemi
      • Sicurezza informatica
      • DevOps
    • Project Management
      • Organizzazione aziendale
      • HR
      • Soft skills
    • Lean/Agile
      • Scrum
      • Teoria della complessità
      • Apprendimento & Serious Gaming
    • Internet & Digital
      • Cultura & Società
      • Conferenze & Reportage
      • Marketing & eCommerce
    • Hardware & Tecnologia
      • Intelligenza artificiale
      • UX design & Grafica
  • Ultimo numero
  • Archivio
    • Archivio dal 2006 ad oggi
    • Il primo sito web – 1996-2005
  • Chi siamo
  • Ventennale
  • Libri
  • Contatti
Menu
  • Argomenti
    • Programmazione & Linguaggi
      • Java
      • DataBase & elaborazione dei dati
      • Frameworks & Tools
      • Processi di sviluppo
    • Architetture dei sistemi
      • Sicurezza informatica
      • DevOps
    • Project Management
      • Organizzazione aziendale
      • HR
      • Soft skills
    • Lean/Agile
      • Scrum
      • Teoria della complessità
      • Apprendimento & Serious Gaming
    • Internet & Digital
      • Cultura & Società
      • Conferenze & Reportage
      • Marketing & eCommerce
    • Hardware & Tecnologia
      • Intelligenza artificiale
      • UX design & Grafica
  • Ultimo numero
  • Archivio
    • Archivio dal 2006 ad oggi
    • Il primo sito web – 1996-2005
  • Chi siamo
  • Ventennale
  • Libri
  • Contatti
Cerca
Chiudi

Nel numero:

133 ottobre
, anno 2008

Java Business Integration e Service Component Architecture

II parte: Esempio pratico

Marco Piraccini, Vittoria Caranna e Stefano Rossini

Marco Piraccini

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/

Marco Piraccini, Vittoria Caranna e Stefano Rossini

Vittoria Caranna

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.

Marco Piraccini, Vittoria Caranna e Stefano Rossini

Stefano Rossini

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

MokaByte

Java Business Integration e Service Component Architecture

II parte: Esempio pratico

Marco Piraccini, Vittoria Caranna e Stefano Rossini

Marco Piraccini, Vittoria Caranna e Stefano Rossini

  • Questo articolo parla di: Architetture dei sistemi, Java

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

 

 

 

 

Facebook
Twitter
LinkedIn
Marco Piraccini, Vittoria Caranna e Stefano Rossini

Marco Piraccini

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/

Marco Piraccini, Vittoria Caranna e Stefano Rossini

Vittoria Caranna

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.

Marco Piraccini, Vittoria Caranna e Stefano Rossini

Stefano Rossini

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

Marco Piraccini, Vittoria Caranna e Stefano Rossini

Marco Piraccini, Vittoria Caranna e Stefano Rossini

Tutti gli articoli
Nello stesso numero
Loading...

Il programmatore e le sue api

VII parte: Ancora sull‘uso dei pattern nella architettura

Web Service, Enterprise Integration Patterns e Web Application con FUSE

II parte: Implementazione del service mediator

Wicket: Java framework per applicazioni web

III parte: I principali componenti extension

Il programmatore e le sue API

VIII parte: Il design della persistenza con Hibernate

Algoritmi genetici

IV parte: Fase di preparazione

Nella stessa serie
Loading...

Java Business Integration e Service Component Architecture

III parte: Considerazioni

Java Business Integration e Service Component Architecture

I parte: Introduzione

Mokabyte

MokaByte è una rivista online nata nel 1996, dedicata alla comunità degli sviluppatori java.
La rivista tratta di vari argomenti, tra cui architetture enterprise e integrazione, metodologie di sviluppo lean/agile e aspetti sociali e culturali del web.

Imola Informatica

MokaByte è un marchio registrato da:
Imola Informatica S.P.A.
Via Selice 66/a 40026 Imola (BO)
C.F. e Iscriz. Registro imprese BO 03351570373
P.I. 00614381200
Cap. Soc. euro 100.000,00 i.v.

Privacy | Cookie Policy

Contatti

Contattaci tramite la nostra pagina contatti, oppure scrivendo a redazione@mokabyte.it

Seguici sui social

Facebook Linkedin Rss
Imola Informatica
Mokabyte