La figura mostra il formato logico e gli oggetti che compongono i messaggi nella serie di messaggi Video . In questa sede è possibile inoltre leggere una descrizione della figura.
La serie di messaggi Video è un componente del modello di messaggio di esempio Noleggio video . Dal modello di messaggio è possibile vedere come creare un modello di messaggio logico ed i relativi formati fisici associati. Nell'esempio Noleggio video, il modello di messaggio contiene dati relativi ad un cliente che prende a noleggio dei video. I dati contenuti nei messaggi includono:
Per ulteriori informazioni, leggere le sezione relativa ai modelli di messaggio nella documentazione di WebSphere Message Broker.
Gli elementi nel modello di messaggio si basano su tipi complessi e semplici. I riquadri in grigio rappresentano gli elementi basati su tipi complessi, mentre quelli in bianco rappresentano elementi basati su tipi semplici. Come si può vedere nella figura, il modello di messaggio contiene quattordici elementi basati su tipi semplici. I tipi semplici sono tipi di dati, come ad esempio string, integer e byte. Questi tipi semplici costituiscono le basi per gli elementi nei riquadri bianchi nella figura. Fatta eccezione per gli elementi ID e Magazine, che sono child diretti di Customer, tutti gli elementi semplici nel modello di messaggio sono child di elementi complessi o di un gruppo. Questi elementi complessi ed il gruppo sono child del tipo complesso Customer. Un tipo complesso è una definizione di struttura, che in effetti è una maschera per i dati contenuti al suo interno. Questi tipi complessi sono le basi degli elementi in grigio nella figura.
I tipi complessi possono avere un nome o essere anonimi. Nel modello di messaggio Video, Address e Borrowed hanno tipi complessi (locali) anonimi, mentre Name ha un tipo complesso (globale) con nome. Un tipo complesso con nome può essere utilizzato altrove, ad esempio in altri schemi, mentre un tipo complesso anonimo può essere utilizzato unicamente nella dichiarazione di appartenenza. L'utilizzo di tipi complessi con nome ha alcuni vantaggi evidenti. Utilizzando tipi complessi con nome è possibile, ad esempio, condividere informazioni con maggiore facilità all'interno dell'organizzazione. Tuttavia, vi possono essere casi in cui potrebbe essere preferibile l'utilizzo di tipi complessi anonimi, come ad esempio quando un tipo complesso non deve essere riutilizzato altrove.
L'oggetto denominato IdGroup è differente dagli altri elementi nel messaggio, in quanto si tratta di un gruppo. IdGroup aiuta a definire il modo in cui funzionano gli elementi PassportNo, DrivingLicenseNo e CreditCardNo. Quando un cliente apre un nuovo conto nel negozio di video, è necessario un solo tipo di identificativo per comprovarne l'identità. Creando un gruppo e definendo PassportNo, DrivingLicenseNo e CreditCardNo come membri di tale gruppo, è possibile configurare il modello di messaggio in modo da poter scegliere solo uno dei tre tipi di identificativo. Cioè, i tre elementi sono considerati come una scelta all'interno del tipo sovrastante. Se si includono gli elementi direttamente in un tipo, tutti e tre gli elementi potrebbero essere immessi contemporaneamente.
Per illustrare modi differenti di creare un modello di messaggio, l'oggetto denominato LastName viene creato come un attributo piuttosto che come un elemento. La creazione di un oggetto come attributo influenza il modo in cui è creato l'XML.
Per ulteriori informazioni, leggere le sezione relativa agli oggetti modello di messaggio nella documentazione di WebSphere Message Broker.
L'esempio Noleggio video dà anche una dimostrazione dell'utilizzo di spazi nomi nel modello di messaggio, nel messaggio di input XML e nell'ESQL utilizzato dal flusso di messaggi per fare riferimento a parti del messaggio. L'esempio Noleggio video contiene tre definizioni di messaggi. Il file di definizione dei messaggi per le informazioni di Customer non dispone di spazi nomi di destinazione. Tuttavia, i file di definizione dei messaggi per le informazioni di Address e Borrowed dispongono invece di spazi nomi di destinazione. I file di definizione dei messaggi per Address e Borrowed sono importati nel file di definizione dei messaggi per le informazioni di Customer. L'inserimento di Address e Borrowed in spazi nomi separati significa che questi elementi potrebbero essere facilmente utilizzati altrove per altri scopi aziendali.
Raggruppare le informazioni in modo logico significa che i dati raccolti, ad esempio, dal reparto assistenza clienti di una società possono poi essere facilmente condivisi da altri reparti, quali fatturazione o vendite. Non è necessario collocare gli oggetti che devono essere condivisi in spazi nomi differenti, ma vi sono casi in cui questo può facilitare la condivisione. Ad esempio, differenti sviluppatori che lavorano indipendentemente uno dall'altro, potrebbero creare oggetti con lo stesso nome, ma con significato diverso per l'attività aziendale. Collocando gli oggetti in spazi nomi differenti, le serie di oggetti possono essere sviluppate indipendentemente senza conflitti di nome.
Gli spazi nomi possono rivelarsi utili anche quando oggetti vengono sviluppati da un gruppo di sviluppatori. Ad esempio, un oggetto denominato Name potrebbe avere vari significati; potrebbe indicare il nome di un cliente oppure il nome di un prodotto. Un modo di evitare l'inconveniente potrebbe essere quello di creare oggetti con nomi, come ad esempio CustomerName e ProductName, ma questo potrebbe portare a nomi eccessivamente lunghi. Una soluzione alternativa consiste nel collocare tutti gli oggetti relativi alle informazioni sul cliente in uno spazio nomi e tutti gli oggetti relativi ai prodotti in un altro. In questo modo è possibile fare sì che lo spazio nomi a cui appartiene un oggetto ne determini il contesto.
Per ulteriori informazioni, leggere la sezione relativa agli spazi nomi nella documentazione di WebSphere Message Broker.
WebSphere Message Broker supporta diversi formati fisici che consentono di definire la rappresentazione fisica dei messaggi in dettaglio. Ad esempio, aggiungendo un CWF (custom wire format) alle proprie serie di messaggi è possibile elaborare i messaggi di input in questo formato, creare messaggi di output in questo formato e convertire messaggi da CWF in TDS o XML oppure da TDS o XML in CWF. I messaggi di input per i tre formati fisici sono descritti nelle seguenti sezioni.
Per ulteriori informazioni, leggere le sezione relativa ai formati fisici nella documentazione di WebSphere Message Broker.
Il messaggio Video relativo al cliente nel formato fisico CWF viene riportato sotto (si noti che potrebbe essere necessario scorrere verso destra per visualizzare l'intero messaggio):
Mr Fred Bloggs 12 Willow Avenue Salisbury CJ123456TT Fast Cars 23-05-20033,00Cut To The Chase 23-05-20033,751
Il CWF (custom wire format) non utilizza tag. Ad esempio, nel messaggio precedente, il primo campo (con il valore Mr) ha una lunghezza 3, ma non vi sono tag ad indicare dove finisce il campo. Ecco come sarebbe il messaggio Video relativo al cliente in CWF se i differenti campi fossero separati su righe differenti per una più facile lettura:
Mr Fred Bloggs 12 Willow Avenue Salisbury C J123456TT Fast Cars 23-05-2003 3,00 Cut To The Chase 23-05-2003 3,75 1
Il messaggio Video relativo al cliente viene reso in XML nel seguente modo:
<Customer xmlns:addr="http://www.ibm.com/AddressDetails" xmlns:brw="http://www.ibm.com/BorrowedDetails">
<Name LastName="Bloggs">
<Title>Mr</Title>
<FirstName>Fred</FirstName>
</Name>
<addr:Address>
<HouseNo>13</HouseNo>
<Street>Oak Street</Street>
<Town>Southampton</Town>
</addr:Address> <ID>P</ID>
<PassportNo>J123456TT</PassportNo>
<brw:Borrowed>
<VideoTitle>Fast Cars</VideoTitle>
<DueDate>23-05-2003T01:00:00</DueDate>
<Cost>3,50</Cost>
</brw:Borrowed>
<brw:Borrowed>
<VideoTitle>Cut To The Chase</VideoTitle>
<DueDate>23-05-2003T01:00:00</DueDate>
<Cost>3,00</Cost>
</brw:Borrowed>
<Magazine>0</Magazine>
</Customer>
Il messaggio Video relativo al cliente in formato TDS è riportato sotto (i dati sono stati suddivisi su righe separate per facilità di lettura):
{Name:[Title:Mr*FirstName:Fred*LastName:Bloggs] &Address:[HouseNo:12*Street:Willow Avenue*Town:Salisbury] &ID:P &PassportNo:J123456TT &Borrowed:[Fast Cars+23-05-2003+3,00] &Borrowed:[Cut To The Chase+23-05-2003+3,75] &Magazine:1}
L'oggetto IdGroup nel messaggio rappresenta una scelta di tipi di identificativo per i video che il cliente ha noleggiato. L'identificativo può essere un numero di passaporto, un numero di patente di guida o un numero di carta di credito. Il numero fornito nel messaggio di input corrisponde ad uno di tre possibili campi (scelta): PassportNo, DrivingLicenseNo o CreditCardNo. Con i messaggi XML e TDS, la scelta può essere risolta utilizzando tag e delimitatori nei messaggi stessi. Tuttavia, il messaggio CWF non contiene tag o delimitatori, quindi la scelta deve essere risolta utilizzando ESQL ed il valore del campo ID nel messaggio. Il campo ID contiene un singolo carattere che rappresenta il tipo di identificativo fornito dal cliente: P per PassportNo, D per DrivingLicenseNo o C per CreditCardNo.
Quando un messaggio CWF che contiene una scelta non risolta arriva ad un nodo di input, il programma di analisi MRM emette un messaggio di avvertenza (che può essere visualizzato se si tiene traccia del flusso di messaggi). L'elaborazione del messaggio continua, ma non può essere completata a meno che non ci sia un successivo nodo che contiene codice ESQL che risolve la scelta. Il codice ESQL in un nodo Compute offre un modo di fare riferimento all'albero logico del messaggio creato come risultato dell'analisi iniziale. Poiché il messaggio di input non era risolto, riferimenti all'albero restituiscono il valore null.
Per decidere a quale campo (PassportNo, DrivingLicenseNo o CreditCardNo) è assegnato il numero di identificativo, viene utilizzato un campo supplementare denominato ID. Il campo ID contiene un carattere per rappresentare il tipo di identificativo utilizzato: P, D o C. Nell'albero del messaggio, questo campo viene prima del campo di scelta IdGroup. Questo significa che il valore del campo ID può essere analizzato prima che vi sia un tentativo di risolvere la scelta. Con il campo ID analizzato, il valore può quindi essere utilizzato in istruzioni ESQL per risolvere la scelta.
Per capire come funziona la gestione della scelta, consultare Esecuzione dell'esempio Noleggio video e tentare di utilizzare l'attività di traccia facoltativa. Per scoprire come appare l'ESQL per l'esempio, consultare Creazione del flusso di messaggi.
Quando sono stati importati i file della serie di messaggi nel workbench, è possibile esaminare le proprietà degli elementi nel modello di messaggio Video. Quello che si vede nel workbench corrisponde alla figura della struttura del messaggio riportata sopra. Ad esempio, per esaminare l'elemento Name:
E' possibile visualizzare altri elementi in modo simile. Per informazioni più dettagliate su come viene creata la struttura del messaggio, consultare Creazione dell'esempio Noleggio video.