Service Message Objects

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.

SMO-Modell

Das SMO-Modell ist ein Muster für die Verwendung von SDO-DataObjects zur Darstellung von Nachrichten. Das SMO enthält eine Darstellung der folgenden Datengruppen:
  • Business-Nutzdaten der Nachricht: Die Nutzdaten bestehen aus den Anwendungsdaten, die zwischen den Serviceendpunkten ausgetauscht werden.
  • Headerinformationen, die der Nachricht zugeordnet sind: Hierbei kann es sich beispielsweise um JMS-Header (JMS = Java Message Service) handeln, falls eine Nachricht mit der JMS-API übergeben wurde, oder um MQ-Header, wenn die Nachricht von WebSphere MQ stammt.
  • Kontextinformationen: Andere Daten als die Nutzdaten der Nachricht.

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.

Abbildung 1. Übersicht über SMO-Struktur. Header, Kontext und Hauptteil eines Objekts "ServiceMessageObject"Das Objekt "ServiceMessageObject" enthält context (Occurs 1), headers (Occurs 1) und body (Occurs 0..1). Der Kontext enthält correlation (Occurs 0..1), transient (Occurs 0..1), failInfo (Occurs 0..1) und primitiveContext (Occurs 0..1). Die Header enthalten SMOheader (Occurs 0..1), JMSheader (Occurs 0..1), SOAPheader (Occurs 0..unbounded), SOAPFaultInfo (Occurs 0..1), properties (Occurs 0..unbounded) und MQHeader (Occurs 0..1).

WebSphere Process Server und SMO

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.

Nachrichten können aus verschiedenen Quellen stammen. Daher muss das SMO in der Lage sein, unterschiedliche Arten von Nachrichtenheadern zu übertragen. WebSphere Process Server verarbeitet die folgenden Arten von Nachrichtenheadern:
  • Nachrichtenheader von Web-Services
  • Nachrichtenheader von SCA (Service Component Architecture)
  • Nachrichtenheader von JMS (Java Message Service)
  • Nachrichtenheader von WebSphere Adapter
  • Nachrichtenheader von WebSphere MQ

SMO-Laufzeit von WebSphere Process Server

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.

MQ-Headerdaten im SMO

Innerhalb der SMO-Struktur werden MQ-Headerinformationen im Verzeichnis /headers/MQHeader gespeichert. Dazu gehören folgende drei Elemente:
  • md - der MQ-Nachrichtendeskriptor der Nachricht (MQMD)
  • control - Formatierungsangaben für den Nachrichtentext
  • header - die (optionale) Wiederholung und Darstellung der Headerstrukturen in der WebSphere MQ-Nachricht
Das Element md enthält alle Felder aus der MQMD-Definition (siehe WebSphere MQ-Dokumentation) mit Ausnahme bestimmter Steuerungsfelder, die keine nützlichen Daten enthalten (z. B. StrucId und Version), und Nachrichtenformatfelder (Encoding, CodedCharSetId und Format).

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.

Ein Element header repräsentiert einen Nachrichtenheader, z. B. MQRFH2. Jeder Header entspricht einem der folgenden Typen:
  • Ein explizit modellierter Header im SMO (ein RFH der Version 1 oder 2).
  • Ein Header gemäß der MQ-Standardheaderstruktur, jedoch nicht explizit modelliert. Solche Header verfügen über MQ-Formatkennungen, die mit MQH beginnen. Sie werden im SMO durch unstrukturierte Binärdaten dargestellt.
  • Ein Header, der durch eine vom Benutzer angegebene MQ-Headerdatenbindung verarbeitet wird.

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).

Headersubelemente

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.

RFH-Header

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.

RFH2-Header

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.

Nicht modellierte WebSphere MQ-Header

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.

Typen für WebSphere MQ-Headerinformationen

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)