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 <list-attributes>, i servizi che il componente fornisce.
Ogni servizio deve essere identificato da un nome (<local-part>) e da un endpoint (<endpoint-name>).
Nel caso in cui il componente utilizzi a sua volta altri servizi, tali servizi devono essere indicati all’interno del tag (<service>).
Di seguito si riporta come esempio il service list dell’applicazione Demo della SUN descritta in [MOKA_JBI_I]. 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:

<list-attributes>
<list-service>
<namespace-uri>http://www.payroll.org/payroll.wsdl</namespace-uri>
<local-part>PayrollService</local-part>
</list-service>
. . . . .
<endpoint-name>seqEndpoint</endpoint-name>
<list-description>This is the simple service list</list-description>
<list-operation>
<namespace-uri>http://www.payroll.org/payroll.wsdl</namespace-uri>
<local-part>inputxml</local-part>
</list-operation>
</list-attributes>

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

<service>
<service-name>
<namespace-uri>http://www.transformer.org/timecard.wsdl</namespace-uri>
<local-part>TimecardService</local-part>
</service-name>
<interface-name>
. . . . .
</interface-name>
<endpoint-name>transformEndpoint</endpoint-name>
<service-id>first_service</service-id>
<operation>
<namespace-uri>http://www.transformer.org/timecard.wsdl</namespace-uri>
<local-part>transform</local-part>
</operation>
<mep>http://www.w3.org/2004/08/wsdl/in-out</mep>
</service>

e l’operazione submit del servizio LAFPayrollService.

<service>
<service-name>
<namespace-uri>http://www.laf.org/lafpayroll.wsdl</namespace-uri>
<local-part>LAFPayrollService</local-part>
</service-name>
<interface-name>
<namespace-uri>http://www.laf.org/lafpayroll.wsdl</namespace-uri>
<local-part>LAFPayrollIF</local-part>
</interface-name>
<endpoint-name>lafsoapendpoint</endpoint-name>
. . . . .
<operation>
<namespace-uri>http://www.laf.org/lafpayroll.wsdl</namespace-uri>
<local-part>submit</local-part>
</operation>
<mep>http://www.w3.org/2004/08/wsdl/in-out</mep>
</service>

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.

Figura 1: Struttura di una Service Unit

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

Figura 2: il Service Assembly

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 <service-assembly> bisogna indicare i servizi che partecipano all’ “assemblaggio” indicando con il tag <service-unit>, per per ognuno di essi, il nome dello zip <artifacts-zip> a quale componente è associato <component-name>.

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 [MOKA_JBI_II]).
  
• 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:\mokabyte\moka_jbi\ftp).
Una volta che si è copiato un file XML nella directory <<MOKA_JBI>>\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)).

Figura 3: la Composite Application d’esempio

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:\mokabyte\moka_jbi\ftp mediante il tag <input-dir> (vedere [JBI_SDK1.0_DOC]).

<?xml version="1.0"?>
<endpoint-list xmlns=". . . . . >
<endpoint>
<service>
<namespace-uri>http://www.mokabyte.it/mokase.wsdl</namespace-uri>
<local-part>MokaService</local-part>
</service>
<interface>
<namespace-uri>http://www.mokabyte.it/mokase.wsdl</namespace-uri>
<local-part>MokaServiceIF</local-part>
</interface>
<endpoint-name>ftpEndpoint</endpoint-name>
<endpoint-role>consumer</endpoint-role>
<input-dir>c:\mokabyte\moka_jbi\ftp</input-dir>
. . . . .
<operation>
<name>
<namespace-uri>http://www.mokabyte.it/mokase.wsdl</namespace-uri>
<local-part>inputxml</local-part>
</name>
. . . . .
</operation>
</endpoint>
</endpoint-list>

Inseriamo il file XML in un apposito archivio di nome SunFileSU2.zip.

Figura 4: SunFileSU2.zip

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.

<?xml version="1.0"?>
<service-list xmlns=". . . . ." >
<list-attributes>
<list-service>
<namespace-uri>http://www.mokabyte.it/mokase.wsdl</namespace-uri>
<local-part>MokaService</local-part>
</list-service>
<list-interface>
<namespace-uri>http://www.mokabyte.it/mokase.wsdl</namespace-uri>
<local-part>MokaServiceIF</local-part>
</list-interface>
<endpoint-name>MokaEndpoint</endpoint-name>
<list-description>This is the simple service list</list-description>
<list-operation>
<namespace-uri>http://www.payroll.org/payroll.wsdl</namespace-uri>
<local-part>inputxml</local-part>
</list-operation>
<list-mep>http://www.w3.org/2004/08/wsdl/in-only</list-mep>
</list-attributes>
</service-list>

Alla SU deve essere associato anche un descriptro di nome jbi.xml.

<?xml version='1.0' ?>
<jbi version="1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://java.sun.com/xml/ns/jbi"
xmlns:mokaroll="http://www.mokabyte.it/mokase.wsdl"
xsi:schemaLocation="http://java.sun.com/xml/ns/jbi jbi.xsd">
<services binding-component="">
<provides service-name="mokaroll:MokaService"
interface-name="mokaroll:MokaServiceIF"
endpoint-name="Moka_Endpoint">
</provides>
</services>
</jbi>

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.

Figura 5: MokaSampleSU.zip

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 (<service-unit>) che concorrono al SA indicandone il nome (<name>) e il corrispettivo .zip nelle quali sono contenute (<artifacts-zip>) nonché il componente JBI a cui sono collegate (<component-name>). Nel descriptro si indica il nome del SA (MokaServiceAssembly)

<service-assembly>
<identification>
<name>MokaServiceAssembly</name>
<description>Moka sample Service Assembly</description>
</identification>

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 [MOKA_JBI_II] bisogna quindi indicare come file zip il file MokaSampleSU.zip e come nome del componente MokaSampleServiceEngine:

<service-unit>
<identification>
<name>MokaSampleSU</name>
<description>Service Engine Sub-Assembly for JBI Demo</description>
</identification>
<target>
<artifacts-zip>MokaSampleSU.zip</artifacts-zip>
<component-name>MokaSampleServiceEngine</component-name>
</target>
</service-unit>

Figura 6: Tag <service-unit> del jbi.xml del SA

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

<service-unit>
<identification>
<name>SunFileSU2</name>
<description>Description of ServiceUnit: FileBindingSU</description>
</identification>
<target>
<artifacts-zip>SunFileSU2.zip</artifacts-zip>
<component-name>SunFileBinding</component-name>
</target>
</service-unit>
</service-assembly>
</jbi>

Figura 7: MokaServiceAssembly.zip

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

Figura 8: Composizione del MokaServiceAssembly

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 <<MOKA_JBI>>\install_deploy\sa\MokaServiceAssembly.zip
start-service-assembly MokaServiceAssembly

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 : MokaServiceAssembly
State: Started
--------------------------------
. . . . .
--------------------------------

Proviamo ora a verificare che la nostra semplice Composite Application funzioni correttamente.

Copiamo un file xml nella directory <<MOKA_JBI>>\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 <<MOKA_JBI>>\log\mokalog_DD-MM-YYYY_HH-MM-SS.log con il contenuto del file XML.

Figura 9: Lo scenario dell’esempio proposto

Conclusioni
Con questo articolo si chiude la mini-serie 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 [MOKA_JBI_I]) che da un punto di vista pratico ([MOKA_JBI_II] 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.

Bibliografia e riferimenti
[MOKA_JBI_I] S. Rossini: Java Business Integration(I), Mokabyte N. 100 – Ottobre 2005
[MOKA_JBI_II] S. Rossini: Java Business Integration(I), Mokabyte N. 101 – Novembre 2005
[JSR208_SPEC]: R. Ten-Hove, P. Walker: Java Business Integration (JBI) 1.0 Final Release
http://www.jcp.org/en/jsr/detail?id=208
[JBI_HOME] http://java.sun.com/integration/
[WP_DEVSE] Sun White Paper: Developing a Service Engine Component-
http://java.sun.com/integration/reference/techart/
[JBI_SDK1.0] http://java.sun.com/integration/download/
[JBI_SDK1.0_DOC] http://java.sun.com/integration/1.0/docs/sdk/
[JBI_JAVADOC] http://java.sun.com/integration/1.0/docs/sdk/api/index.html