In der Abbildung sind das logische Format und die Objekte dargestellt, aus denen die Video-Nachrichtengruppe besteht . Außerdem finden Sie hier Erläuterungen zu dieser Abbildung.
Der Video-Nachrichtenfluss ist eine Komponente des Nachrichtenmodells für das Beispielprogramm 'Video Rental'. Anhand des Nachrichtenmodells wird der Aufbau eines logischen Nachrichtenmodells und dessen physischer Formate verdeutlicht. Im Beispielprogramm 'Video Rental' enthält das Nachrichtenmodell Daten zu den Kunden, die Videos ausleihen. Die Nachrichten enthalten unter anderem folgende Daten:
Weitere Informationen finden Sie in der WebSphere Message Broker-Dokumentation im Abschnitt über Nachrichtenmodelle.
Die Elemente im Nachrichtenmodell basieren auf komplexen und einfachen Typen. Die schraffierten Felder repräsentieren Elemente, die auf komplexen Typen basieren, während die nicht schraffierten Felder Elemente repräsentieren, die auf einfachen Typen basieren. Wie Sie anhand der Abbildung erkennen können, enthält das Nachrichtenmodell 14 Elemente, die auf einfachen Typen basieren. Bei den einfachen Typen handelt es sich um Datentypen (z. B. Zeichenfolge (STRING), Integer und Byte). Diese einfachen Typen bilden die Grundlage für die nicht schraffierten Elemente in der Abbildung. Mit Ausnahme der Elemente 'ID' und 'Magazine' (Magazin), die dem Element 'Customer' (Kunde) direkt untergeordnet sind, sind alle einfachen Elemente im Nachrichtenmodell komplexen Elementen oder einer Gruppe untergeordnet. Diese komplexen Element und die Gruppe sind wiederum untergeordnete Elemente des komplexen Typs 'Customer'. Ein komplexer Typ ist eine Strukturdefinition, die eigentlich eine Schablone für die darin enthaltenen Daten ist. Diese komplexen Typen bilden die Grundlage für die grau schraffierten Elemente in der Abbildung.
Komplexe Typen können entweder einen Namen haben oder anonym sein. Im Video-Nachrichtenmodell sind den Elementen 'Address' (Adresse) und 'Borrowed' (Ausgeliehen) anonyme (lokale) komplexe Typen zugeordnet, während 'Name' ein benannter (globaler) komplexer Typ zugeordnet ist. Ein benannter komplexer Typ kann an jeder beliebigen Stelle (z. B. in anderen Schemen) verwendet werden, während ein anonymer komplexer Typ nur in der Deklaration verwendet werden kann, in der er enthalten ist. Die Verwendung benannter komplexer Typen bietet einige deutliche Vorteile. Durch die Verwendung von benannten komplexen Typen kann beispielsweise die gemeinsame Nutzung von Informationen in Ihrer Organisation vereinfacht werden. Unter gewissen Umständen kann jedoch die Verwendung von anonymen komplexen Typen vorzuziehen sein, z. B. wenn ein komplexer Typ nicht an anderen Stellen verwendet werden muss.
Das Objekt 'IdGroup' unterscheidet sich von den anderen Elementen in der Nachricht, da es sich hierbei um eine Gruppe handelt. Mit 'IdGroup' kann die Verhaltensweise der Elemente 'PassportNo', 'DrivingLicenseNo' und 'CreditCardNo' definiert werden. Wenn ein Kunde in der Videothek ein neues Konto eröffnet, ist nur eine Ausweisart als Identitätsnachweis erforderlich. Durch die Erstellung einer Gruppe und die Definition von 'PassportNo', 'DrivingLicenseNo' und 'CreditCardNo' als Mitglieder dieser Gruppe können Sie das Nachrichtenmodell so konfigurieren, dass Sie nur eine dieser drei Ausweisarten auswählen können. Das heißt, die drei Elemente werden innerhalb des obigen Typs als eine Auswahl behandelt. Wenn Sie die Elemente direkt in einen Typ einfügen, könnten alle drei Elemente gleichzeitig eingegeben werden.
Um verschiedene Arten des Aufbaus eines Nachrichtenmodells zu veranschaulichen, wird das Objekt 'LastName' als Attribut (und nicht als Element) erstellt. Die Erstellung eines Objekts als Attribut wirkt sich auf den XML-Aufbau aus.
Weitere Informationen finden Sie in der WebSphere Message Broker-Dokumentation im Abschnitt über Nachrichtenmodellobjekte.
Das Beispielprogramm 'Video Rental' veranschaulicht außerdem die Verwendung von Namensbereichen im Nachrichtenmodell, in der XML-Eingabenachricht und im ESQL-Code, der vom Nachrichtenfluss für Verweise auf Teile der Nachricht verwendet wird. Das Beispielprogramm 'Video Rental' verfügt über drei Nachrichtendefinitionen. Der Nachrichtendefinitionsdatei für die Kundendaten (Customer) ist kein Zielnamensbereich zugeordnet. Die Nachrichtendefinitionsdateien für 'Address' und 'Borrowed' verfügen jedoch über Zielnamensbereiche. Diese Nachrichtendefinitionsdateien werden in die Nachrichtendefinitionsdatei für die Kundendaten importiert. Dadurch, dass 'Address' und 'Borrowed' in separate Namensbereiche gestellt werden, können diese Elemente für sonstige Geschäftszwecke auch an anderen Stellen verwendet werden.
Die logische Gruppierung von Informationen bedeutet, dass die Daten, die beispielsweise von der Abteilung 'Kundendienst' eines Unternehmens erfasst wurden, auf einfache Weise auch von anderen Abteilungen (z. B. der Rechnungsabteilung oder dem Vertrieb) genutzt werden können. Es ist nicht unbedingt erforderlich, Objekte, die gemeinsam benutzt werden sollen, in verschiedene Namensbereiche zu stellen. Unter gewissen Umständen kann dies jedoch zur gemeinsamen Nutzung hilfreich sein. Beispiel: Verschiedene Entwickler, die unabhängig voneinander arbeiten, erstellen Objekte mit denselben Namen, die jedoch jeweils im Geschäftsbereich eine andere Bedeutung haben. Werden die Objekte in verschiedene Namensbereiche gestellt, können sie separat ohne Namensüberschneidungen entwickelt werden.
Namensbereiche können auch dann sinnvoll sein, wenn Objekte von einer einzelnen Entwicklergruppe entwickelt werden. Das Objekt 'Name' könnte beispielsweise mehrere Bedeutungen haben: Es könnte für den Namen eines Kunden oder eines Produkts stehen. Dieses Problem könnte durch die Erstellung von Objekten wie 'Kundenname' und 'Produktname' vermieden werden, hätte jedoch unter Umständen sehr lange Namen zur Folge. Die Alternativlösung besteht darin, alle Objekte, die sich auf Kundeninformationen beziehen, in einen Namensbereich, und alle Objekte, die sich auf Produkte beziehen, in einen anderen Namensbereich zu stellen. Auf diese Weise kann der Namensbereich, zu dem ein Objekt gehört, den Kontext festlegen.
Weitere Informationen finden Sie in der WebSphere Message Broker-Dokumentation im Abschnitt über Namensbereich.
WebSphere Message Broker unterstützt mehrere physische Formate, mit denen Sie die physische Darstellung Ihrer Nachrichten genau definieren können. Wenn Sie Ihren Nachrichtengruppen beispielsweise ein CWF-Format (Custom Wire Format) hinzufügen, können Sie Eingabenachrichten in diesem Format verarbeiten, Ausgabenachrichten in diesem Format erstellen und Nachrichten von CWF in TDS oder XML bzw. von TDS oder XML in CWF umwandeln. In den folgenden Abschnitten werden die Eingabenachrichten für die drei physischen Format beschrieben.
Weitere Informationen finden Sie in der WebSphere Message Broker-Dokumentation im Abschnitt über physische Datenformate.
Im Folgenden wird die Video-Kundennachricht im physischen CWF-Format angezeigt (unter Umständen müssen Sie mit der Schiebeleiste ganz nach rechts blättern, um die Nachricht vollständig anzuzeigen):
Mr Fred Bloggs 12 Willow Avenue Salisbury CJ123456TT Fast Cars 2003-05-233.00Cut To The Chase 2003-05-233.751
Im CWF-Format werden keine Tags verwendet. In der obigen Nachricht hat beispielsweise das erste Feld (mit dem Wert 'Mr') die Länge 3, es ist jedoch kein Tag vorhanden, der angibt, an welcher Stelle das Feld endet. Die Video-Kundennachricht würde im CWF-Format folgendermaßen aussehen, wenn die verschiedenen Felder zur Verbesserung der Leserlichkeit jeweils in einer eigenen Zeile stünden:
Mr Fred Bloggs 12 Willow Avenue Salisbury C J123456TT Fast Cars 2003-05-23 3.00 Cut To The Chase 2003-05-23 3.75 1
Die Video-Kundennachricht wird wie folgt in XML wiedergegeben:
<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>2003-05-23T01:00:00</DueDate>
<Cost>3.50</Cost>
</brw:Borrowed>
<brw:Borrowed>
<VideoTitle>Cut To The Chase</VideoTitle>
<DueDate>2003-05-23T01:00:00</DueDate>
<Cost>3.00</Cost>
</brw:Borrowed>
<Magazine>0</Magazine>
</Customer>
Im Folgenden wird die Video-Kundennachricht im TDS-Format angezeigt (zur besseren Lesbarkeit wurden die Daten in separate Zeilen aufgeteilt):
{Name:[Title:Mr*FirstName:Fred*LastName:Bloggs] &Address:[HouseNo:12*Street:Willow Avenue*Town:Salisbury] &ID:P &PassportNo:J123456TT &Borrowed:[Fast Cars+2003-05-23+3.00] &Borrowed:[Cut To The Chase+2003-05-23+3.75] &Magazine:1}
Das Objekt 'IdGroup' in der Nachricht repräsentiert eine Auswahl an Ausweisarten für den Kunden, der Videos ausleiht. Als Ausweis kann eine Reisepass-, Führerschein- oder Kreditkartennummer verwendet werden. Die in der Eingabenachricht angegebene Nummer wird einem der drei möglichen (Auswahl)felder zugeordnet: PassportNo, DrivingLicenseNo oder CreditCardNo. Bei XML- und TDS-Nachrichten kann die Auswahl mit Hilfe von Tags und Begrenzern in den Nachrichten selbst aufgelöst werden. Da die CWF-Nachricht jedoch keine Tags oder Begrenzer enthält, muss die Auswahl unter Verwendung von ESQL und des Werts im Feld 'ID' in der Nachricht aufgelöst werden. Das Feld 'ID' enthält einen Buchstaben, der für die Art und Weise steht, wie sich der Kunde ausgewiesen hat: P für PassportNo, D für DrivingLicenseNo oder C für CreditCardNo.
Wenn beim Empfangsknoten eine CWF-Nachricht eingeht, die eine unaufgelöste Auswahl enthält, gibt der MRM-Parser eine Warnungsmeldung aus (diese kann angezeigt werden, wenn ein Traceknoten für den Nachrichtenfluss durchgeführt wird). Die Verarbeitung der Nachricht wird zwar fortgesetzt, kann jedoch nur vollständig abgeschlossen werden, wenn ein nachfolgender Knoten ESQL-Code enthält, mit dem die Auswahl aufgelöst wird. Über den ESQL-Code in einem Rechenknoten kann auf die logische Nachrichtenbaumstruktur verwiesen werden, die am Ende der ersten Syntaxanalyse erstellt wurde. Da die Eingabenachricht nicht aufgelöst wurde, geben die Verweise auf die Baumstruktur 'Null' zurück.
Um festzulegen, welchem Feld (PassportNo, DrivingLicenseNo oder CreditCardNo) die ID-Nummer zugeordnet wird, wird das zusätzliche Feld 'ID' verwendet. Das Feld 'ID' enthält ein Zeichen für die Darstellung der verwendeten Ausweisart: P, D oder C. In der Nachrichtenbaumstruktur steht dieses Feld vor dem Auswahlfeld 'IdGroup'. Dies bedeutet, dass der Wert des Felds 'ID' syntaktisch analysiert werden kann, bevor versucht wird, die Auswahl aufzulösen. Nach der Syntaxanalyse des Feldes 'ID' kann dieser Wert in ESQL-Anweisungen für die Auflösung der Auswahl verwendet werden.
Um die Funktionsweise der Auswahlbearbeitung zu verstehen, lesen Sie den Abschnitt Beispielprogramm 'Video Rental' ausführen und probieren Sie den optionalen Trace aus. Um zu erfahren, wie der ESQL-Code für das Beispielprogramm aussieht, lesen Sie den Abschnitt Nachrichtenfluss erstellen.
Wenn Sie die Nachrichtengruppendateien in die Workbench importiert haben, können Sie die Eigenschaften der Elemente im Video-Nachrichtenmodell testen. Die Anzeige in der Workbench entspricht der Abbildung der obigen Nachrichtenstruktur. Wenn Sie beispielsweise das Element 'Name' testen möchten, gehen Sie wie folgt vor:
Die anderen Elemente können auf ähnliche Weise angezeigt werden. Weitere Informationen zum Aufbau der Nachrichtenstruktur finden Sie im Abschnitt Beispielprogramm 'Video Rental' erstellen.