Nel precedente articolo si è sviluppato un semplice Componente JBI di tipo Service Engine.
In questo articolo vedremo come verificarne il funzionamento costruendo una Composite Application di test. Questo ci permetterà di capire i meccanismi JBI standard di deploy dei cosiddetti Service Assembly.

Introduzione

Un componente JBI può essere usato all‘interno di un‘applicazione se e solo se è associato ad una Service Unit. Una o più Service Unit possono concorrere ad un Service Assembly, cioè ad una composizione di servizi.

Service Unit

Una Service Unit (SU) è un file archive (.zip) che contiene i file necessari per descrivere i servizi che un componente fornisce o utilizza.

Questo package non deve essere direttamente deployato ma serve per la costruzione di un “super-package”: il Service Assembly.

La definizione di una SU richiede la creazione di un file XML di nome servicelist.xml che deve indicare, mediante i tag , i servizi che il componente fornisce.
Ogni servizio deve essere identificato da un nome () e da un endpoint ().

Nel caso in cui il componente utilizzi a sua volta altri servizi, tali servizi devono essere indicati all‘interno del tag ().
Di seguito si riporta come esempio il service list dell‘applicazione Demo della SUN descritta in [1]. La Service Unit del componente SunSequencingEngine utilizza il BC SunFileBinding ed invoca i servizi del SunTransformationEngine (SE) e del SunSOAPBinding (BC).
Nel file servicelist.xml si dichiara quindi che viene esportato un servizio di nome PayrollService, con endpoint seqEndpoint che fornisce l‘operazione di nome inputxml:

http://www.payroll.org/payroll.wsdlPayrollService . . . seqEndpointThis is the simple service listhttp://www.payroll.org/payroll.wsdlinputxml

Inoltre si specifica che la SU utilizza l‘operazione di nome transform del servizio TimecardService

http://www.transformer.org/timecard.wsdlTimecardService. . . . . transformEndpointfirst_servicehttp://www.transformer.org/timecard.wsdltransformhttp://www.w3.org/2004/08/wsdl/in-out

e l‘operazione submit del servizio LAFPayrollService.

http://www.laf.org/lafpayroll.wsdlLAFPayrollServicehttp://www.laf.org/lafpayroll.wsdlLAFPayrollIF lafsoapendpoint. . . . . http://www.laf.org/lafpayroll.wsdlsubmithttp://www.w3.org/2004/08/wsdl/in-out

Oltre al file servicelist.xml bisogna associare alla SU un nuovo file jbi.xml che rappresenta il Service Unit descriptor.

A questo punto è possibile provvedere a creare un nuovo archivio .zip contenente i due documenti appena scritti ricordandosi di mettere il file jbi.xml in una sottodirectory META-INF.

Service Assembly

Un Service Assembly (SA) è costituito da un file archivio .zip che contiene:

• zero o piu‘ Service Unit

• un deployment descriptor (jbi.xml)

Un Service Assembly (SA) è un‘unità  standard di deploy che include, in un unico package, tutte le SU necessarie per comporre un‘applicazione (Composite Application).

Anche il Service Assembly necessita del suo deployment descriptor all‘interno del quale si devono indicare i partecipanti alla composizione dell‘applicazione.

Racchiuso tra i tag bisogna indicare i servizi che partecipano all‘”assemblaggio” indicando con il tag , per per ognuno di essi, il nome dello zip a quale componente è associato .

Un esempio di Composite Application

Vediamo di esemplificare quanto detto costruendo una semplice Composite Application.
Lo scopo di costruire il MokaServiceAssembly è duplice:

• verificare il funzionamento del componente MokaServiceEngine creato la scorsa volta (vedere [2]).

• creare una semplice Service Assembly costituito da due SU

La Composite Application rimane composta quindi dai due seguenti componenti:

• il MokaServiceEngine in grado di ricevere i messaggi e di stamparne il contenuto su file

• il Binding Component (BC) distribuito come sample nell‘SDK JBI (SunFileBindingComponent) in grado di ricevere i messaggi da una specifica directory

Il BC SunFileBindingComponet rimane in attesa di ricevere messaggi su una specifica directory definita in fase di deploy dell‘endpoint (es: c:mokabytemoka_jbiftp).

Una volta che si è copiato un file XML nella directory <ftp, il componente JBI SunFileBinding “preleva” il file (Figura 3(2)) e inserisce il suo contenuto come payload in un messaggio in forma “normale” e lo invia al MokaServiceEngine (Figura 3(3)).
Il SE, ricevuto il messaggio, scrive su file il suo contenuto (Figura 3(4)).

Bene, procediamo quindi a costruire le due SU ed il SA.

Iniziamo con la Service Unit del SunFileBindingComponent.

Modifichiamo il file endpoints.xml del SunFileBindingComponet indicando come directory di input su cui deve essere in “ascolto” il componente c:mokabytemoka_jbiftp mediante il tag (vedere [7]).

Proseguiamo costruendo la SU associata al Service Engine MokaComponent.
Per creare un Component Service Unit bisogna creare il file servicelist.xml che descrive i servizi esposti e/o usati dalla SU.
https://www.mokabyte.it/mokase.wsdlMokaService https://www.mokabyte.it/mokase.wsdlMokaServiceIF MokaEndpointThis is the simple service listhttp://www.payroll.org/payroll.wsdlinputxmlhttp://www.w3.org/2004/08/wsdl/in-only
Alla SU deve essere associato anche un descriptro di nome jbi.xml.

Inseriamo i due file XML in uno zip ad hoc (MokaSampleSU.zip) ricordandoci di mettere il file jbi.xml all‘interno di una directory META-INF.

Adesso arriva la parte finale: dobbiamo "assemblare" le due SU al fine di comporre la nostra applicazione.
Costruiamo quindi il Service Assembly.
Nel file descrittore del Service Assembly jbi.xml dobbiamo indicare le Service Unit () che concorrono al SA indicandone il nome () e il corrispettivo .zip nelle quali sono contenute () nonchà© il componente JBI a cui sono collegate ().
Nel descriptro si indica il nome del SA (MokaServiceAssembly)
 MokaServiceAssemblyMoka sample Service Assembly
e per ogni SU (MokaSampleSU e SunFileSU2) si specifica il nome del file archivio .zip ed il nome del componente a cui la SU fa riferimento.
Per la SU del componente sviluppato in [2] bisogna quindi indicare come file zip il file MokaSampleSU.zip e come nome del componente MokaSampleServiceEngine: 
MokaSampleSUService Engine Sub-Assembly for JBI DemoMokaSampleSU.zipMokaSampleServiceEngine

Mentre per la SU del componente SUN bisogna indicare il file SunFileSU2.zip ed esplicitare come nome del componente SunFileBinding: 
  SunFileSU2 Description of ServiceUnit: FileBindingSU   SunFileSU2.zip SunFileBinding  

Lo schema finale del SA è rappresentato nella figura che segue.

Passiamo ad effettuarne il deploy del SA sull‘Application Server SUN.
Utilizzando il jbiadmin, il command line tool del JBI SDK, è possibile effettuare il deploy del SA con il comando deploy-service-assembly e avviarlo mediante il comando start-service-assembly
deploy-service-assembly <
Per verificare che il SA sia partito correttamente è possibile vedere la lista dei SA installati mediante il comando list-service-assemblies:
>list-service-assemblies================================List of Service Assemblies================================Name : MokaServiceAssemblyState: Started--------------------------------. . . . .--------------------------------
Proviamo ora a verificare che la nostra semplice Composite Application funzioni correttamente.
Copiamo un file xml nella directory <ftp e controlliamo che il file venga inoltrato al Moka SE guardando i log dell‘Application Server e appurando che sia stato creato il file nella <logmokalog_DD-MM-YYYY_HH-MM-SS.log con il contenuto del file XML.

Conclusioni
Con questo articolo si chiude la miniserie di articoli dedicati a JBI.
Ho cercato di dare un‘idea la più possibile completa di cosa sia JBI sia da un punto di vista architetturale (vedere [1]) che da un punto di vista pratico ([2] e questo numero).
JBI è uno standard interessante e promettente. Non rimane che attendere e vedere quale sarà  il peso che assumerà  negli anni a venire che, come per ogni proposta di standard, è soprattutto dettato dal supporto e dalla fiducia che i principali player del mercato decideranno di accordare alla specifica SUN.
1S. Rossini"Java Business Integration (I)" Mokabyte 100 Ottobre 20052S. Rossini "Java Business Integration (II)" Mokabyte 101 Novembre 20053R. Ten-Hove, P. Walker "Java Business Integration (JBI) 1.0 Final Release"http://www.jcp.org/en/jsr/detail?id=2084http://java.sun.com/integration/5Sun White Paper: "Developing a Service Engine Component" http://java.sun.com/integration/reference/techart/6http://java.sun.com/integration/download/7http://java.sun.com/integration/1.0/docs/sdk/




 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