![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
Trace des communications du service ORB (Object Request Broker)
La trace des communications de l'ORB (Object Request Broker), généralement nommé CommTrace, contient la séquence de messages GIOP (General InterORB Protocol) envoyés et reçus par l'ORB lors de l'exécution de l'application.
Il peut s'avérer nécessaire de comprendre la série d'interactions de niveau inférieur client-serveur ou serveur-serveur lors de l'identification des incidents. La présente rubrique utilise des exemples de journaux pour présenter les entrées de trace et expliquer le contenu du journal et vous permet de comprendre la série d'interactions. Il traite uniquement les messages GIOP et ne présente pas en détail les autres informations de trace sur les limites des messages GIOP.
Emplacement
Lorsque la trace de l'ORB est
activée, ces informations sont placées dans le répertoire racine_serveur_app/profiles/nom_profil/logs/nom_serveur/trace.log.
Lorsque la trace de l'ORB est activée, ces informations
sont placées dans le répertoire racine_profil/logs/nom_serveur/trace.log.
Présentation du fichier de trace ORB
Les propriétés du fichier créées lorsque la fonction de trace de l'ORB est activée sont indiquées ci-après.
- accessible en lecture seule,
- Mises à jour par la fonction d'administration
- Utilisez ce fichier pour localiser et résoudre des incidents liés à l'ORB.
Interprétation du résultat
Les sections suivantes font référence à l'exemple de sortie de journal illustré plus loin dans cette rubrique.
- Identification des informations
- Le début d'un message GIOP est identifié par une ligne contenant SORTANT : ou ENTRANT :, selon que le message est envoyé ou reçu par le processus.Une série d'éléments fait suite à la ligne d'identification et elle est mise en forme pour plus de commodité, à l'aide des informations extraites du message brut qui identifie les points d'extrémité de cette interaction de message en particulier. Voir les lignes 3 à 13 des deux exemples. Les éléments mis en forme sont les suivants :
- Type de message GIOP (ligne 3)
- Date et heure d'enregistrement du message (ligne 4)
- Cette donnée est utilisée pour identifier l'unité d'exécution en cours lors de l'enregistrement du message, ainsi que d'autres informations spécifiques de l'unité d'exécution (ligne 5)
- Ports TCP/IP locaux et distants utilisés pour l'interaction (lignes 6 à 9)
- Version GIOP, ordre des octets, fragmentation ou non du message, taille du message (lignes 10 à 13)
- ID de demande, réponse prévue et statut de la réponse
- L'ID de demande fait suite au informations du message d'introduction et se présente sous la forme d'un entier généré par l'ORB. Il permet
d'identifier et d'associer chaque demande avec la réponse correspondante. Cette
association est nécessaire car les ORB peuvent recevoir des demandes de
plusieurs clients et doivent être capables d'associer chaque réponse à la
demande d'origine correspondante.
- Les lignes 15 à 17 de l'exemple de demande affichent l'ID de demande, suivi d'une indication pour le point d'extrémité de réception signalant qu'une réponse est attendue (CORBA permet d'envoyer des demandes unilatérales n'impliquant pas de réponse).
- La ligne 15 de l'Exemple d'entrée de journal - Réponse GIOP affiche l'ID de demande, tandis que la ligne 33 affiche le statut de la réponse reçue une fois que la demande d'envoi précédente est terminée.
- Clé d'objet
- Les lignes 18 à 20 de l'exemple de demande affichent la clé d'objet, la représentation interne utilisée par l'ORB pour identifier et localiser l'objet cible destiné à recevoir le message de demande. Les clés d'objet ne sont pas standardisées.
- Opération
- La ligne 21 de l'exemple de demande affiche le nom de l'opération lancée par l'objet cible au point dans le point d'extrémité de réception. Dans cet exemple, l'opération spécifique demandée est appelée _get_value.
- Informations sur le contexte de service
- Les contextes de service du message sont eu aussi mis en forme pour plus de commodité.
Chaque message GIOP peut contenir une séquence de contextes de service envoyés et reçus par chaque point d'extrémité. Les contextes de service, identifiés uniquement à l'aide d'un ID,
contiennent des données utilisées lors d'un échange particulier, comme
un échange d'informations de sécurité, de conversion de page de codes
et de version de l'ORB.
Le contenu de certains contextes de service
est standardisé et spécifié par OMG, tandis que d'autres contextes
de service sont propriétaires et spécifiés par chaque fournisseur. Les contextes de service propres à IBM sont identifiés par les ID
commençant par 0x4942.
Les lignes 22 à 41 de l'exemple de demande illustrent les entrées de contexte de service classiques. Il existe trois contextes de service dans le message de demande, comme le montre la ligne 22. L'ID, la longueur des données et les données brutes pour chaque contexte de service sont affichés plus bas. Les lignes 23 à 25 affichent le contexte propre à IBM, indiqué par l'ID 0x49424D12. Les lignes 26 à 41 affichent deux contextes de service standard, identifiés par l'ID 0x6 (ligne 26) et l'ID 0x1 (ligne 39).
Les lignes 16 à 32 de l'Exemple d'entrée de journal - Réponse GIOP illustrent deux contextes de service, un propre à IBM (ligne 17) et un standardisé (ligne 20).
Pour connaître la définition des contextes de service standardisés, reportez-vous à la spécification CORBA. Le contexte de service 0x1 (CORBA::IOP::CodeSets) permet de publier les jeux de code de caractères pris en charge par l'ORB pour négocier et déterminer le jeu de code utilisé pour transmettre des données de caractères. Le contexte de service 0x6 (CORBA::IOP::SendingContextRunTime) est utilisé par RMI-IIOP (Remote Method Invocation over the Internet Inter-ORB Protocol) pour fournir au point d'extrémité de réception l'IOR de l'objet SendingContextRuntime. Le contexte de service IBM 0x49424D12 permet de publier les informations de versions partenaires de l'ORB pour la prise en charge de l'interopérabilité entre les ORB d'envoi et de réception.
- Décalage de données
- La ligne 42 de l'exemple de demande affiche le décalage, par rapport au début du message GIOP, au niveau duquel se trouve le reste du corps du message de demande ou de réponse. Cette partie du message est spécifique à chaque opération et varie d'une opération à une autre. Par conséquent, il n'est pas mis en forme car le contenu spécifique est inconnu de l'ORB. Le décalage est imprimé comme aide pour localiser rapidement les données spécifiques à l'opération dans le cliché du message GIOP brut qui suit le décalage des données.
- Cliché de message GIOP brut
- Un cliché brut du message GIOP est imprimé au format hexadécimal, en commençant à la ligne 45 de l'exemple de demande et à la ligne 36 de l'Exemple d'entrée de journal - Réponse GIOP. Les messages de demande contiennent les paramètres requis pour l'opération donnée et les messages de réponse contiennent les paramètres de sortie comme requis par l'opération en question. Les données brutes ne sont pas toutes représentées dans les figures par souci de brièveté.
Exemple d'entrée de journal - Demande GIOP
1. SORTANT : 3. Message de demande 4. Date : 17 avril 2002 10:00:43 PM CDT 5. Informations de l'unité d'exécution : P=842115:O=1:CT 6. Port local : 1243 (0x4DB) 7. IP locale : jdoe.austin.ibm.com/192.168.1.101 8. Port distant : 1242 (0x4DA) 9. IP distante : jdoe.austin.ibm.com/192.168.1.101 10. Version GIOP : 1.2 11. Ordre des octets : big endian 12. Fragment à suivre : Non 13. Taille du message : 268 (0x10C) -- 15. ID de demande : 5 16. Indicateur de réponse : WITH_TARGET 17. Adresse cible : 0 18. Clé d'objet : longueur = 24 (0x18) 4B4D4249 00000010 BA4D6D34 000E0008 00000000 00000000 21. Opération : _get_value 22. Contexte de service : longueur = 3 (0x3) 23. ID de contexte : 1229081874 (0x49424D12) 24. Données de contexte : longueur = 8 (0x8) 00000000 13100003 26. ID de contexte : 6 (0x6) 27. Données de contexte : longueur = 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. ID de contexte : 1 (0x1) 40. Données de contexte : longueur = 12 (0xC) 00000000 00010001 00010100 42. Décalage de données : 118 45. 0000 : 47494F50 01020000 0000010C 00000005 GIOP............ 46. 0010 : 03000000 00000000 00000018 4B4D4249 ............KMBI 47. 0020: [remainder of message body deleted for brevity]
Exemple d'entrée de journal - Réponse GIOP
1. ENTRANT : 3. Message de réponse 4. Date : 17 avril 2002 10:00:47 PM CDT 5. Informations de l'unité d'exécution : RT=0:P=842115:O=1:com.ibm.rmi.transport.TCPTransportConnection 5a (ligne 5 segmentée pour la publication). remoteHost=192.168.1.101 remotePort=1242 localPort=1243 6. Port local : 1243 (0x4DB) 7. IP locale : jdoe.austin.ibm.com/192.168.1.101 8. Port distant : 1242 (0x4DA) 9. IP distante : jdoe.austin.ibm.com/192.168.1.101 10. Version GIOP : 1.2 11. Ordre des octets : big endian 12. Fragment à suivre : Non 13. Taille du message : 208 (0xD0) -- 15. ID de demande : 5 16. Contexte de service : longueur = 2 (0x2) 17. ID de contexte : 1229081874 (0x49424D12) 18. Données de contexte : longueur = 8 (0x8) 00000000 13100003 20. ID de contexte : 6 (0x6) 21. Données de contexte : longueur = 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. Statut de réponse : 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]