Xml2Soa Volume1 v1-1p -...

TBS IT Telematic&Biomedical Services S.r.l. con socio unico

Sede legale: Via Gallina, 4 - 34122 Trieste – Tel. 06 51941001 – Fax 0651941120 Sede amministrativa: Via F. Bettini, 13 - 06034 Foligno (PG) – Tel. 0742 32661- Fax 0742 326632

[email protected] - www.tbsit.com Capitale Sociale € 9.000.000,00 interamente versato

C.F., P.IVA, Reg. Impr. Trieste 01165260322 - REA TS129517 Sedi e ufficia: Roma, Bari, Capodrise (CE), Firenze, Assago (MI), Potenza, Ivrea (TO), Venezia

Materia le p roprietar io d i TBS IT Te lemat ic & Biomedica l Serv ices S.r . l . tu te lato a i sensi de l la normativa v igente in tema di d ir i tto d ’auto re e banche dat i ( legge n.633/1941 e successiv i aggio rnamenti) . Le informazion i contenute ne l la presente offerta sono da considerars i s tre ttamente r iservate e non possono essere r iprodot te o d ivulga te a te rz i o usate per uno scopo diverso da quel lo d i va lutare le stesse a l f ine d i add ivenire a lla s t ipu la d i un accordo, senza i l prevent ivo consenso scri t to d i TBS IT Te lemat ic & B iomedica l Serv ices S.r . l .

«XML2SOA» v. 1.0

Presentazione

Versione: 1.1p

Data versione: 24/02/2012

Data emissione: 11/04/2013

CONTATTI

Luca Blasi [email protected]

TBS IT Telematic & Biomedical Services S.r.l. - Sede legale: Via Gallina, 4 - 34122 Trieste

«XML2SOA» V. 1 .0 – Presentazione [v . 1.1p del 24/02/2012] Pagina 2 d i 28

1. Indici



1.1 Sommario

1. INDICI...............................................................................2

1.1 Sommario ..................................................................................................... 3

1.2 Indice delle Figure ........................................................................................ 4

2. INTRODUZIONE .................................................................5

2.1 Glossario....................................................................................................... 6

2.1.1 Glossario dei termini relativi al componente XML2SOA ............................................. 6

2.2 Presentazione ............................................................................................... 7

2.2.1 Inquadramento generale .......................................................................................... 7 2.2.2 Valore aggiunto della soluzione. ............................................................................... 9

3. ARCHITETTURA GENERALE ...............................................10

3.1 Tipologie di colloquio implementate da XML2SOA....................................... 11

3.1.1 Colloquio sincrono .................................................................................................. 12 3.1.2 Colloquio asincrono................................................................................................. 13

3.1.2.1 Scenario della chiamata iniziale.........................................................................................13 3.1.2.2 Scenario delle chiamate intermedia e finale ........................................................................14 3.1.2.3 Considerazioni sul colloquio asincrono................................................................................15

3.2 Architettura e logica di funzionamento di XML2SOA ................................... 16

3.2.1 Componenti............................................................................................................. 16 3.2.2 Comunicazione tra componenti ............................................................................... 17 3.2.3 Componenti e macrologica del loro funzionamento................................................. 18

3.2.3.1 Componenti XML2SOA.....................................................................................................18 XML2SOA_PORTA0 .........................................................................................................18 XML2SOA_SENDER .........................................................................................................18 XML2SOA_ENQ ..............................................................................................................18 XML2SOA_DEQ ..............................................................................................................18

3.2.3.2 Transazione di tipo “XML2SOA_PROMOTER”........................................................................18 Considerazioni sulle scelte implementative .........................................................................20

3.2.4 Introduzione alla profilazione delle Operazioni....................................................... 22 3.2.4.1 Entità di base per la costruzione dei Profili ..........................................................................22 3.2.4.2 Relazioni di base per la costruzione dei Profili......................................................................23 3.2.4.3 Riepilogo delle caratteristiche di base per la costruzione dei Profili ..........................................24

3.2.5 Scalabilità ............................................................................................................... 26



1.2 Indice delle Figure

Figura 1 – Glossario dei termini relativi al componente XML2SOA ............................................................. 6 Figura 2 – «Communication Diagram» generale..................................................................................... 8 Figura 3 – «Sequence Diagram» generale in caso di colloquio sincrono .................................................... 12 Figura 4 – «Sequence Diagram» generale in caso di colloquio asincrono (parte 1) ..................................... 13 Figura 5 – «Sequence Diagram» generale in caso di colloquio asincrono (parte 2) ..................................... 14 Figura 6 – «Component Diagram» di XML2SOA.................................................................................... 16 Figura 7 – «Communication Diagram» di XML2SOA. ............................................................................. 17 Figura 8 – Principali Entità che compongono il Profilo dell’Operazione in ambito XML2SOA........................... 22 Figura 9 – Principali Relazioni che compongono il Profilo dell’Operazione in ambito XML2SOA. ..................... 23 Figura 10 – «Entity-Relationship Diagram» inerente al Profilo dell’Operazione in ambito XML2SOA. .............. 24 Figura 11 – Esempio di deployment multi-istanza di XML2SOA in presenza di dispositivo di load balancing..... 27 Figura 12 – Esempio di deployment multi-istanza di XML2SOA con assegnazione statica applicazione-istanza. 27 Figura 13 – Esempio di deployment multi-istanza di XML2SOA con assegnazione statica operazione-istanza. . 28



2. Introduzione



2.1 Glossario

Nell’ambito della presente Documentazione, i seguenti termini assumono il significato di seguito indicato.

2.1.1 Glossario dei termini relativi al componente XML2SOA

Figura 1 – Glossario dei termini relativi al componente XML2SOA

XML2SOA Il componente software oggetto di questo Documento, preposto all’inoltro di Richieste provenienti da Richiedenti verso un SistemaRemoto e delle conseguenti Risposte al Richiedente e agli eventuali DestinatariRisposta.

Richiedente Sistema Informativo che genera la Richiesta e riceve (in modalità sollecitata) la RispostaARichiedente.

Richiesta Messaggio generato da un Richiedente, inerente all’innesco presso un SistemaRemoto di processamenti finalizzati al rilascio di informazioni (Risposta).

Nello specifico, la versione del Messaggio in un formato valido condiviso tra Richiedente e XML2SOA.

SistemaRemoto Il Sistema Informativo destinatario della Richiesta di un Richiedente in quanto preposto a soddisfarla, in altre parole il c.d. DestinatarioRichiesta.

RichiestaARemoto La versione (trasformazione) del messaggio di Richiesta in un formato valido condiviso tra XML2SOA e il DestinatarioRichiesta.

DestinatarioRichiesta Sistema Informativo c.d. Remoto (vedi), che rappresenta il destinatario della Richiesta generata dal Richiedente.

Risposta Messaggio contenente le informazioni prodotte da un SistemaRemoto (o DestinatarioRichiesta) a seguito di una Richiesta.

Nello specifico, la versione del Messaggio in un formato valido condiviso tra il DestinatarioRichiesta e XML2SOA.

RispostaARichiedente La versione (trasformazione) del messaggio di Risposta pervenuto dal SistemaRemoto (ovvero un sottoinsieme di informazioni derivate da esso) in un formato valido condiviso tra XML2SOA e il Richiedente.

DestinatarioRisposta Sistema Informativo che riceve la RispostaADestinatario in modalità non sollecitata.

RispostaADestinatario La versione (trasformazione) del messaggio di Risposta pervenuto dal SistemaRemoto (ovvero un sottoinsieme di informazioni derivate da esso) in un formato valido condiviso tra XML2SOA e l’N-esimo DestinatarioRisposta.

ACKRisposta Messaggio d’esito rilasciato dal DestinatarioRisposta a XML2SOA a seguito della ricezione di una RispostaADestinatario.

Operazione Esecuzione della chiamata di un Richiedente a XML2SOA, tramite la quale viene innescata una Richiesta di tipo X, tipo sulla base del quale ne viene determinato dinamicamente il Profilo.

Profilo Insieme degli attributi associati ad un’Operazione sulla base dei quali viene determinata dinamicamente la natura di tutti gli elementi coinvolti nell’esecuzione dell’Operazione stessa (Richiesta, SistemaRemoto, Risposta, DestinatariRisposta, ecc.).

Transazione (o Transazione logica)

Un ciclo di elaborazione di informazioni basato su 1 singola Operazione di XML2SOA o su molteplici Operazioni di XML2SOA concatenate tra loro in sequenza.



2.2 Presentazione

2.2.1 Inquadramento generale

Il presente documento contiene la descrizione della soluzione tecnica inerente allo sviluppo di un componente software, denominato “XML2SOA”, atto a definire un’interfaccia unica standard tramite la quale Sistemi Informativi Locali abilitati possano accedere ai servizi pubblicati da SistemiRemoti in modalità trasparente.

XML2SOA si frappone tra i S.I. Locali e il SistemaRemoto allo scopo di ottenere i seguenti vantaggi:

� amplificazione e semplificazione della sicurezza, concentrando tali aspetti relativi al colloquio con il SistemaRemoto in un unico punto (i S.I. Locali sanno come chiamare XML2SOA, ma non sanno come chiamare il SistemaRemoto);

� semplificazione delle modalità di fruizione dei servizi esposti dal SistemaRemoto, esponendo XML2SOA ai S.I. Locali servizi più lineari che mascherano la complessità del colloquio con il SistemaRemoto.

Il componente in oggetto assume la denominazione di “XML2SOA”, che mette in risalto il meccanismo per cui Richieste generate a livello locale in formato XML vengono inoltrate al competente DestinatarioRichiesta tramite logiche di chiamata basate su Server/Client SOA che interagiscono tra loro scambiando messaggi veicolati in protocollo SOAP con binding in stile di tipo “documento”.

In effetti, come di seguito descritto, detto componente viene ingegnerizzato come un concentratore che agendo in veste di "router/dispatcher1 SOAP" è in grado di fare da ponte tra SistemiRemoti e S.I. Locali.

XML2SOA viene implementato come un componente altamente generalizzato, basato su automatismi fondati sul binding dinamico delle profilazioni delle proprie funzionalità di interfacciamento di SistemiRemoti.

Di conseguenza XML2SOA consente ai S.I. Locali l’integrazione in modalità semplificata della fruizione di una molteplice gamma di servizi remoti, il cui unico prerequisito consisterà nel presentarsi in modo coerente con il modello di sequenze logiche di colloquio implementato:

� i S.I. Locali sono chiamati a interagire con XML2SOA in una unica modalità standard predefinita, senza integrare logiche differenti espresse da SistemiRemoti differenti;

� XML2SOA, per mezzo di opportune profilazioni (quindi senza la necessità di ulteriori interventi di sviluppo del software), valida e traduce le Richieste dei S.I. Locali verso i SistemiRemoti e ne valida e restituisce le Risposte traducendole per i S.I. Locali sollevandoli dalla conoscenza applicativa specifica intrinseca a ogni SistemaRemoto.

In sintesi, il know-how delle attività eseguite da XML2SOA è per la quasi totalità demandato alla profilazione dinamica delle Operazioni.

1 In particolare: routing della Richiesta e dispatching della Risposta.



In particolare i componenti software (Java) di XML2SOA sono strutturati staticamente per effettuare la seguente sequenza di step logici (funzionalità), secondo quanto successivamente esposto nella Figura 2:

1. Ricevere 1 Richiesta [messaggio 1] dall’N-esimo Richiedente 2. Validare/Trasformare la Richiesta in 12 RichiestaARemoto 3. Inoltrare la RichiestaARemoto [messaggio 1.1] al DestinatarioRichiesta2 4. Ricevere 1 Risposta [messaggio 2] dal DestinatarioRichiesta 5. Validare/Trasformare la Risposta in 1 RispostaARichiedente 6. Validare/Trasformare la Risposta in 0..N RispostaADestinatario 7. Inoltrare la RispostaARichiedente [messaggio 2.1] al Richiedente 8. Inoltrare la RispostaADestinatario [messaggio 2.2] a 0..N DestinatarioRisposta 9. Ricevere 0..N ACKRisposta [messaggio 3] dagli 0..N DestinatarioRisposta coinvolti 10. Tracciare l’intero ciclo di vita del flusso delle attività sopra citate a fini di monitoraggio

In altre parole XML2SOA è ingegnerizzato per effettuare scambi di messaggi tra componenti SOAP che di volta in volta si presentano come Client o Server.

Il meccanismo di scambio dei messaggi, è evidenziato nel Diagramma di Figura 2.

Figura 2 – «Communication Diagram» generale

Posto che XML2SOA è strutturato staticamente per gestire la citata sequenza di step, è opportuno sottolineare che il contenuto informativo di questi step è invece di per sé ignoto ai componenti Java di XML2SOA, essendo determinato dinamicamente sulla base degli attributi associati all’Operazione corrente (come è strutturata la Richiesta, come validarla, come trasformarla in RichiestaARemoto, dove inoltrare la RichiestaARemoto, ecc.) nell’ambito di un Profilo esterno ai componenti Java di cui sopra.

E’ dunque il Profilo dell’Operazione, e non i componenti Java di XML2SOA, a determinare le effettive modalità di espletamento dell’esecuzione dell’Operazione stessa. E a tale proposito, per consentire una migliore comprensione di questo concetto, si può anticipare che:

2 Specifica tecnico-funzionale dell’attuale versione 1.0: la Richiesta è inoltrata a 1 e 1 solo

DestinatarioRichiesta.



� È a livello di Profilo, che vengono definiti gli indirizzi delle chiamate al DestinatarioRichiesta e agli eventuali DestinatariRisposta; chiamate quindi in tal modo determinate dinamicamente dai componenti Java e chiamate passibili dunque di variazioni nel tempo in maniera del tutto trasparente a detti componenti.

� Il Profilo include componenti XSD e XSLT, preposti alle funzioni di validazione e trasformazione sopra citate (step 2, 5, 6), che sono a tutti gli effetti i proprietari del know-how del contenuto informativo delle Operazioni, in una modalità del tutto disaccoppiata dai componenti Java preposti ad innescarne l’esecuzione.

� Il Profilo è ospitato da un DB a ciò dedicato e può quindi essere manutenuto ed evoluto a prescindere dai componenti Java di XML2SOA.

2.2.2 Valore aggiunto della soluzione.

� Posto quindi questo quadro, appare evidente a cosa ci si riferisce affermando il valore aggiunto proveniente dall’alto grado di dinamicità di XML2SOA nell’”apertura” della fruizione di molteplici servizi remoti: XML2SOA costituisce un motore “vuoto”, che è possibile utilizzare rapidamente per implementare (tramite le sue Operazioni) la gestione del colloquio tra un Richiedente e un DestinatarioRichiesta (con l’eventuale ulteriore concorso di DestinatariRisposta diversi dal Richiedente), concentrando il know-how del colloquio negli ambiti XSD/XSLT associati al Profilo di dette Operazioni.

In altre parole, ferma restando la necessità di sviluppare (a livello dei S.I.Locali fruitori) componenti software che nel ruolo di Richiedente siano atti ad innescare la chiamata verso XML2SOA, nonché gli opportuni XSD/XSLT, l’implementazione di nuove funzionalità di colloquio si riduce al popolamento di nuovi Profili di Operazione nel DB di XML2SOA, senza alcuna necessità di intervenire sul codice di quest’ultimo.

� Anche indipendentemente da questo, è inoltre evidente che il disaccoppiamento a livello di codice tra la componente Java di XML2SOA e i componenti XSD/XSLT consentono la massima potenzialità di ampliamento delle soluzioni, separando peraltro in fase di sviluppo le pertinenze di chi detiene il know-how relativo a XML2SOA da quelle di chi detiene il know-how dei domini applicativi relativi ai Richiedenti/DestinatariRisposta. In altre parole, lo sviluppo dei componenti XSD/XSLT relativi alle RisposteARichiedente/RisposteADestinatario può essere demandato, indipendentemente da XML2SOA, al soggetto competente per il dominio applicativo che costituisce il destinatario finale delle informazioni.

� XML2SOA consente inoltre, in fase di trattamento della Risposta, la distribuzione delle informazioni fornite dal Sistema Remoto (DestinatarioRichiesta) su sollecitazione di un Richiedente a N DestinatariRisposta, in modo automatico e totalmente disaccoppiato.

In altre parole XML2SOA è predisposto ove necessario a gestire Richieste generate automaticamente, ad esempio ciclicamente, da un componente che giochi il ruolo di Richiedente (che può essere tanto un Demone sviluppato in ambienti quali Java, .NET, ecc., quanto addirittura un semplice Scheduled Task ospitato nel DB di XML2SOA), i cui risultati possono essere distribuiti in modo non sollecitato a qualsiasi Sistema –interno o esterno all’Organizzazione– se predisposto a riceverli in modalità SOAP Server.



3. Architettura generale



3.1 Tipologie di colloquio implementate da XML2SOA

Le casistiche relative allo scambio di messaggi con un SistemaRemoto prevedono solitamente 2 differenti tipologie di colloquio:

� sincrono: quando il contenuto del messaggio di risposta del SistemaRenoto esaurisce la Richiesta del Richiedente senza ulteriori attività;

� asincrono: quando un messaggio proveniente da un Richiedente è finalizzato esclusivamente all’innesco sul SistemaRemoto di un’elaborazione differita i cui esiti (che rappresentano la scopo del Richiedente) potranno essere recuperati non direttamente nell’ambito della risposta a tale messaggio, ma tramite l’invio di ulteriori successivi messaggi, costituenti nel loro insieme una SequenzaAsincrona.

Rispetto a quest’ultima logica di funzionamento, inoltre, è possibile distinguere 2 casi:

� colloquio asincrono basato su 3 tipi di messaggio,

� messaggio iniziale: innesca l’ElaborazioneRemota sul SistemaRemoto,

� messaggio intermedio: (o di sincronizzazione) interroga lo stato di avanzamento dell’ElaborazioneRemota,

� messaggio finale: recupera il risultato dell’ElaborazioneRemota;

� colloquio asincrono basato su 2 tipi di messaggio (versione ridotta della precedente):

� messaggio iniziale: corrisponde all’omonimo messaggio del caso precedente,

� messaggio finale: accorpando in un unico messaggio l’intermedio e il finale del caso precedente, interroga lo stato di avanzamento dell’ElaborazioneRemota e, quando risulti conclusa, ne recupera il risultato.

XML2SOA è in grado di supportare tutte le tipologie e casistiche di colloquio sopra enunciate.

Inoltre, come di seguito esposto, XML2SOA implementa, grazie al meccanismo parametrico delle trasformazioni XSLT (vedi Paragrafo 3.2.3.2), l’automatismo di gestione del colloquio asincrono in modalità trasparente al Richiedente.

Tale modalità trasparente prevede che, dopo la chiamata iniziale del Richiedente, il ciclo delle successive chiamate di sincronizzazione e di recupero dei risultati sia interamente gestito internamente a XML2SOA stesso, senza coinvolgimento del Richiedente.

In tal caso, al termine della SequenzaAsincrona, i risultati perverranno in maniera non sollecitata a un Server SOAP (configurato come DestinatarioRisposta del “messaggio finale”) che si suppone correlato al Richiedente che –in veste di Client SOAP– abbia originato la sequenza, in modalità atta comunque a riaccoppiare la Richiesta del “messaggio iniziale” con la Risposta del “messaggio finale”.

Resta inteso che, qualora questo meccanismo non dovesse essere compatibile con le esigenze del S.I. Locale che funge da Richiedente, resterà sempre possibile implementare un opportuno numero di Operazioni (2 o 3, secondo la casistica necessaria) da esso fruibili per farsi carico direttamente (e quindi sempre in modalità sincrona) delle singole chiamate che altrimenti sarebbero andate a comporre la SequenzaAsincrona a lui trasparente.



3.1.1 Colloquio sincrono

Il colloquio sincrono è riscontrabile quando è previsto che la Risposta alla Richiesta inviata da XML2SOA al DestinatarioRichiesta sia contenuta nel messaggio di risposta alla chiamata stessa, con questo esaurendosi il colloquio, senza ulteriore differimento del processamento della Richiesta (vedi Figura 3).

Figura 3 – «Sequence Diagram» generale in caso di colloquio sincrono



3.1.2 Colloquio asincrono

Il colloquio asincrono è riscontrabile quando è previsto che il processamento (ElaborazioneRemota) della Richiesta inviata da XML2SOA al DestinatarioRichiesta sia differito nel tempo da parte di quest’ultimo.

Questa modalità si espleta nel caso più esteso con una serie di 3 chiamate distinte:

� chiamata iniziale, contenente la Richiesta di natura asincrona,

� chiamata intermedia, per determinare l’esito dell’ElaborazioneRemota della Richiesta sul SistemaRemoto (può reiterarsi se il processamento risultasse non completato),

� chiamata finale, per ricevere la Risposta a fronte del completamento dell’ElaborazioneRemota.

3.1.2.1 Scenario della chiamata iniziale

Nell’ambito della chiamata iniziale, scatenata dal Richiedente, il messaggio di risposta alla chiamata stessa contiene un mero riscontro di tipo ACK/NACK, che provocherà a tutti gli effetti l’esaurimento (sincrono) del colloquio tra il Richiedente e XML2SOA con tale RispostaARichiedente (vedi Figura 4).

Figura 4 – «Sequence Diagram» generale in caso di colloquio asincrono (parte 1)



3.1.2.2 Scenario delle chiamate intermedia e finale

In caso di ACK alla chiamata iniziale, tale esito proviene dal DestinatarioRichiesta e transita fino al Richiedente. A livello del DestinatarioRichiesta (SistemaRemoto) tale ACK si traduce in un’accettazione della Richiesta che porta a procedere in modalità differita alla conseguente ElaborazioneRemota.

Figura 5 – «Sequence Diagram» generale in caso di colloquio asincrono (parte 2)

XML2SOA quindi (vedi Figura 5):

� interroga ciclicamente il DestinatarioRichiesta effettuando chiamate intermedie contenenti opportuni messaggi c.d. di sincronizzazione, tramite i quali riceve un riscontro sullo stato di avanzamento dell’ElaborazioneRemota;



� a fronte di un riscontro di tipo “processamento concluso”, XML2SOA procede alla chiamata finale contenente un messaggio di richiesta del risultato dell’ElaborazioneRemota, tramite il quale perverrà la Risposta.

3.1.2.3 Considerazioni sul colloquio asincrono

In caso di colloquio asincrono, quindi:

� siamo di fronte a transazioni logiche composte non da 1 ma da molteplici chiamate;

� va inoltre sottolineato che il contenuto informativo del risultato dell’ElaborazioneRemota processata sul SistemaRemoto (da un punto di vista almeno logico, se non sempre fisico, corrispondente al DestinatarioRichiesta), risultato che in altre parole rappresenta l’obiettivo stesso della Richiesta iniziale del Richiedente, perverrà (in veste di RispostaADestinatario non sollecitata) ai DestinatariRisposta, all’ ”insaputa” del Richiedente stesso;

� non ha quindi senso che transazioni di questo tipo prefigurino meno di 1 DestinatarioRisposta3.

Si tenga inoltre in considerazione che:

� la transazione asincrona a 3 chiamate sopra esposta rappresenta il caso più esteso di SequenzaAsincrona;

� si possono riscontrare anche transazioni asincrone basate su 2 sole chiamate (in cui quella intermedia e quella finale del caso precedente sono accorpate in un’unica tipologia di chiamata, sempre successiva a quella iniziale);

� in virtù della sua dinamicità di gestione, legata alle possibilità date dall’esecuzione di trasformazioni parametriche, XML2SOA è in grado di gestire in modalità del tutto standard anche questa casistica di colloquio a 2 chiamate (vedi a riguardo il successivo Paragrafo 3.2.3.2).

3 A conferma, si noti che, nelle Figure precedenti, questo –a livello Diagrammi– è evidenziato dal fatto che,

mentre nella Figura 3 il fragment di tipo “Loop [1..N]” è nidificato in un fragment di tipo “Opt”, nella Figura 5 il fragment di tipo “Loop [1..N]” non è ospitato da un fragment di tipo “Opt”.



3.2 Architettura e logica di funzionamento di XML2SOA

3.2.1 Componenti

Il seguente diagramma illustra la strutturazione dei componenti logici di XML2SOA.

Figura 6 – «Component Diagram» di XML2SOA.

XML2SOA in quanto tale è un deliverable software che gioca i ruoli:

� di Server SOAP (componente XML2SOA_PORTA0), esponendo un unico servizio fruibile dai Richiedenti, per mezzo del quale essi possono inoltrare di volta in volta una Richiesta contenente la specifica dell’Operazione correntemente invocata;

� di Client SOAP (componente XML2SOA_SENDER), invocando servizi esposti:

� dal DestinatarioRichiesta per la soddisfazione della Richiesta del Richiedente,

� eventualmente da 1 o più DestinatariRisposta, nel caso in cui il Profilo dell’Operazione preveda l’inoltro dei risultati a Sistemi Informativi terzi.



3.2.2 Comunicazione tra componenti

Il seguente diagramma illustra la comunicazione che intercorre tra i componenti logici di XML2SOA, a fronte delle Richieste che pervengono a livello di Server SOAP.

Figura 7 – «Communication Diagram» di XML2SOA.



3.2.3 Componenti e macrologica del loro funzionamento

I componenti di XML2SOA qui di seguito descritti sono tutti sviluppati in linguaggio Java.

3.2.3.1 Componenti XML2SOA

Al proprio interno XML2SOA è composto dai seguenti componenti.

XML2SOA_PORTA0

Riceve le Richieste delle chiamate dei Richiedenti e (trasformandole in RichiesteARemoto) le consegna a XML2SOA_SENDER, da cui riceve quindi le corrispondenti Risposte che (trasformate in RisposteARichiedente) restituisce ai corrispondenti Richiedenti.

XML2SOA_SENDER

Svolge indistintamente, sulla base della stessa logica di funzionamento, 2 differenti funzioni:

� riceve le RichiesteARemoto da XML2SOA_PORTA0 e le inoltra al DestinatarioRichiesta, ne riceve la Risposta che viene consegnata al componente XML2SOA_ENQ (vedi di seguito) per eventuali DestinatariRisposta e a XML2SOA_PORTA0 perché venga consegnata al Richiedente.

� riceve le RisposteADestinatario da XML2SOA_DEQ (vedi di seguito) e le inoltra al corrispondente DestinatarioRisposta, da cui riceve un riscontro di tipo ACK/NACK che restituisce a XML2SOA_DEQ stesso.

XML2SOA_ENQ

Riceve le Risposte da XML2SOA_SENDER e verifica dal Profilo la presenza di eventuali DestinatariRisposta; se questi sono previsti, per ciascuno di essi le trasforma, in base al Profilo, in RispostaADestinatario che inserisce in un’apposita coda allocata su DB dedicato, altrimenti le scarta.

XML2SOA_DEQ

E’ un demone che sulla base di un timer configurabile preleva le RispostaADestinatario dalla coda e le consegna a XML2SOA_SENDER per l’inoltro; ne riceve un esito di tipo ACK o NACK, sulla base del quale elimina definitivamente o mantiene la Risposta nella coda.

3.2.3.2 Transazione di tipo “XML2SOA_PROMOTER”

Posto che XML2SOA_SENDER è un componente che agisce con ruolo di Client SOAP e che XML2SOA_PORTA0 è un componente che agisce con ruolo di Server SOAP, nulla vieta la possibilità che il primo effettui chiamate al secondo, in uno scenario in cui XML2SOA si raffigura contemporaneamente come Richiedente e DestinatarioRisposta di se stesso.



Questa concatenazione di chiamate a se stesso (basate sulle ampie potenzialità date dalla parametricità della trasformazione XSLT insita nei Profili delle differenti Operazioni) è convenzionalmente denominata «Transazione di tipo “XML2SOA_PROMOTER».

Tramite essa si rende possibile l’ingegnerizzazione del workflow delle Richieste là dove le transazioni logiche del DestinatarioRichiesta si svolgano in modalità asincrona (vedi Paragrafo 3.1.2), ovvero dove la transazione preveda una serie successiva e progressiva di chiamate a servizi differenti esposti dal DestinatarioRichiesta (come appunto nel caso della c.d. SequenzaAsincrona).

Facendo riferimento alla classificazione delle chiamate nell’ambito del colloquio asincrono in iniziali, intermedie e finali (di cui al Paragrafo citato), a ciascuna di queste chiamate corrisponde lato XML2SOA un’Operazione distinta, quindi ciascuna dotata di un proprio Profilo specifico.

Chiamata Iniziale

Il Profilo dell’Operazione (caratterizzato da una Tipologia di Profilo che, per evitare equivoci, qui chiameremo TipoOperazione1) corrispondente a tale chiamata iniziale (che qui chiameremo Chiamata T1) prevede: � Richiedente = il S.I. Locale che necessita dell’esecuzione della transazione,

cui dunque spetta l’iniziativa di inoltrare la Richiesta a XML2SOA;

� DestinatarioRichiesta = un SistemaRemoto;

� DestinatarioRisposta = XML2SOA (=XML2SOA_PORTA0).

La RispostaARichiedente che XML2SOA restituirà (tramite sequenza PORTA0-SENDER-SistemaRemoto-SENDER-PORTA0) al Richiedente (S.I. Locale chiamante) conterrà il mero esito della chiamata, ovvero un riscontro di tipo ACK/NACK, atto a chiudere la presente Chiamata T1.

Al tempo stesso (tramite il percorso standard ENQ-DEQ-SENDER) viene ulteriormente inoltrata a XML2SOA la RispostaADestinatario, che –in virtù del meccanismo di trasformazione– assumerà il contenuto informativo4 atto a generare (da parte di XML2SOA_DEQ, in veste di Richiedente) una Richiesta (di TipoOperazione2) corrispondente alla chiamata intermedia (Chiamata T2).

Chiamata Intermedia

Il Profilo dell’Operazione corrispondente a tale chiamata (Chiamata T2) prevede: � Richiedente = XML2SOA (=XML2SOA_DEQ);

� DestinatarioRichiesta = il SistemaRemoto coinvolto nella chiamata iniziale o comunque un componente riconducibile ad esso;

� DestinatarioRisposta = XML2SOA (=XML2SOA_PORTA0).

La RispostaARichiedente che XML2SOA restituirà (tramite sequenza PORTA0-SENDER-SistemaRemoto-SENDER-PORTA0) al Richiedente (XML2SOA_DEQ) conterrà nuovamente un mero riscontro di tipo ACK/NACK, atto a chiudere la presente Chiamata T2.

La RispostaADestinatario, che perverrà (tramite sequenza ENQ-DEQ-SENDER) anch’essa nuovamente a XML2SOA, consentirà di reimpostare da capo il ciclo, come già precedentemente impostato a partire dalla chiamata iniziale del Richiedente.

Infatti, la successiva trasformazione di questa RispostaADestinatario che verrà inoltrata da XML2SOA_DEQ a XML2SOA_PORTA0 consentirà:

4 Ad esempio, un identificativo univoco, un numero di protocollo, o quant’altro atto a collegare presso il

SistemaRemoto (DestinatarioRichiesta) la chiamata intermedia alla chiamata iniziale (e successivamente, per analogia, la chiamata finale alla iniziale).



� a fronte di un esito tipo “processamento non concluso”, di reiterare un’ulteriore chiamata intermedia (Chiamata T2), generando la corrispondente Richiesta (di TipoOperazione2);

� a fronte di un esito tipo “processamento concluso”, di procedere ad effettuare la chiamata finale (Chiamata T3), generando la corrispondente Richiesta (di TipoOperazione3).

Chiamata Finale

Il Profilo dell’Operazione corrispondente a tale chiamata (Chiamata T3) prevede: � Richiedente = XML2SOA (=XML2SOA_DEQ);

� DestinatarioRichiesta = il SistemaRemoto coinvolto nella chiamata iniziale o comunque un componente riconducibile ad esso;

� DestinatarioRisposta = il/i componente/i destinato/i a ricevere il contenuto informativo target della Richiesta iniziale.

Anche in questo caso, la RispostaARichiedente che XML2SOA restituirà (tramite sequenza PORTA0-SENDER-SistemaRemoto-SENDER-PORTA0) al Richiedente (XML2SOA_DEQ) conterrà il mero riscontro di tipo ACK/NACK, atto a chiudere la presente Chiamata T3.

L’effettivo contenuto informativo della Risposta trasmessa dal SistemaRemoto (es.: il risultato di una interrogazione, ecc.), trasformato nella forma di RispostaADestinatario, perverrà invece (tramite sequenza ENQ-DEQ-SENDER e in modalità dunque non sollecitata) ai S.I. Locali destinatari delle informazioni target (probabilmente ma non obbligatoriamente, componenti afferenti al S.I. Locale che ha generato la chiamata iniziale), portando così a conclusione il workflow della SequenzaAsincrona.

CONSIDERAZIONI SULLE SCELTE IMPLEMENTATIVE

A seguito di questa scelta implementativa, si raggiunge l’obiettivo di mantenere performante l’atomicità e inalterata l’univocità logica di XML2SOA_SENDER (anche in termini di riduzione della complessità del codice), dato che esso è in grado di trattare in modo indistinto la gestione delle chiamate sia verso il DestinatarioRichiesta che verso il DestinatarioRisposta.

Inoltre la scomposizione della SequenzaAsincrona in Operazioni aventi tipologie distinte e di fatto isolate l’una dall’altra consente di gestire in modo più pregnante le attività di tracciamento della chiamate che la compongono.

E’ da notare infine che questa soluzione implica che a livello dei S.I. richiedenti si realizzi un disaccoppiamento tra:

� una parte Client SOAP, preposta all’inoltro della Richiesta iniziale a XML2SOA,

� una parte Server SOAP preposta alla ricezione della RispostaADestinatario.

Ed è quindi evidente che in tale caso è responsabilità autonoma di ciascun S.I. Richiedente quello di riconciliare, localmente nel proprio ambito applicativo, la Richiesta con la RispostaADestinatario.

In alternativa, l’unica possibilità risulterebbe nel fatto di demandare al S.I. richiedente la gestione della sincronizzazione tramite l’assunzione diretta della responsabilità delle 3 tipologie di chiamata, implementando al proprio interno la gestione di altrettante Operazioni basate su messaggi sincroni.

In altre parole, i S.I. Locali dovrebbero ciascuno assumere per una certa parte il know-how della logica di funzionamento delle transazioni asincrone del proprio DestinatarioRichiesta. Mentre,



demandando la gestione di tale know-how a XML2SOA, i Richiedenti devono soltanto conoscere lo standard di chiamate verso di esso senza occuparsi di altro, se non la corretta ricezione della RispostaADestinatario.

Per altro, come già anticipato5, la possibilità data di costruire transazioni logiche di tipo XML2SOA_PROMOTER (per consentire la possibilità di mascherare ai S.I. fruitori l’esecuzione della SequenzaAsincrona) non esclude in nessun momento e caso la soluzione alternativa della gestione sincrona (non “trasparente”) come possibile scelta da parte dei responsabili del S.I. Locale).

5 Vedi Capitolo 3.1



3.2.4 Introduzione alla profilazione delle Operazioni

Al fine di favorire la percezione delle potenzialità indotte dal binding dinamico delle Operazioni sulla base della loro profilazione, in questo Paragrafo vengono presentate le principali caratteristiche inerenti alla loro parametrizzazione.

3.2.4.1 Entità di base per la costruzione dei Profili

Le principali Entità che stanno alla base del Profilo dell’Operazione sono le seguenti.

Figura 8 – Principali Entità che compongono il Profilo dell’Operazione in ambito XML2SOA.

Entità Descrizione Attributi Info Applicazioni Costituiscono l’insieme dei Richiedenti

autorizzati ad accedere ai servizi di XML2SOA.

� Login � Password

Sono le credenziali utilizzate da un’Applicazione per autenticarsi presso XML2SOA.

Destinatari Costituiscono l’insieme dei Destinatari interfacciabili tramite i servizi di XML2SOA. Si suddividono in: � DestinatariRichiesta � DestinatariRisposta

� Info Destinatario Informazioni varie relative al Destinatario. Entrambe le tipologie di Destinatario rappresentano dei Server SOAP.

Servizi Costituiscono l’insieme dei Servizi corrispondenti ai Destinatari.

� URL � Info Servizi

Si tratta della URL di accesso ad un Server SOAP più altre informazioni opzionali.

UtenzeRemote Costituiscono l’insieme delle credenziali riconosciute dai Servizi SOAP corrispondenti ai Destinatari.

� Login � Password � Info Utenza Remota

Sono le credenziali utilizzate se necessario da XML2SOA per autenticarsi presso un Destinatario (di entrambe le tipologie) per conto del Richiedente.

Test Costituiscono l’insieme dei Test applicabili ai Documenti XML trattati nelle differenti Fasi di elaborazione, ai fini di determinare la natura del Documento corrente (es.: Risposta positiva, Risposta negativa, segnalazione di errore, ecc.).

� Testo XQuery � Risultato XQuery in caso di esito positivo del Test

I Test sono basati sull’applicazione di XQuery ai Documenti XML correntemente trattati.

Esiti Costituiscono l’insieme delle informazioni relative ai differenti esiti finali della transazione da comunicare al Richiedente per i casi di risultato negativo o positivo.

� Codice esito � Descrizione esito � Msg a Richiedente � SubClasse di Esito

Sono suddivisi in: � Esiti di sistema, generati autonomamente da XML2SOA in caso di anomalia,

� Esiti applicativi, generati da XML2SOA a partire dal contenuto della Risposta restituita dal DestinatarioRichiesta.

E’ da notare che l’Entità «Profilo» (intendendo per questa il Profilo dell’Operazione) non ha attributi specifici, rappresentando di fatto un “contenitore” all’interno del quale vengono di volta in volta combinate tra loro le Entità sopra definite secondo uno schema prestabilito.



3.2.4.2 Relazioni di base per la costruzione dei Profili

Le principali Relazioni che stanno alla base del Profilo dell’Operazione sono quelle illustrate nelle seguenti Figure.

Figura 9 – Principali Relazioni che compongono il Profilo dell’Operazione in ambito XML2SOA.

Entità/Associazioni Entità correlate Info

Operazione Applicazione

Ciascuna Operazione può essere invocata da N Applicazioni abilitate (Richiedenti). Applicazioni abilitate (correlate) all’x-esima Operazione possono non essere abilitate all’y-esima Operazione.

Operazione- Applicazione

DestinatarioRichiesta XSD XSLT

A ciascuna relazione Operazione-Applicazione sono correlati: � 1 solo DestinatarioRichiesta (nell’attuale Versione di XML2SOA) a cui trasmettere la RichiestaARemoto proveniente dal Richiedente;

� 1 coppia XSD/XSLT atta a validare la Richiesta pervenuta dall’Applicazione chiamante e a trasformarla in RichiestaARemoto da trasmettere al DestinatarioRichiesta.

Test

Nell’ambito di ciascuna relazione Operazione-Applicazione, al DestinatarioRichiesta sono correlati: � 2..N Test, per mezzo dei quali è possibile stabilire la natura della Risposta proveniente da DestinatarioRichiesta stesso, in funzione del dominio applicativo del Richiedente6.

Operazione- Applicazione- DestinatarioRichiesta

DestinatarioRisposta

Nell’ambito di ciascuna relazione Operazione-Applicazione, al DestinatarioRichiesta sono correlati: � 0..N DestinatariRisposta, ai quali inoltrare la Risposta proveniente da esso.

Operazione- Applicazione- DestinatarioRichiesta- Test

Esiti XSD XSLT

Nell’ambito di ciascuna relazione Operazione-Applicazione-DestinatarioRichiesta, a ciascun Test sono correlati: � 1 Esito, � 1 coppia XSD/XSLT, per mezzo dei quali è possibile pervenire alla formazione della RispostaARichiedente da restituire al Richiedente.

Operazione- Applicazione- DestinatarioRichiesta- DestinatarioRisposta

Test

Nell’ambito di ciascuna relazione Operazione-Applicazione-DestinatarioRichiesta, al DestinatarioRisposta sono correlati; � 2..N Test, per mezzo dei quali è possibile stabilire la natura della Risposta proveniente dal DestinatarioRichiesta, in funzione del dominio applicativo del DestinatarioRisposta stesso6.

Operazione- Applicazione- DestinatarioRichiesta- DestinatarioRisposta- Test

Esiti XSD XSLT

Nell’ambito di ciascuna relazione Operazione-Applicazione-DestinatarioRichiesta-DestinatarioRisposta, a ciascun Test sono correlati: � 1 Esito, � 1 coppia XSD/XSLT. A seconda della Fase di Test associata (ovvero a seconda che la Fase di Test sia espletata nell’ambito di XML2SOA_ENQ oppure di XML2SOA_DEQ), per mezzo di detti XSD e XSLT è possibile pervenire: � (in caso di Test sulla Risposta) alla formazione della RispostaADestinatario da trasmettere al DestinatarioRisposta;

� (in caso di Test sulla AckRisposta) alla determinazione dell’esito finale della trasmissione della RispostaADestinatario al DestinatarioRisposta.

Dette Relazioni sono illustrate nel Diagramma di cui alla seguente Figura.

6 La quantità di Test configurati dovrà essere almeno 2: 1 in caso di esito negativo e 1 in caso di esito positivo.



Figura 10 – «Entity-Relationship Diagram» inerente al Profilo dell’Operazione in ambito XML2SOA.

3.2.4.3 Riepilogo delle caratteristiche di base per la costruzione dei Profili

La profilazione di una nuova Operazione prevede a grandi linee di determinare dunque le seguenti informazioni:

1. il Codice attribuito all’Operazione nelle Richieste che la invocano; 2. quali Applicazioni (Richiedenti) potranno invocare l’Operazione e con quali credenziali saranno

autenticate da XML2SOA; 3. quali DestinatariRichiesta (1 unico, nell’attuale versione 1.0) dovranno fornire le informazioni

richieste; 4. per ciascun DestinatarioRichiesta di cui al punto 3:

� l’URL del Servizio SOAP corrispondente al DestinatarioRichiesta, � le credenziali con le quali XML2SOA sarà autenticato dal DestinatarioRichiesta, � le eventuali Informazioni aggiuntive atte a completare la comunicazione di XML2SOA verso il

DestinatarioRichiesta, � la coppia XSD1/XSLT1 atta a validare la Richiesta e trasformarla dal formato condiviso dal

Richiedente con XML2SOA nel formato (RichiestaARemoto) specifico del dominio applicativo del DestinatarioRichiesta,

� il gruppo di 2..N Test da applicare alla Risposta restituita dal DestinatarioRichiesta per determinarne una risultanza positiva o negativa, ai fini della comunicazione della RispostaARichiedente al Richiedente,

� eventuali DestinatariRisposta; 5. per ciascun Test di cui al punto 4:

� il testo della XQuery atta a intercettare la risultanza del Test, � il risultato della XQuery corrispondente all’intercettazione7,

7 Ciascuna XQuery sarà composta da:

� un controllo da applicare al contenuto del corrente Documento XML da testare (es. presenza o assenza di un determinato Nodo, oppure presenza/assenza di un particolare contenuto di un determinato Nodo, ecc.),

� un valore corrispondente al risultato positivo del controllo,



� la codifica dell’Esito (positivo o negativo) specificamente intercettato dal Test, da comunicare al Richiedente (Codice, Descrizione, Messaggio, Subclasse),

� la coppia XSD2/XSLT2 atta a validare la Risposta e trasformarla dal formato previsto dal DestinatarioRichiesta nel formato (RispostaARichiedente) specifico del dominio applicativo del Richiedente;

6. per ciascun DestinatarioRisposta di cui al punto 4: � l’URL del Servizio SOAP corrispondente al DestinatarioRisposta, � le credenziali con le quali XML2SOA sarà autenticato dal DestinatarioRisposta, � le eventuali Informazioni aggiuntive atte a completare la comunicazione di XML2SOA verso il

DestinatarioRisposta, � il gruppo di 2..N Test da applicare alla Risposta restituita dal DestinatarioRichiesta per

determinarne una risultanza positiva o negativa, ai fini della comunicazione della RispostaADestinatario al DestinatarioRisposta,

� il gruppo di 2..N Test da applicare alla AckRisposta restituita dal DestinatarioRisposta per determinarne una risultanza positiva o negativa, ai fini della determinazione dell’esito finale della trasmissione della RispostaADestinatario al DestinatarioRisposta;

7. per ciascun Test appartenente al 1° gruppo di cui al punto 6 (Test applicabile alla Risposta restituita dal DestinatarioRichiesta): � il testo della XQuery atta a intercettare la risultanza del Test, � il risultato della XQuery corrispondente all’intercettazione7, � la codifica dell’Esito (positivo o negativo) specificamente intercettato dal Test, da comunicare

al DestinatarioRisposta (Codice, Descrizione, Messaggio, Subclasse), � la coppia XSD3/XSLT3 atta a validare la Risposta e trasformarla dal formato previsto dal

DestinatarioRichiesta nel formato (RispostaADestinatario) specifico del dominio applicativo del DestinatarioRisposta;

8. per ciascun Test appartenente al 2° gruppo di cui al punto 6 (Test applicabile alla AckRisposta restituita dal DestinatarioRisposta): � il testo della XQuery atta a intercettare la risultanza del Test, � il risultato della XQuery corrispondente all’intercettazione7, � la codifica dell’Esito (positivo o negativo) specificamente intercettato dal Test, corrispondente

all’esito finale della trasmissione della RispostaADestinatario al DestinatarioRisposta (Codice, Descrizione, Messaggio, Subclasse),

� la coppia XSD4/XSLT4 atta a validare la AckRisposta e trasformarla dal formato previsto dal DestinatarioRisposta nel formato specifico del dominio applicativo di XML2SOA.

� un valore corrispondente al risultato negativo del controllo.

Il Test sarà ritenuto positivo se il risultato ottenuto a run-time dall’esecuzione della XQuery corrisponderà al valore configurato in fase di profilazione del Test.



3.2.5 Scalabilità

Ferma restando l’ovvia possibilità di dispiegarne istanze plurime a compartimenti stagni (ovvero ciascuna istanza dotata di un proprio DB autonomo e dunque totalmente isolata da eventuali altre), le caratteristiche intrinseche di XML2SOA consentono di distribuire la scalabilità del deployment su istanze plurime dei componenti applicativi che condividano invece un unico DB (di adeguate prestazioni) su cui risulteranno concentrate univocamente tutte le informazioni relative sia alle profilazioni delle Operazioni che all’esecuzione delle relative transazioni logiche innescate dalle chiamate effettuate dai S.I. Richiedenti.

Per facilitare il tracciamento delle Operazioni, l’unico punto di aggancio del disegno dati all’eventuale presenza di istanze molteplici è fornito dalla conseguente marcatura delle informazioni di Log e della Coda delle RisposteADestinatario.

In presenza di istanze multiple, l’accesso alle singole istanze da parte dei Sistemi Informativi Richiedenti potrà essere governato dai responsabili del deployment (amministratori di sistema) in modo statico, assegnando ciascuna istanza a un sottoinsieme prestabilito di S.I. Richiedenti (tramite la distribuzione ai S.I. Richiedenti di parametri differenziati di accesso al componente XML2SOA_PORTA0 di ciascuna istanza), o dinamicamente, in presenza di sottosistemi di gestione del load balancing (vedi Figure successive).

Dal punto di vista della logica di funzionamento, al momento dell’inizializzazione generale, ciascuna istanza acquisisce il proprio identificativo tramite un opportuno Parametro di Configurazione e lo utilizza per marcare sul DB, ove previsto, le informazioni di propria competenza.

Al fine poi di migliorare le performance di inoltro delle RisposteADestinatario da parte del componente XML2SOA_DEQ, al momento dell’inizializzazione generale viene acquisito anche un ulteriore Parametro di Configurazione contenente un indicatore (switch) sulla base del quale si determina se ciascun componente XML2SOA_DEQ appartenente a un’istanza di XML2SOA debba elaborare solo elementi della coda delle RisposteADestinatario generati dalla propria istanza o anche elementi della coda generati da altre istanze. Appare ovvio che nel secondo caso, qualora un popolamento massivo della coda risultasse sbilanciato su un sottoinsieme delle istanze, l’onere del suo svuotamento potrà essere distribuito su tutte le istanze presenti, migliorando le performance generali.



Figura 11 – Esempio di deployment multi-istanza di XML2SOA in presenza di dispositivo di load balancing.

Figura 12 – Esempio di deployment multi-istanza di XML2SOA con assegnazione statica applicazione-istanza.



Figura 13 – Esempio di deployment multi-istanza di XML2SOA con assegnazione statica operazione-istanza.

Date post:	10-May-2019
Category:	Documents
Upload:	phamdan
View:	213 times
Download:	0 times

Xml2Soa Volume1 v1-1p -...

Documents