Operazione: Progettazione del messaggio
Questa attività descrive le azioni richieste per sviluppare un modello completo di progettazione del messaggio (catalogo). Tratta inoltre, come sfondo, i modelli di scambio dei messaggi e la relazione del modello di dominio con il modello del messaggio. Verranno esposte inoltre considerazioni sulla progettazione per la granularità del messaggio e per le prestazioni del messaggio.
Discipline: Analisi e progettazione
Relazioni
Descrizione principale
I messaggi ed i componenti tra i servizi comunicanti sono una parte critica di una SOA. Questi includono non solo i messaggi di input e output di un dato richiamo del servizio, ma anche il formato del messaggio iniziale da utilizzare nell'impresa quando il flusso di informazioni passa nei livelli di architettura dell'applicazione.  In molti casi, un formato comune del messaggio è consigliato.

Poiché i servizi includono i messaggi di input e output, questa funzione si incentra su:

  • l'identificazione e specifica del formato e del contenuto dei messaggi di input e output di un servizio,
  • la sua relazione con i modelli di dati sottostanti,
  • il formato comune del messaggio interno e le considerazioni e
  • le decisioni su come associare ogni messaggio ad un altro.

La specifica dei messaggio per il modello del servizio dovrebbe considerare le prospettive dall'architettura dell'azienda o dell'applicazione, di dati e di integrazione. Sono inclusi:

  • Gli standard del messaggio definiti a livello di azienda o applicazione
  • Il modello di dati o metadati appropriato che sono parte di una architettura di dati
  • Gli standard di trasformazione del messaggio che sono parte di un'architettura di integrazione.

Durante la specifica, è importante capire gli standard dell'organizzazione, se disponibili, in ognuna delle 3 aree di architettura. Le specifiche del messaggio ed i modelli di dati sono legati. Il modello di dati consiste di entità sottostanti e dei loro rapporti, di cui è possibile inviare un sottoinsieme come parte di un messaggio di output e riceverlo come input dal messaggio in entrata. Dunque l'associazione tra i formati del messaggio ed il modello di dati sottostante o l'architettura di dati è una considerazione chiave sull'architettura. In alcuni casi, i modelli e la loro implementazione come Enterprise Service Bus possono gestire la trasformazione (ed il routing) dei messaggi. In molti casi, è possibile che sia necessario un gestore esplicito per trasformare i messaggi da e nei modelli di dati.

Nella maggior parte dei linguaggi di programmazione orientati all'oggetto, la chiamata di un funzionamento si basa sulle chiamate del metodo o sui paradigmi di passaggio dei messaggi. C++ ad esempio, utilizza le tabelle dei puntatori di funzione per richiamare il metodo corretto. D'altra parte Smalltalk, passa i messaggi il cui destinatario viene valutato al momento dell'esecuzione. Le soluzioni orientate al servizio sono inerentemente basate sui messaggi e mentre i binding ai linguaggi di programmazione possono presentare interfacce basate sul metodo per i client, questa non è la realtà della comunicazione con o tra i servizi. Un altro aspetto della messaggistica del servizio è che quanto più i servizi vengono sviluppati con interfacce asincrone tanto più si oppongono alla natura fondamentalmente sincrona delle chiamate del metodo.

Nell'arena di integrazione dell'impresa,è stata utilizzata con successo una classe di tecnologia per alcuni anni: MOM ( Message Oriented Middleware). Questo insieme di tecnologie è manifesto nei prodotti quali gestori code e broker messaggi. Ha fornito organizzazioni IT con un metodo flessibile, scalabile e robusto per le applicazioni che si connettono debolmente.

E' stato notato che la SOA (Service-Oriented Architecture) è un'evoluzione dello sviluppo basato sul componente. In alcune situazioni questa evoluzione prende in considerazione molte delle lezioni apprese dal successo di MOM: come unire debolmente i sistemi in modo efficace. L'infrastruttura MOM fornisce le caratteristiche seguenti che consentono ai sistemi di comunicazione di evolvere indipendentemente.

  • Coda messaggi, per una distribuzione affidabile dei messaggi anche nel caso di un errore del sistema o della rete.
  • Routing messaggi, in entrambi i termini di routing attorno alla rete per prestazioni e affidabilità e routing avanzato basato sul contenuto del messaggio.
  • Trasformazione messaggi, in modo che un servizio di chiamata sia in grado di spedire una richiesta per un "prodotto" quando il servizio ricevente può accettare le richieste per gli "elementi."
  • Adattatori messaggi, per consentire ai sistemi che non sono stati sviluppato in origine con le interfacce MOM di essere indirizzati dai servizi abilitati di MOM.
Passi
Utilizzo degli standard di messaggio
Quando si definiscono le specifiche del messaggio per i servizi identificati, è importante prendere in considerazioni gli standard del messaggio dell'impresa se esistono.  Dove gli standard del messaggio non sono identificati, è consigliabile svilupparli. Dove esistono gli schemi del messaggio del settore, si consiglia di utilizzarli.  Ad esempio, le specifiche di messaggistica XML sono state definite per i settori finanza, gestione, viaggi (OTA XML [Open Travel Alliance, http://www.opentravel.org/online_schema.cfm]) e comunicazione.   Inoltre, non ci sono schemi specifici non del settore disponibili da OAGIS [Open Applications Group, http://www.openapplications.org/index.htm].

Formato messaggio comune

I messaggi comuni fanno riferimento ai messaggi che vengono trasferiti nei livelli di un'architettura a n livelli.  In genere, le informazioni dell'interfaccia utente vengono riportate, inviate ad un livello di controllo nei livelli di business o applicazione e quindi passate ad un livello di persistenza o ad un sistema precedente di backend.  Durante ogni trasferimento, viene scambiato un messaggio tra livelli dove ognuno può avere un formato diverso.  La cosa importante accordarsi su uno standard per un formato del messaggio comune all'interno dell'impresa così da superare il sovraccarico della traduzione del formato dove non viene utilizzato l'ESB (Enterprise Service Bus) o quando il suo utilizzo è ritenuto espansivo in termini di traduzione del formato.  L'utilizzo di un ESB si occupa di molte tra queste mediazioni, trasformazioni e routing.  Questo è il livello di integrazione come illustrato nel modello dei livelli SOA.

In alcuni casi, potrebbe essere sufficiente accordarsi sui formati dei messaggi in entrata ed in uscita.  La questione di un formato del messaggio comune è una decisione chiave strutturale: è possibile scegliere di "roll your own" come di seguito specificato, adottare i modelli del settore come ad esempio XML OTA del settore o adottare modelli specifici non del settore come ad esempio quelli definiti da OAGIS.  In alcuni casi, la decisione sarà di utilizzare un messaggio aziendale comune che aggiorna i campi nel messaggio e li passa al livello successivo per un'ulteriore elaborazione.   Se un tale schema comune non può essere ottenuto a causa di fattori politici, allora è possibile progettare gli adattatori che traducono i messaggi in un messaggio interno comune.  Questi possono anche essere utilizzati come parte di un ESB.

Considerazioni ISV : I messaggi che richiamano i servizi realizzati nei pacchetti ISV potrebbero dover essere argomentati con gli attributi dei dati per soddisfare i limiti nel modello di dati del pacchetto ISV.  Tali elementi di dati potrebbero essere identificati tramite l'analisi del servizio realizzato nel componente del pacchetto ISV o potrebbero anche essere identificati tramite l'analisi del servizio dal basso in alto del pacchetto ISV.  Poiché questi attributi potrebbero non essere identificati fino alla realizzazione del servizio, questi potrebbero essere adattati nel messaggio comune quando sono identificati.

Formato del messaggio comune e architettura dei dati

In generale, i servizi non dovrebbero indicare nient'altro che i modelli dei dati sottostanti.  Piuttosto, questi dovrebbero essere utilizzati per incapsulare i modelli dei dati sottostanti i cui archivi di dati sono utilizzati dai componenti del servizio che realizzano i servizi. Quindi, i servizi che sono visualizza, modifica, cancella,aggiungi ricerca e altre operazioni su un database potrebbero non essere buoni candidati per i servizi ma potrebbero essere utilizzati come operazioni del componente sottostante come sono utilizzate oggi.

Le architetture dei dati esistenti che definiscono i modelli di dati concettuali, logici o fisici sono origini obbligatorie nella definizione dei formati dei messaggi comuni.  Le definizioni dei formati dei comuni dovrebbero essere coordinate con gli impegni dell'architettura di dati ed i modelli di dati.  Questa analisi assicura la disponibilità di archivi di dati e schemi appropriati e per i componenti del servizio che realizzano nuovi servizi.  L'architettura di dati esistenti verrà potenziata per conformarsi ai nuovi servizi se è necessario aggiungere i dati ai sistemi sottostanti.

In molte aziende, i sistemi esistenti spesso riflettono l'esistenza di silos e isole di dati che collaborano nei processi di batch. La migrazione dagli archivi di dati isolati è possibile tramite i mezzi dei servizi.  L'identificazione delle origini dati del provider del servizio è eseguita durante la realizzazione del servizio

Considerazioni ISV: Il modello di dati logico deve conformarsi ai modelli di dati predefiniti, spesso impliciti incorporati nei pacchetti ISV.  Quindi il messaggio si trasferisce tra le applicazioni impacchettate e devono verificarsi i modelli di dati esistenti. Questo è spesso fatto tramite le API offerte dalle ISV. In un SOA, gli adattatori a questi modelli di dati ISV diventano importanti, specialmente se l'ISV non espone i dati sottostanti e la funzionalità tramite i servizi.

Notare che in alcuni casi in cui il modello di dati ISV è accessibile, potrebbe essere possibile personalizzare il modello per conformare i messaggi richiesti per supportare i servizi identificati.  Al contrario, se il modello di dati non è accessibile, la messaggistica del servizio potrebbe essere limitata dal modello di dati contenuto nell'ISV.  Un meccanismo di mediazione può anche essere impiegato per limitare il problema. La mediazione, come quella fornita da un ESB può essere utilizzata in questo contesto per supportare l'interfaccia con i pacchetti ISV.  Il modello di dati ISV potrebbe anche dettare gli altri attributi che sono richiesti oltre quelli richiesti per implementare il servizio.

Il formato del messaggio comune con tutti i servizi relativi

I formati del messaggio comune devono essere riconciliati con i messaggi di input/output dei servizi singoli e assegnati per consentire ai servizi appropriati di utilizzarli e aggiornarli in base alle necessità.  I servizi potrebbero aver bisogno di estrarre le informazioni o di aspettare l'output dal formato del messaggio aziendale comune.  Queste sono documentate nel modello del formato del messaggio comune del servizio.
Riutilizzo del modello del dominio

Nel concetto Concetto: Domain Design, è stata tracciata la nozione di modellamento del dominio, analoga alla nozione di un modello di analisi o di un modello di analisi business in rappresentazione dei concetti principali dal dominio business in un modo indipendente dalla tecnologia. E' chiaro che i messaggi utilizzati dai servizi sono tecnologicamente preparati (se non specifici della tecnologia come nel caso dello schema XML utilizzato per i servizi web) allo stesso modo lo schema del database utilizzato per memorizzare i dati del dominio è specifico della tecnologia all'interno del servizio. Infatti, è possibile considerare la relazione seguente.

Il diagramma viene descritto nel contenuto testuale.

Ciò dimostra la relazione tra il modello del dominio utilizzato per scoprire gli elementi chiave del dominio ed il modello del messaggio come la realizzazione del modello del dominio come un insieme di elementi passati a e restituiti dai servizi.

Il diagramma viene descritto nel contenuto testuale.

Il seguente è un modello tipico del componente Java in cui è possibile rilevare la separazione dell'interfaccia dalla classe e l'inclusione di funzioni "di accesso" per ottenere ed impostare il valore delle variabili di stato. Questo è un approccio molto comune, ma ha lo svantaggio che, se l'utente ed il componente si trovano in spazi di indirizzi diversi o su una macchina diversa, il costo della comunicazione di ogni chiamata è alto in termini di accesso allo stato intero di un qualsiasi componente.

Il diagramma viene descritto nel contenuto testuale.

Un altro problema è rappresentato dalle relazioni tra i componenti, la nozione che un account disponga di una serie di utenti è difficile da sviluppare in questo stile e di solito termina nella gestione degli elenchi degli identificativi utilizzati per recuperare oggetti singoli.

Nello sviluppo di un modello del servizio è possibile utilizzare un approccio di identificazione del servizio data-driven che conduce alla specifica di un servizio AccountMgr e di un servizio MeetingMgr. La prima specifica del servizio agisce come posizione centrale per la gestione di tutti gli account e di tutti i contatti. Infatti, il modello dati principale per le soluzioni CRM (Customer Relationship Management) è stato creato utilizzando questo ed altri servizi. Il secondo servizio è stato separato in quando può essere utilizzato dalle soluzioni CRM e da altre soluzioni per prenotare incontri e interfacciare le applicazioni Groupware dell'impresa.

L'esempio dal modello seguente, mostra le specifiche di servizio, si presume che i messaggi provengano dal modello del dominio precedente.

Il diagramma viene descritto nel contenuto testuale.

Conoscenza modelli di scambio del messaggio

Quando si pensa ai messaggi, vi è la tendenza naturale a considerarli semplicemente dei parametri nelle operazioni. Ciò avviene probabilmente perché la rappresentazione UML dei servizi utilizza operazioni con parametri e WSDL (Web Services Description Language) 1.1 utilizza un approccio simile. Tuttavia, quando si pensa in termini di Servizi e diSpecifiche di servizio, è più utile pensare ai messaggi come elementi riutilizzabili prodotti da o utilizzati/consumati da un'operazione del servizio. Nel gergo dei servizi, l'operazione diventa semplicemente uno scambio di messaggi, sebbene si tratti di uno scambio denominato su un servizio distinguibile da un altro scambio che potrebbe utilizzare gli stessi messaggi di input e output.

La nozione di modello di scambio messaggi è stata considerata interessante nel mondo degli standard dei servizi web, come parte dell'analisi dell'utilizzo dei servizi nello sviluppo degli standard per supportare le specifiche relative. Un modello di scambio messaggi fissa una combinazione particolare di messaggi prodotti, utilizzati o consumati tra due servizi (o tra un servizio ed un consumatore) e fornisce un vocabolario comune per consentire ai progettisti del servizio di descrivere le operazioni sulle specifiche di servizio.

Di seguito sono elencati modelli di scambio comuni che è possibile utilizzare nella definizione delle specifiche di servizio. Tali modelli vengono di solito trovati durante il modellamento di Collaborazioni del servizio.

Richiesta/Risposta sincrona: Si tratta in effetti di una chiamata del metodo tradizionale in cui l'utente invia un messaggio ad un servizio quindi si blocca in attesa di una risposta dal servizio.

Il diagramma viene descritto nel contenuto testuale.

Messaggio unidirezionale: In questo caso, l'utente invia semplicemente un messaggio al servizio, senza aspettare o prevedere una risposta. Questo modello può essere considerato come una chiamata di metodo asincrona senza alcun tipo di replica, il che significa che l'utente del servizio continua l'esecuzione dopo l'invio del messaggio, piuttosto che attendere che il servizio elabori il messaggio.

Il diagramma viene descritto nel contenuto testuale.

Notifica: In questo caso, il servizio è responsabile per il rinvio del messaggio all'utente (di solito un altro servizio). Per realizzare ciò l'utente deve essersi registrato in qualche modo con il servizio in modo che il servizio sappia dove inviare i messaggi di notifica.

Il diagramma viene descritto nel contenuto testuale.

Richiesta/Risposta asincrona: Questa è una combinazione del messaggio unidirezionale e della notifica. L'utente del servizio invia un messaggio, incluso un indirizzo a cui rispondere. Quando il servizio completa l'elaborazione, richiama il creatore. Il fatto che gli utenti del servizio inviino il primo messaggio in modalità asincrona richiede che venga tenuta traccia di tutte le richieste inviate così che le risposte, quando ricevute dal servizio, possano essere correlate alla richiesta originale.

Il diagramma viene descritto nel contenuto testuale.

Pubblicazione/Sottoscrizione: Di nuovo questa è una combinazione. Un utente del servizio registra le proprie opinioni in un "argomento" con un servizio di pubblicazione. Gli altri servizi o gli utenti del servizio pubblicano i messaggi (inviano i messaggi) al servizio di pubblicazione identificando l'argomento associato al messaggio. Se l'argomento corrisponde agli utenti precedentemente registrati, a questi ultimi viene notificato il nuovo messaggio. In questo caso è possibile unire molto debolmente i servizi partecipanti. E' solo necessario che ogni utente o editore conosca la posizione del servizio di pubblicazione ed è possibile aggiungere nuovi utenti alla soluzione senza alcuno sforzo significativo.

Il diagramma viene descritto nel contenuto testuale.

Gestione granularità messaggio

E' previsto che i servizi forniscano operazioni ad ampia granularità. Così, anche i messaggi di tali operazioni che fluiscono in entrata ed in uscita tenderanno ad essere a granularità ampia. Questo obiettivo è stato evidenziato originariamente presto nella distribuzione delle soluzioni dei servizi Web dove l'utilizzo di HTTP come trasporto, di SOAP come protocollo e di XML come formato wire ha condotto a risposte relativamente lente e a requisiti di larghezza di banda molto elevati. Ad esempio, considerare una richiesta della una quotazione di un titolo da un servizio. E' stata spesso dimostrata una quotazione di titolo semplice nei primi giorni dei servizi web. Il simbolo di teleborsa è composto da quattro caratteri e la risposta è un numero decimale. In un protocollo binario di stile RPC, è possibile prevedere che l'identificativo del messaggio aggiunga, diciamo 8 byte e in questo modo si potrebbe prevedere un posto qualsiasi nell'area di 8+4 per la richiesta e di 8+8 (per un decimale di alta precisione) nella risposta. Con HTTP/SOAP, è possibile prevedere qualcosa nella forma seguente:

Richiesta Risposta
   SOAPAction: "http://www.webservicex.net/Quote"
User-Agent: MyAgent 1.0
Content-Type: text/xml; charset=UTF-8
<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:tns="http://www.webservicex.net/">
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<soap:Body>
<tns:Quote>
<tns:Symbol>IBM</tns:Symbol>
</tns:Quote>
</soap:Body>
</soap:Envelope>
   HTTP/1.1 200 OK
X-Powered-By: ASP.NET
Connection: close
Content-Length: 522
X-AspNet-Version: 1.1.4322
Date: Mon, 21 Mar 2005 00:34:21 GMT
Content-Type : text/xml; charset=utf-8
Server : Microsoft-IIS/6.0Cache-Control: private, max-age=0
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Body>
<QuoteResponse xmlns="http://www.webservicex.net/">
<Quote><Last>89.28</Last>
</Quote>
</QuoteResponse>
</soap:Body>
</soap:Envelope>

Coloro che adottarono per primi la tecnologia dei servizi web giunsero a due conclusioni. Primo, i servizi sono stati ottimizzati per un numero piccolo di operazioni che forniscono i dati come documenti piuttosto che lo stile più completo dei modelli del componente tradizionali. Ciò ha il vantaggio di ammortizzare il sovraccarico dei protocolli attraverso un payload maggiore reale dei dati. Inoltre, tra i servizi in un'impresa, almeno tra i servizi all'interno della stessa soluzione, sono stati scelti binding di protocollo più piccoli e più semplici e HTTP/SOAP è stato riservato per situazioni in cui era necessario, come interfacciarsi a servizi al di fuori dell'impresa.

Questa nozione non è interamente nuova. Anche nel mondo dei componenti, il modello Value Object o J2EE Service Facade sono entrambi approcci per ridurre il numero di cicli (round-trip) di comunicazioni tra client e server. Entrambi utilizzano la nozione di inviare una copia completa dello stato del componente al client piuttosto che utilizzare le funzioni di accesso tradizionali.Per i servizi, di potrebbe considerare il fatto che i servizi in fase di sviluppo sono allineati in modo molto stretto ai modelli business, specialmente ai modelli del processo business. Così, i messaggi arrivano a riflettere documenti di business comuni nello stesso modo in cui gli insiemi di transazioni EDI (Electronic Data Interchange) rappresentano i documenti di business come ordini, fatture, avvisi di spedizione e così via.

Gestione prestazione scambio del messaggio

In generale, l'utilizzo di messaggi grandi è costoso per superare le prestazioni delle comunicazioni, sebbene in alcuni casi grandi messaggi di dati possono essere un problema. Ad esempio, nei messaggi SOAP precedenti, è stato illustrato come la dimensione del messaggio, utilizzando HTTP, SOAP e XML ha aumentato in modo significativo la dimensione dei dati. Questo è stato un problema relativo ai primi sistemi costruiti utilizzando le tecnologie dei servizi web. D'altra parte, questi problemi hanno consentito di imparare molte lezioni interessanti come il considerare le prestazioni in termini di prestazioni di codice, progettazione del messaggio e scelta di protocollo come un'attività di progettazione iniziale.

Un aspetto importante da considerare è che vengono spostati grandi blocchi di stato dal servizio all'utente oda servizio a servizio, questi messaggi rappresentano in realtà istantanee non aggiornate dello stato del servizi.Così, una delle considerazioni è di gestire esplicitamente questa "mancanza di aggiornamento" identificando il periodo in cui è possibile considerare i dati affidabili o "affittarlo" all'utente in modo che scada dopo un certo periodo di tempo. Per ulteriori informazioni, consultare la white paper Utilizzo di SOA (Service-Oriented Architecture) e CBD (Component-Based Development) per creare le applicazioni dei servizi web.

Un altro argomento che deve essere considerato è la memorizzazione nella cache del contenuto. Ma memorizzazione nella cache di solito un obiettivo che viene trattato come un'ottimizzazione delle prestazioni per le applicazioni, ma in una soluzione orientata al servizio, la natura distribuita e la comunicazione basata sul messaggio si riproduce nell'inserzione di cache tra gli utenti ed i servizi. Tali cache non sono cache del database tipiche utilizzate per l'ottimizzazione delle query, ma più come le cache utilizzate nei server web e nei proxy web. Infatti, nel caso in cui i servizi web utilizzino HTTP e SOAP, questi proxy potrebbero essere utilizzati come cache per servire le risposte del servizio in determinate situazioni.

Tuttavia i problemi, riguardo all'utilizzo di alcune cache, sono: il modo in cui la cache comprende le politiche utilizzate per servire il contenuto dalla cache e come un servizio può invalidare la cache. E' necessario che l'infrastruttura tecnica utilizzata per ospitare e gestire i servizi distribuiti fornisca capacità di memorizzazione nella cache. Un'area della politica del servizio che si prevede verrà sviluppata nel futuro è la fornitura di informazioni relative alla gestione della cache.

Ulteriori informazioni