Bei Service Message Objects (SMOs) handelt es sich um erweiterte Servicedatenobjekte (Service Data Objects, SDOs). Ein SMO stellt eine abstrakte Ebene für die Verarbeitung und Bearbeitung von Nachrichten zur Verfügung, die zwischen Services ausgetauscht werden.
Der Zugriff auf alle diese Daten erfolgt als SDO-DataObjects. Es gibt eine Schemadeklaration, in der die Gesamtstruktur des SMO angegeben ist. Das Schema wird durch WebSphere Integration Developer generiert.
Alle SMOs weisen dieselbe Grundstruktur auf. Die Struktur besteht aus einem Stammdatenobjekt namens "ServiceMessageObject". Es enthält andere Datenobjekte für die Header-, Hauptteil- und Kontextdaten. Der SMO-Hauptteil enthält die Nutzdaten der Nachricht. Die Header enthalten Informationen, die aus einer bestimmten Import- oder Exportbindung stammen, beispielsweise einer JMS-Bindung.
Ein SMO stellt eine Schnittstelle für den Zugriff und die Änderung von Nachrichtenheadern und Nachrichtennutzdaten bereit. Es kann den logischen Inhalt vieler unterschiedlichen Nachrichtentypen darstellen.
WebSphere Process Server verarbeitet Nachrichten, während diese zwischen den Endpunkten einer Interaktion austauscht werden. In WebSphere Process Server werden Nachrichten durch Mediationsabläufe als SMO verarbeitet.
Um dynamisches Routing zu ermöglichen, können die Interaktionsendpunkte mit WSRR (Websphere Service Registry and Repository) abgefragt werden. Das Ergebnis der WSRR-Abfrage wird im SMO gespeichert.
WebSphere Process Server erstellt SMO-Objekte, die dann für die Mediationsabläufe verfügbar sind.
Bei der Erstellung von Mediationsabläufen gibt WebSphere Integration Developer den Typ des Nachrichtenhauptteils für jedes Terminal (Eingabe, Ausgabe oder Fehler) und optional den Typ der Kontextinformationen an. WebSphere Process Server verwendet diese Informationen, um Nachrichten in SMO-Objekte des angegebenen Typs zu konvertieren.
Das Element control enthält die Felder Encoding, CodedCharSetId und Format, die den Nachrichtentext beschreiben. Wenn die WebSphere MQ-Nachricht Nachrichtenheader enthält (z. B. MQRFH2), werden die Felder Encoding, CodedCharSetId und Format, die den Header beschreiben, im Element header übergeben.
Das Element header enthält die Felder Encoding, CodedCharSetId und Format, die den Header beschreiben. Insbesondere das Feld Format muss korrekt angegeben werden (z. B. MQHRF2 für einen MQRFH2-Header). Die Felder CodedCharSetId und Encoding sind wichtig für nicht transparente Daten. Bei der Darstellung als WebSphere MQ-Nachricht werden diese Formatinformationen in den vorherigen MQ-Header geschrieben (oder in MQMDmessage, wenn kein vorheriger Header vorhanden ist).
Das Element header enthält außerdem Subelemente (rfh und rfh2) für jeden modellierten Header, ein Subelement (opaque) für nicht modellierte MQ-Standardheader und ein Subelement (value) für vom Benutzer angegebene MQ-Header. Genau eines dieser vier Elemente muss definiert sein. Wenn in einem Headerelement mehr als eines dieser Subelemente definiert ist, führt dies zu einem Fehler. Im Subelement value wird die Struktur für die vom Benutzer angegebene Headerdatenbindung gespeichert, die drei anderen Elemente (rfh, rfh2 und opaque) werden in den nachfolgenden Abschnitten beschrieben.
Ein WebSphere MQ-RFH-Header enthält eine Zeichenfolge mit Name/Wert-Paaren, wobei jeder Name und jeder Wert aus einer einfachen Textzeichenfolge besteht. Dies wird im SMO als ein wiederholt vorkommendes Merkmalselement dargestellt, das einen Namen und einen Wert enthält.
Ein WebSphere MQ-RFH2-Header enthält null oder mehr benannte Ordner, die jeweils eine Sequenz aus Merkmalen und Grupppen enthalten. Ein Merkmal verfügt über einen Namen, einen optionalen Typ und einen Wert, die jeweils als Zeichenfolge angegeben werden). Eine Gruppe verfügt über einen Namen und enthält wiederum eine Sequenz aus Merkmalen und Gruppen. Die SMO-Darstellung eines RFH2-Headers enthält zudem ein Element NameValueCCSID, das die zum Codieren der Ordner in der WebSphere MQ-Nachricht verwendete CCSID festlegt.
Das Element opaque repräsentiert einen beliebigen WebSphere MQ-Header der Standardstruktur. Die in allen Headern dieses Typs enthaltenen Felder (StrucId, Version und Flags) werden als Elemente dargestellt. Ein weiteres Element namens data enthält den nicht modellierten Teil des Headers als Daten des Typs hexBinary. Bei Verwendung des Elements opaque ist in der Regel darauf zu achten, dass die dem Header zugeordneten korrekten Werte für Encoding und CodedCharSetId beibehalten werden, um Datenfehler zu vermeiden.
Die WebSphere MQ-Headerfelder werden unter Verwendung derselben Typengruppe definiert, die von WebSphere MQ selbst verwendet werden. MQLONG-Felder werden als int dargestellt, MQBYTEnn-Felder als Daten des Typs hexBinary mit Längenbegrenzung nn und MQCHARnn-Felder als Datentyp string mit Längenbegrenzung auf nn Zeichen.
(c) Copyright IBM Corporation 2005, 2006.
Dieses Information Center basiert auf Eclipse-Technologie. (http://www.eclipse.org)