![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
Trace für ORB-Kommunikation
Der Trace für ORB-Kommunikation (Object Request Broker), normalerweise als CommTrace bezeichnet, enthält die Folge der GIOP-Nachrichten (General InterORB Protocol), die bei der Ausführung von Anwendungen vom ORB gesendet und empfangen werden.
Sie sollten sich mit der Folge der Client-Server- bzw. Server-Server-Interaktionen, die auf der unteren Ebene stattfinden, vertraut machen. In diesem Artikel wird der Protokollinhalt anhand von Traceeinträgen aus Beispielprotokollen erläutert. Dies hilft, die Folge der Interaktionen zu verstehen. Im Mittelpunkt stehen die GIOP-Nachrichten. Weitere Traceinformationen, die sich auf die Grenzwerte der GIOP-Nachrichten beziehen, werden nicht ausführlich behandelt.
Position
Wenn der ORB-Trace aktiviert ist, werden diese Informationen
im Verzeichnis Stammverzeichnis_des_Anwendungsservers/profiles/Profilname/logs/Servername/trace.log abgelegt.
Wenn
die ORB-Traceerstellung aktiviert ist, werden diese Informationen im Verzeichnis
Profilstammverzeichnis/logs/Servername/trace.log abgelegt.
ORB-Tracedatei
Die Datei, die beim Aktivieren des ORB-Trace erstellt wird, hat folgende Eigenschaften:
- Schreibgeschützt (Read-only)
- Von Verwaltungsfunktion aktualisiert
- Dient zum Lokalisieren und Auflösen von ORB-Fehlern.
Interpretation der Ausgabe
Die folgenden Abschnitte beziehen sich auf eine Beispielprotokollausgabe, die unten in diesem Abschnitt aufgeführt ist.
- Informationen zur Identifizierung
- Eine GIOP-Nachricht beginnt entweder mit der Zeichenfolge "Abgehend:" bzw.
"Eingehend:", je nachdem, ob die Nachricht vom Prozess, für den das Tracing ausgeführt wird,
gesendet oder empfangen wird. Die folgende Identifikationszeile ist eine Serie von Elementen, die zu Ihrer Unterstützung formatiert wurden. Die Zeile enthält Daten, die aus der Rohnachricht extrahiert wurden und die Endpunkte dieser Nachrichteninteraktion angeben. Siehe Zeilen 3-13 in beiden Beispielen. Die formatierten Elemente sind folgende:
- GIOP-Nachrichtentyp (Zeile 3)
- Datum und Uhrzeit der Nachrichtenaufzeichnung (Zeile 4)
- Informationen zur Identifizierung des Thread, der ausgeführt wird, wenn die Nachricht aufgezeichnet wird, und andere threadspezifische Informationen (Zeile 5)
- Lokale und ferne TCP/IP-Ports, die für die Interaktion verwendet werden (Zeilen 6 bis 9)
- GIOP-Version, Byteanordnung, ggf. Hinweis, dass die Nachricht nicht vollständig ist, Nachrichtengröße (Zeilen 10 bis 13)
- Anforderungs-ID, erwartete Antwort und Antwortstatus
- Nach den
einführenden Informationen zur Nachricht folgt die Anforderungs-ID. Die
Anforderungs-ID ist ein Integer, das vom ORB generiert wird. Sie wird verwendet,
um die einzelnen Anforderungen den entsprechenden Antworten zuzuordnen. Diese Zuordnung
ist
erforderlich, weil der ORB Anforderungen von mehreren Clients empfangen kann und in der
Lage sein muss, jede Antwort der entsprechenden Anforderung zuzuordnen.
- In den Zeilen 15-17 im Anforderungsbeispiel wird Folgendes angezeigt: die Anforderungs-ID und ein Hinweis an den Empfangsendpunkt, dass eine Antwort erwartet wird (CORBA lässt das Senden von unidirektionalen Anforderungen, bei denen keine Antwort erwartet wird, zu).
- In Zeile 15 im Beispielprotokolleintrag - GIOP-Antwort wird die Anforderungs-ID, in Zeile 33 der nach Bearbeitung der zuvor gesendeten Anforderung empfangene Antwortstatus angezeigt.
- Objektschlüssel
- In den Zeilen 18-20 des Anforderungsbeispiels wird der Objektschlüssel angezeigt. Der Objektschlüssel ist die interne Darstellung, die der ORB bei der Ausführung verwendet, um das für den Empfang der Anforderungsnachricht vorgesehene Zielobjekt anzugeben und zu lokalisieren. Objektschlüssel sind nicht standardisiert.
- Operation
- In Zeile 21 des Anforderungsbeispiels wird der Name der Operation, die am Empfangsendpunkt vom Zielobjekt ausgeführt werden soll, angezeigt. In diesem Beispiel heißt die spezifische angeforderte Operation _get_value.
- Informationen zu Servicekontexten
- Die Servicekontexte in der Nachricht
sind ebenfalls zu Ihrer Unterstützung formatiert.
Jede GIOP-Nachricht kann eine Folge von Servicekontexten, die von den einzelnen Endpunkten
gesendet bzw. empfangen wurden, enthalten. Servicekontexte, die mit einer ID eindeutig
angegeben werden, enthalten Daten, die in der spezifischen Interaktion angegeben werden,
wie z. B. Informationen zu Sicherheit, Konvertierung von codierten Zeichensätzen und
ORB-Version. Der Inhalt einiger Servicekontexte wird von OMG standardisiert und
angegeben, während andere Servicekontexte proprietär sind und von jedem
Hersteller angegeben werden. IBM-spezifische Servicekontexte werden mit IDs
angegeben, die mit 0x4942 beginnen.
Die Zeilen 22-41 des Anforderungsbeispiels enthalten typische Servicekontexteinträge. Es gibt drei Servicekontexte in der Anforderungsnachricht, wie in Zeile 22 angezeigt. Die ID, die Datenlänge und Rohdaten für jeden Servicekontext werden anschließend ausgegeben. In den Zeilen 23-25 wird ein proprietärer IBM Kontext angezeigt, wie durch die ID 0x49424D12 angegeben. In den Zeilen 26-41 werden zwei Standardservicekontexte angezeigt, die durch die IDs 0x6 (Zeile 26) und 0x1 (Zeile 39) angegeben werden.
Die Zeilen 16-32 im Beispielprotokolleintrag - GIOP-Antwort zeigen zwei Servicekontexte, einen IBM proprietären (Zeile 17) und einen standardisierten (Zeile 20).
Die CORBA-Spezifikation enthält die Definition der standardisierten Kontexte. Mit dem Servicekontext 0x1 (CORBA::IOP::CodeSets) werden die vom ORB unterstützten codierten Zeichensätze veröffentlicht, um den zur Übertragung von Zeichendaten verwendeten codierten Zeichensatz zu vereinbaren und festzulegen. Der Servicekontext 0x6 (CORBA::IOP::SendingContextRunTime) wird vom RMI-IIOP verwendet, um dem Empfangsendpunkt die IOR für das SendingContextRuntime-Objekt bereitzustellen. Mit dem IBM Servicekontext 0x49424D12 werden ORB-PartnerVersion-Informationen veröffentlicht, um die Interoperabilität der verschiedenen Releases bei der Kommunikation zwischen sendenden und empfangenden ORBs zu gewährleisten.
- Relative Datenadresse
- Zeile 42 des Anforderungsbeispiels zeigt die Datenadresse relativ zum Anfang der GIOP-Nachricht, wo der verbleibende Hauptteil der Anforderungs- oder Antwortnachricht sich befindet. Dieser Abschnitt der Nachricht ist für jede Operation spezifisch und variiert. Daher ist dieser Wert nicht formatiert, da der ORB den spezifischen Inhalt nicht kennt. Die relative Adresse wird ausgegeben, um die operationsspezifischen Daten im Speicherauszug der GIOP-Rohnachricht, der auf die relative Datenadresse folgt, schnell lokalisieren zu können.
- Speicherauszug für GIOP-Rohnachricht
- Ein Speicherauszug der vollständigen GIOP-Rohnachricht wird im Hexadezimalformat ausgegeben und beginnt im Anforderungsbeispiel in Zeile 45 und im Beispielprotokolleintrag - GIOP-Antwort in Zeile 36. Anforderungsnachrichten enthalten die Parameter, die von der jeweiligen Operation angefordert werden. Antwortnachrichten enthalten die Rückgabewerte und den Inhalt der Ausgabeparameter, wie von der jeweiligen Operation angefordert. In den folgenden Abbildungen wurden aus Gründen der Übersichtlichkeit nicht alle Rohdaten aufgeführt.
Beispiel für Protokolleintrag - GIOP-Anforderung
1. OUT GOING: 3. Request Message 4. Date: April 17, 2002 10:00:43 PM CDT 5. Thread Info: P=842115:O=1:CT 6. Local Port: 1243 (0x4DB) 7. Local IP: jdoe.austin.ibm.com/192.168.1.101 8. Remote Port: 1242 (0x4DA) 9. Remote IP: jdoe.austin.ibm.com/192.168.1.101 10. GIOP Version: 1.2 11. Byte order: big endian 12. Fragment to follow: No 13. Message size: 268 (0x10C) -- 15. Request ID: 5 16. Response Flag: WITH_TARGET 17. Target Address: 0 18. Object Key: length = 24 (0x18) 4B4D4249 00000010 BA4D6D34 000E0008 00000000 00000000 21. Operation: _get_value 22. Service Context: length = 3 (0x3) 23. Context ID: 1229081874 (0x49424D12) 24. Context data: length = 8 (0x8) 00000000 13100003 26. Context ID: 6 (0x6) 27. Context data: length = 164 (0xA4) 00000000 00000028 49444C3A 6F6D672E 6F72672F 53656E64 696E6743 6F6E7465 78742F43 6F646542 6173653A 312E3000 00000001 00000000 00000068 00010200 0000000E 3139322E 3136382E 312E3130 310004DC 00000018 4B4D4249 00000010 BA4D6D69 000E0008 00000000 00000000 00000002 00000001 00000018 00000000 00010001 00000001 00010020 00010100 00000000 49424D0A 00000008 00000000 13100003 39. Context ID: 1 (0x1) 40. Context data: length = 12 (0xC) 00000000 00010001 00010100 42. Data Offset: 118 45. 0000: 47494F50 01020000 0000010C 00000005 GIOP............ 46. 0010: 03000000 00000000 00000018 4B4D4249 ............KMBI 47. 0020: [remainder of message body deleted for brevity]
Sample Log Entry - GIOP Reply
1. IN COMING: 3. Reply Message 4. Date: April 17, 2002 10:00:47 PM CDT 5. Thread Info: RT=0:P=842115:O=1:com.ibm.rmi.transport.TCPTransportConnection 5a (Zeile 5 ist zur besseren Lesbarkeit umbgebrochen.) remoteHost=192.168.1.101 remotePort=1242 localPort=1243 6. Local Port: 1243 (0x4DB) 7. Local IP: jdoe.austin.ibm.com/192.168.1.101 8. Remote Port: 1242 (0x4DA) 9. Remote IP: jdoe.austin.ibm.com/192.168.1.101 10. GIOP Version: 1.2 11. Byte order: big endian 12. Fragment to follow: No 13. Message size: 208 (0xD0) -- 15. Request ID: 5 16. Service Context: length = 2 (0x2) 17. Context ID: 1229081874 (0x49424D12) 18. Context data: length = 8 (0x8) 00000000 13100003 20. Context ID: 6 (0x6) 21. Context data: length = 164 (0xA4) 00000000 00000028 49444C3A 6F6D672E 6F72672F 53656E64 696E6743 6F6E7465 78742F43 6F646542 6173653A 312E3000 00000001 00000000 00000068 00010200 0000000E 3139322E 3136382E 312E3130 310004DA 00000018 4B4D4249 00000010 BA4D6D34 000E0008 00000001 00000000 00000002 00000001 00000018 00000000 00010001 00000001 00010020 00010100 00000000 49424D0A 00000008 00000000 13100003 33. Reply Status: NO_EXCEPTION 36. 0000: 47494F50 01020001 000000D0 00000005 GIOP............ 37. 0010: 00000000 00000002 49424D12 00000008 ........IBM..... 38. 0020: [remainder of message body deleted for brevity]