[AIX Solaris HP-UX Linux Windows][IBM i]

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.

Remarque : Cette rubrique fait référence à un ou plusieurs des fichiers journaux de serveur d'applications. Il est recommandé de configurer le serveur de telle sorte qu'il utilise l'infrastructure de journalisation et de trace HPEL (High Performance Extensible Logging) à la place des fichiers SystemOut.log, SystemErr.log, trace.log et activity.log sur les systèmes distribués et IBM® i. Vous pouvez également utiliser HPEL conjointement avec vos fonctions de journalisation z/OS natives. Si vous utilisez l'infrastructure HPEL, vous pouvez accéder à toutes les informations de journalisation et de trace en utilisant l'outil de ligne de commande LogViewer à partir de votre répertoire bin de profil de serveur. Pour plus d'informations sur l'utilisation de HPEL, voir les informations sur l'utilisation de HPEL en vue du traitement des incidents liés aux applications.

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

[AIX Solaris HP-UX Linux Windows]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.

[IBM i]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]

Icône indiquant le type de rubrique Rubrique de référence



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rorb_traceo
Nom du fichier : rorb_traceo.html