DE19936118A1 - Computer software based errors search method for distributed applications, involves transferring protocols in generic format and then separating the information into essential and administrative data - Google Patents

Abstract

Search for errors, particularly in distributed applications based on common object request broker architecture (COBRA) and so-called middle-ware i.e. software enabling communication between two different programs, requires initially transferring the protocol information in a generic format prior to breaking down the information into administrative- and useful- data and then filing the results in a data store, ready for presentation in a user interface.

Description

The present invention describes a method for Troubleshoot distributed applications, especially for CORBA based applications.

CORBA (Common Object Request Broker Architecture) became 1992 presented and allowed by the OMG (Open Management Group) the creation of components (objects) that are independent of your implementation language and platform communicate. In addition, a number of services are available Provided the use in practice only make interesting. Above all, this includes the points Security, transactions and persistence.

Object Management Architecture (OMA)

The OMG object model and the OMG form the basis Reference model of the Object Management Architecture Guide (see [1]). The OMG object model describes the common one Semantics of objects in an OMG-compliant system deal with each other. This happens in an abstract way independent of a special technology and Implementation (e.g. a special programming language). The OMG reference model describes the object management Architecture (OMA). The intention is one technology-independent identification and characterization of components, interfaces and protocols define.  

Those described in the object and reference models abstract foundations and architectural elements are supposed to be through the industry is technologically concretized. The OMG so don't implement any of their suggestions (which are in the form of Specifications are issued) itself, but provides only specifications on. Any specification that is not implemented by a software company within one year is deleted and may need to be reconsidered become.

CORBA as part of the OMA

The Common Object Request Broker Architecture (CORBA) and their associated object model is technological Specification of the OMA and its associated Object model, and thus provides a direct template for an implementation by the industry.

Status with object-oriented middleware Middleware

The concept of middleware was introduced to reduce the compatibility problems and the complexity of network programming. Middleware is software that enables two different programs, client and server, on two different computers to communicate with each other without having to worry about the details of (network) communication. Fig. 1 shows the rough architecture for such a call.

The Object Request Broker is an extensive extension of the classic middleware concept. On the one hand, it enables the use of distributed objects (usually also  Objects of different languages) and connects the Advantages of object oriented software development and simple programming of network applications Middleware. It also becomes a more or less extensive collection of services offered to the Simplify handling of distributed software. To the For example, it is no longer necessary to use an ORB Address of the computer on which the server object is stored to know. Rather, the address of an ORB is sufficient know who then calls to the appropriate ORBs forwards.

Thus, the developer can focus on the much better focus actual logic of its application since it is from the recurring problems of Network programming is largely exempt.

Current problems with object middleware technology

With ORBs it is possible to quickly create complex, reusable and easily expandable Build applications, however, solves the object-oriented Middleware, of course, does not solve all of the problems Software development.

Abstract programming interface

Free from the basic problems of distributed development Applications, the developer sees himself quickly with new ones Faced difficulties. Since the new API (Application Programmers interface) is so simple and abstract, the programmer also loses direct control over the real thing. It can no longer be traced can be what with a few lines of source code  is generated or which complex network operations be performed. It is no longer the case with the implementer possible between network, middleware or application to distinguish errors even if he has the line in the Knows source code with which an error occurs. The entire Spectrum often becomes multiple with a single method call and used distributed without the programmer must know. Of course, you can still use the known problems, such as hardware or operating system errors occur.

Troubleshooting

If a distributed application crashes, it cannot be easy understand when and where the real mistake unless the problem is just accidental occurred on the local machine. Otherwise, the Error in the request to the server during processing on the server, or when the server responds, without this being easy to check. This will still be complicated by the fact that a distributed Usually not only applied to two systems limited, but the original server further Makes requests to other servers to fulfill its orders to be able to. As I said, it is now possible, very much quickly complex and easily expandable applications create, but troubleshooting was significantly more difficult which requires correspondingly powerful tools.

Lack of base problem

Troubleshooting is very difficult for developers the middleware itself. This refers to the fact that the different implementations of the CORBA- Standards partly due to the open concept  differentiate. This is due to the fact that the different manufacturers have only implemented the parts that seemed sensible to them, or quickly realizable, or new, own ideas were brought in. Consequently incompatibilities always occur, if not only the simplest ORB functions can be used. Since on the on the other hand, the demand for CORBA on almost everyone Platforms from all sides but is very large also a very big competition. As a consequence, that there are hardly any corresponding tools available on the market, that can be used in general. There is instead almost only own versions, each for one manufacturer-specific ORB can be used. This unfortunately also includes reasonable debuggers.

State of the art Debugging alternatives for distributed applications

There are two main ways to debug distributed applications:
The version that is more comfortable for the user, but also much more complex, is the classic "real-time" debugging tool. The simpler, but relatively limited option is to record information while the application is running and to evaluate it later (offline).

Real-time debugging tools (remote debugger)

The variant of real-time debugging usually offers that Possibility to process the code line by line while doing so monitor the states of various variables. Often additional breakpoints can be set and more Options are used that work with the code  simplify considerably. The difficulty now is that the code is not just on your own as usual Computer is running, but on various Platforms and in various places in different languages. So a corresponding tool support remote debugging and debugging Request information from the currently active server. Each server must have the debugging Information compiled code and this Can also deliver information. So this is one Tool itself a very elaborate distributed application that must use an infrastructure that is currently being developed shall be. A corresponding application of from IBM, a remote debugger, implemented but due to a lack of a base still in a very early stage and the developers of the middleware is not yet fully available. This tool is rather as an integral part of the later middleware Product provided to the user development work the distributed applications as pleasant as possible shape.

Offline debugging

The second variant of debugging relates, as I said, on the evaluation of recorded information. This Information is usually collected with the help of Monitors gained or from the applications themselves generated.

Monitoring

We speak of monitoring when "from outside" Information is queried or obtained and for which later evaluation can be filed. Hardware and  Distinguish between software monitors.

Hardware monitors

Hardware monitors are additional devices that only the To record information. It can are register values or signal states of a line act. The advantage is that these devices only one exert very little influence on the system and the data obtained are therefore very realistic.

The disadvantage is the often very high cost of these devices, the low flexibility and the sometimes high effort of Installation in the system.

Software monitors

Software monitors are a piece of software that data or Record system states. Since no additional Equipment is necessary, the advantage is the high Flexibility, the very low cost and the relative little effort of this solution. The problem is, however high influence of an additional task on the system, because this falsifies the entire runtime behavior. Is this important or even crucial for behavior of the system, the results are usually not useful. In addition, you cannot use arbitrary values can be obtained via software monitors, e.g. B. it is not possible to record signal states of a line.

We speak of "real" software monitors when a Program runs in addition to "normal" software, just to record the desired data.

Debugging about application-generated information  Another variant of troubleshooting via software is the extension of the actual application with the Functionality of information acquisition. The idea is that Code of the application extended by instructions that any output desired data (on disk or console) to Example using cout (C ++) or printing (Java). So there is Program during execution the corresponding values e.g. B. in a file (Job Log). In principle, it is also is a kind of software monitor, the above applies here too mentioned properties. However, this version ends the acquisition of information the output of information with the crash of the program. So it can be relatively easy to what point the program is determined was still running at all (whether really error-free, can in turn not so easily said). Now in this Further editions to be inserted until the actual line of the crash is found. This can however, under certain circumstances a relatively high effort mean.

Existing software

Extensive research on the Internet has only one brought only result that goes roughly in this direction. It is a Linux application that is based on a TCP analyzer is set up. This tool monitors the data that can be exchanged via the network and can IIOP Recognize packages. If a package is discovered, the type of Output message and the request ID on the console. However, this only superficial information is sufficient far from the actual program flow to be able to understand.

Object of the invention

It is therefore an object of the present invention automated tool or automated process for user friendly error identification and Provide error representation for distributed applications, which is also applicable after the application has ended.

This object is achieved by the features in claims 1, 24 and 28 solved. Further advantageous embodiments are in the subordinate claims.

The inventive tool is a program to visualize the communication of distributed applications, especially CORBA applications. The Tool uses traces or dumps, especially the standardized Internet Inter ORB Protocols (IIOP), via that CORBA applications exchange their information.

This communication also includes all important data transmitted, which can be used for troubleshooting. This also refers to error messages or missing or wrong messages.

The tool is independent thanks to the configurable pre-filter from formatting the message packets to the trace Files or dumps. In addition, components whose Structure is not known, simply as formatted hex code output with ASCII and EBCDIC interpretation.

This allows z. B. the traces of any ORBs, any Manufacturer read and formatted. this applies even if ORBs have a GIOP implementation other than the IIOP should communicate, of course then the not protocol-specific components of the IOR can be interpreted. Thus became a universal usable tool created that z. B. also for distributed Java applications can be used since version 2.0  of the JDK the communication in the remote method invocation (RMI) via IIOP.

All communication becomes independent of the extraction the traces reconstructed and most of the components can then be visualized legibly. To use the Tools do not have to be put into great effort, since only the traces must somehow be stored in a file. Otherwise the tool could also be used without special installation, e.g. B. be started from CD.

Because this approach makes it completely independent of the system no major changes are necessary be made. While classic debugging recompile the code or even change the code configuration was necessary Output of the traces can be adjusted, e.g. B. by changing of the trace level or setting the corresponding one Environment variables. This makes the FFIT ideal as a simple one Debug help for ORB and application development can be used as almost all interesting information from establishing a connection to the physical location of an object Implementation can be transferred via this protocol and can be viewed very easily.

But due to the high degree of independence they are Possible uses of the tool not only in this area limited. Especially in the administration of distributed Systems, it can be very useful. Will one distributed application installed in a new environment, this often requires a lot of configuration regarding the infrastructure used (such as system access rights, database access, transaction management, Etc). As a rule, this means that even with stable, extensively tested applications starting difficulties  because the environment has not yet been configured correctly (e.g. if an object does not have access to the database may). To find out where the problem is now can also use the IIOP Traces again be used because e.g. B. also security data be transmitted. So the administrator can use the tool relatively easy to identify the problem area without long in System looking around, or even having to change the application. It is not even necessary to have the detailed structure know the application, because the IIOP in an emergency everyone provides the necessary information (e.g. which object needs which access rights).

In a preferred embodiment, this supports inventive tool the job logs and thus the traces of all ORBs of all platforms or at least the Java and C ++ Traces of the Component Broker ORBs (IBM) of the platforms Microsoft Windows NT and IBM OS / 390. It means that both the type of formatting of the different variants is taken into account as well as the different characters Coding of the platforms. For example, under NT in usually the ASCII (American National Standard Code for Information Interchange) standard used, however under OS / 390 also the EBCDIC (Extended Binary Coded Decimal Interchange Code) encoding.

In a preferred embodiment, the method is for intended to be used under NT since the OS / 390 job logs without more can be downloaded on this platform.

But since the procedure can be implemented in Java, use directly under OS / 390 is also conceivable.

Because the speed of offline debugging at Implementation of the present invention is not critical is, the slower Java performance can easily in Purchase. The application can then do this directly to be used on the S / 390, or to others  Departments or developers who are responsible for Example in the AIX environment (UNIX derivative from IBM) work.

The present invention is based on a preferred one Exemplary embodiment in connection with figures explained where

Fig. 1 shows the structure of a middleware

Fig. 2 shows the inventive architecture of the IIOP trace formatter tool

Fig. 3, the IIOP Trace formatting different ORBs

Figure 4 shows a simple GIOP package

Fig. 5 of the Hex code of the GIOP package of FIG. 4

Fig. 6 is a table: GIOP message parsed

Fig. 7 shows the Java package of tools

Fig. 8 shows different packet formatting

Figure 9 shows the TracePreFilter class

Fig. 10 shows the hierarchical parsing of Codes Hex

Fig. 11 shows the hierarchical data storage of the parser

Figure 12 shows the main window of the inventive tool

Fig. 13 shows the dialog box for determining type

Fig. 14 shows simple data types in the text field

Figure 15 shows the Trace Formatter class

FIG. 16 is a code sample usage of the dialog shows

FIG. 2, the high-level architecture shows the tool. The inventive tool therefore consists of three major components:

• 1. a pre-filter for the job log
• 2. the parser
• 3. a user interface with additional filter or Selection function.

Prefilter

The first filter level is required because the IIOP traces are formatted differently in the job logs of different ORBs (see Fig. 3) and each contain a lot of additional information in text format (see Fig. 4). The corresponding job log must be available as a separate file. This filter then removes "all superfluous data" and stores the "clean" hex code obtained for the actual parser so that it can work without unnecessary difficulties (see FIG. 5). This hex code is then strictly GIOP (General Inter ORB Protocol) traces, since the IIOP represents the practical implementation of the GIOP and the GIOP data is actually only packed in TCP / IP packets. It would therefore be conceivable to prepare and evaluate traces of other implementations of the GIOP (which do not yet exist) with this tool.

Trace parser

The second stage, the actual parser, tries to break down the hex code into the individual components and interpret it as much as possible. For this he uses the table shown in FIG. 6. Since not all the necessary information can be obtained from the pure hex code, a compromise which is as satisfactory as possible must be made by the present invention.

User interface (user interface)

Because both the job logs and the IIOP packages sometimes can be very extensive, only the ones you want  Information is output (e.g. security, or transaction data) to provide some clarity to ensure. It is optional how this data be represented exactly. On the one hand, it would be conceivable that Store the result in a file, or a GUI (Graphical User Interface) to implement what the Would greatly increase usability.

The pre-filter reads the hex code from the table and transfers it to the parser. This recognizes the package components and their meaning, as shown in Fig. 6. These results are filtered according to the user request and displayed using a graphical user interface.

In the following a concrete implementation of the inventive tools (FITT tool) for interpretation and Preparation of GIOP / IIOP messages shown.

The FITT Tool is a graphic tool for interpretation and preparation of GIOP / IIOP messages. These must the FITT in a file in any format available.

The FITT structure

The structure of the FFIT tool is shown in Fig. 2. In the first stage, the tool filters the pure hex code of the message packets from the trace file (file that contains the log data of messages). The next stage consists of gradually breaking down the messages into their components and storing the information obtained. Certain components of the GIOP / IIOP packages cannot be parsed from the pure hex code, since the associated structures or types (administrative data) are not known. It is therefore not possible to say how many parameters were passed. In the last stage, the packages are listed under a graphical user interface and can then be viewed in detail, depending on the user request.

Tool flow

After starting the FFIT tool, the graphical Interface, with the prompt for a file (with GIOP / IIOP Traces) to open. Was a file on the selected the appropriate dialog, the tool tries the Filters for the well known Component Broker formatting for Use trace files. Could not result in a valid GIOP Package are recognized, the user is prompted to specify an appropriate filter for the trace file. Now the file is once regarding the contained packages checked and the respective message type with its ID displayed. Now the user wants the individual He can see the components of a package via the graphical interface in the "depth" of the message prepare.

Structure of the FITT components The packages

The components of the FFIT tool are stored in the Java package traceFormater. In accordance with the main structure of the concept, a separate Java package was provided for the individual components, as can be seen in FIG. 7, in order to organize the source code and the Java classes. The entire files of the packages are stored in the "ffti.jar" file. The package traceFormater.util contains general classes that could not be meaningfully assigned to any of the components.

The pre-filter

The pre-filter can do anything from a file Filter out formatted GIOP / IIOP traces.

Function and concept

For this purpose, the form of the message packets is passed to the pre-filter. This is done with the help of a string consisting of the characters '.' (Dot) for any unimportant characters, 'l' (small L) for the character index (l for lines) and 'x' for the actual hex code, as also shown in FIG. 8. This concept of the filter string has the advantage that other or new formatting can later be taken into account in the job logs, which can simply be entered by the user.

If a line was read in according to the filter, that is only the characters for which an 'l' or 'x' stands checked if it really is a line with hex Code or other information in the job log.

This can be done simply by checking the occurring characters happen. If it is using hex code Character index, only the characters '0' to '9' and 'a' to 'f' occur; if not, it is Row unusable.

Data storage

After this filter string, the corresponding ones Read characters from the job log and the pure hex code in a new file ("GIOP.TMP" as standard). Becomes If the value 0 (zero) is recognized for the index, a new one begins Package and there will be a space ('') in as separator  inserted the hex stream. This means that even with faulty ones Parcels without length information (or with incorrect ones Length specification) again and again the starting point of the next package can be found, and thus also the Packets still parsed after a bad message become.

Structure and interfaces

The pre-filter consists of only one Java class (TracePreFilter) with a static method (cleanFile ()) that can throw a general exception:
The static method cleanFile
public static String cleanFile (String theFilter, File srcFile, File destFile) throws Exception
the string for formatting, the file with the traces and a target file are transferred as parameters.

No instance of this class has to be created for this, but it can directly use the functionality of the method the call TracePreFilter.cleanFile (...) can be used.

Special features are the formatting for the component broker ORBs. Instead of the entire format string, short substitutes are enough to avoid having to pass the long string each time:

"390" for all languages of the S / 390 ORB,
"NTJ" for the NT ORB for Java and
"NTC" for the NT ORB for C ++.

In addition, with a zero value for the target file the "GIOP.TMP" file in the current directory as the default value set.

This means that the next higher layer (here: the Parser) only needs to know in which file the hex code is filed to use the result of pre-filtering can. This shouldn't be a problem as a rule this calls the pre-filter itself.

The parser problem of the unknown parameters

The parser reads the stored hex code from the corresponding file ("GIOP.TMP") and interprets it gradually. The parser itself receives the start parameter the name of the job log file and then calls the pre-filter a null value for the target file, so here it is too no problems with the target file because the Default value is used.

function

The actual parsing process then takes place as follows: It is for the recognized Part of an object created that the assigned Parsing area independently. So the programmer has to don't worry about it anymore. But that means it has to be for everyone Message type and any more complex message component own class exist.

An object of the GiopFile class offers entry which then creates instances of the GiopHeader class, because at least one GIOP news head should appear. Each after the information of the GiopHeader then specific GIOP message objects (e.g. of the type RequestHeader) created and saved. These create more again Objects for their own components etc.  The position of the hex code in the Pass the file for which it is responsible and from the object saved. This is important if the object is later must perform further operations using this code.

The information of the class is then read in accordingly, possibly translated and stored in the attributes of the class. In addition to this information, the classes contain the option of creating new objects for complex "sub-components" (if available). This leads to a hierarchical structure, as shown in FIG. 9.

The problem of the unknown components

As already explained above, different ones can be used Components of a GIOP / IIOP message only on the basis of the pure hex codes are not parsed. This is due to the open architecture of this protocol or the entire CORBA Model, which allows the user to create new ones Define data types or classes and over the network too transfer. Information regarding the structure of these parts but are not in the protocol, but only one CORBA Application before what this tool should not be.

The solution used

Since this problem cannot be solved at the parser level alone, an object of the GiopBody or ParmsBody type is simply created for unknown components, depending on the occurrence of the unknown component. This then contains the starting position of the unknown component and its length in bytes (octets). Depending on the type of unknown part, this length information can be obtained as follows:
If it is an encapsulation (for profiles or contexts), the length was stored as a long value in the first four octets and only needs to be read out.

But when it comes to parameters, the length is actually unknown. However, the parameters are always on End of a message. Because the total length of the message is known and after parsing all other components also the starting position of the parameters, the number can be of the bytes occupied by parameters are very simple calculate over the difference of the values. The so registered As a result, unknown hex codes can be found quickly to be processed later. The So responsibility for further processing becomes simply in part to the user interface passed on, which then somehow represent the hex code got to.

First solution level

A table is used as the standard representation, which consists of the hex code and the corresponding ASCII and EBCDIC characters and a corresponding heading ("Context 4 ", or "Profile 2 ", or "Parm"). This means that the developer who uses this tool can see the relevant components very quickly and neatly and possibly interpret them himself. At least in terms of clarity of the hex code, this represents an improvement over the original job log, but can still be improved.

Extended solution

Therefore, at least for the unknown parameters (still not for profiles and contexts) for requests and replies in the corresponding parent class of these two A parseParms () method is provided for message types supports parsing of some base types for the parameters.  

In order to parse the area of unknown hex codes, the class must be informed which data types are encoded in it. This is done via a list that contains numerical (integer) values for the data types. The types are initially supported, as shown in FIG. 10.

The list with the integer values then becomes an object of the Class ContextParser, or a derived class above the setParmTypes () method. To make this useful To be able to use the user interface offers the Possibility for the unknown parameters from a list to specify the desired data types. To the hex code is then parsed. The hex code will then parsed according to these specifications and the received ones Information stored again in a new list. This can be obtained using the getParms () method. Since the Do not list any type information about the stored data contains, the first list with the data types must again can be used because the first object in the results list is from first type of the type list and the second object from second type and so on.

Easier to use or more readable than the integer values however, are strings with the names of the data type. Therefore can also provide a list of names for those supported Types from the ContextParser class via getTypeList () be asked, the element with index '5' the name for type '5' contains.

Avoid misinterpretation

Since the type list for a limited area of the Hex codes practically any data types can be specified misinterpretations are almost guaranteed. For example, the real parameter list consists of one Long value and a string, but will only be a string as a type specified by the user, the long value is the length of the Interpreted strings. If this value is now much larger than the actual length inevitably comes to a The limits of this package component have been exceeded.

To avoid or at least recognize this, it must constantly controls the position within the hex code and be checked for exceeding the limits.

That is why the parsParms () method must do exactly this Check after every change of the position in the hex code be inserted. If there is a violation of the limits, must throwing an exception, preferably with the hint that wrong parameters were probably given.

This constant checking slows down the parsing process, however, this one plays small and relatively rare occurring (just only with user-defined parameters) Performance loss plays a very minor role.

Data storage

The data storage runs parallel to the parsing and therefore exactly the same hierarchical like this. That is an object of one News class parses its typical components and stores the result in its attributes, so here too there is no additional effort. It is about complex components, becomes an instance of the class who is responsible for this component, and also saved as an attribute. Is it a Sequence of similar, complex components (e.g. by one sequence <IOR <), the corresponding objects in one, Containers offered by the Java API (here:  java.util.Vector). The container is there again an attribute of the corresponding class.

This results in the data structure shown in FIG. 11 (the further - lower - levels can be found in the appendix).

Structure and interfaces

The classes of the Parser have almost in common that it is sufficient to create an associated instance to the class to move to parse. That is the method for parsing the corresponding codes are already called in the constructor. So above all for further work with the objects still the getter and setter methods interesting to the Read out or manipulate the attribute values obtained can. However, this only applies to the constructors Parameters, since without the corresponding values (e.g. which ones File where) parsing is not possible. It is also about the default constructor (no parameters) possible to create a corresponding object without this to use immediately. However, if the constructor with the Using parameters, an instance of the class is sufficient Create GiopFile with the corresponding parameter values, to start the parsing process and thus the entire To use parser. Due to the hierarchical data storage, can pars to the next layers after parsing accessed via the entry point of the GiopFile object become. About the getter methods of this and the one obtained Classes can be reached, read out any data and possibly be changed using the setter methods.

User interface as a post filter

The user interface is used on the one hand to display the Packages of a job log and another as another filter. That is, it can be selected which information, how should be output in detail so that the user interactive based on the news already viewed can select other areas. So the user is not like a "real" post filter on its unique Selection set.

The main window

The main window mainly consists of one Tree view in which the individual packages and its components are shown, as well as a text field in the additional information about the news and the contents of which are displayed, depending on the selected node the tree structure. There is also a simple menu to call the standard dialog for selecting a file and to exit the application.

In the basic state, the text field is empty and the tree contains an element labeled "please open file" to indicate the Alert users to the waiting state of the tool.

Fig. 12 shows the finished surface.

If a file was selected, the tree structure with the found message packages and their components replenished. In the case of requests or replies, the unknown parameter displayed as "Parms Unknown". Becomes Marked a sheet, more details are in the text box spent. If unknown parameters are marked, a Table with the hex code and the ASCII and EBCDIC Interpretation is displayed in the text box so that the parameters can be viewed despite the unknown structure.  

In addition, there is also a request to the user issue the sheet "Parms Unknown" of the tree structure with the right click to select the data types of the To specify the parms: click with the right mouse button on "Parms Unknown" in the tree structure. . . ").

The dialog for type determination

If the user has done exactly this, the dialog for type determination is opened. This consists of two list fields: The left contains the supported data types, the right the selected ones, as can also be seen in Fig. 13. The selection or withdrawal takes place via the buttons "Add" and "Remove". Since the user can see the corresponding hex code with associated ASCII and EBCDIC code for unknown parameters, it is possible to recognize or at least estimate the types of data contained and to select them accordingly on a trial basis. When the selection is finished, the dialog can be closed with the buttons "OK" to confirm or "Cancel" to discard the selection.

If the parameter types were confirmed with "OK", "Unknown Parms" is replaced by "User specified parms" in the tree structure. The values of simple data types are output according to the scheme as in FIG. 14 in the text field, while for the more complex data types (e.g. IOR) a new level is added in the tree structure, as in FIG. 12 in "Reply ( 3 ) " you can see.

If the result is not yet the desired success brought (for example, an error message), the Types can be re-specified as often as required, but now  "User specified parms" in the tree structure on the right again is clicked.

Structure and interfaces of the classes The class of the main window TraceFormater

The TraceFormater class for the main window contains the only class of this tool that contains a main method and can or must therefore be used to start the tool. To do this, the ffit.jar file must be added to the CLASSPATH and the program via the call

java traceFormater.gui.TraceFormater

be started. In Windows NT or Windows 9x this is done by the batch file RUN. BAT taken over.

The further components of this class can be seen in FIG. 15.

The dialog class for defining the parameter types

This class supplies the integer values for the data types of the parameters in a vector. To do this, a new instance of the ParmsDialog class must be created and set visible (method show ()). Since this is a modal dialog, the program flow of the calling program part is stopped until the dialog is closed again. That means after calling show () you can simply ask whether the dialog was closed with "OK". If this is the case, the list of the selected parameters can be queried via getTypes (). These can then be passed to a ContextParser object so that it can parse its parameters according to these specifications. The entire process is summarized again in an example in FIG. 16.

Extension of the tool

The only possibility the parameter types and others Find components without user intervention and accordingly when interpreting the hex code To be able to implement it would be to query the interface Repositories. This is one of the services ORB provides exactly for this purpose.

As the main components of the Component Broker ORB for System / 390 now run smoothly, one could appropriate formatting tool then as CORBA application to be implemented. However, this can no longer independent of the problematic system be worked on because of the corresponding interface Repository needs to be accessed.

The future of the Internet Inter ORB Protocol

Since the GIOP / IIOP dealing with any and any support complex objects, use is also possible in the world of the WWW (World Wide Web). So could complex multimedia objects or security-critical ones Data (with security context) over the IIOP much easier than transmitted over the HTTP (Hyper Text Transfer Protocol) become. This is an important factor at a time of growing multimedia and e-business applications and could for a further enforcement of the IIOP in the internet area to care.

Claims (28)

1. Method for troubleshooting by means of the representation of the communication in distributed applications, wherein a distributed application consists of at least one application part that is installed on a transmitter system and at least one other application part that is installed on a receiver system, and both application parts via one communicate common protocol with each other, the transmitter and receiver functions being interchangeable during communication, the protocol information for the communication exchange between the transmitter and receiver being stored in a file, characterized by the following steps:

• a) converting the log information into a generic format
• b) decomposing the information after step a) into administrative and user data and interpreting the data obtained as far as possible
• c) storing the results after step b) on a storage medium
• d) displaying the result after step c) in a user interface

2. The method according to claim 1 characterized by the following further step:

• a) Presentation of the non-interpretable data according to a standard format.

3. The method according to claim 1, characterized in that the distributed application through an implementation of the General Inter ORB Protocol (GIOP) communicates. 4. The method according to claim 1, characterized in that when transferring the information according to step a) unnecessary information is filtered out and remaining information as a pure GIOP hex code being represented. 5. The method according to claim 4, characterized in that the unnecessary information Formatting characters, character indices or ORB generated additional information concern, the Formatting of the log data must be known. 6. The method according to claim 4, characterized in that the log data must be formatted differently can. 7. The method according to claim 4, characterized in that the pure GIOP hexcode is stored in a new file becomes. 8. The method according to claim 4, characterized in that the pure GIOP hexcode with separator between the respective messages (packages) in a new file is filed. 9. The method according to claim 1, characterized in that disassembling according to the GIOP format in GIOP Message header and GIOP message is done. 10. The method according to claim 9 characterized by the following steps:

• a) Reading the GIOP message header
• b) Interpret the components of the head using a table
• c) Evaluating the information after step bb) to interpret the following component
• d) Perform steps bb) -cc) until all components of the GIOP package have been evaluated.

11. The method according to step 10, characterized in that the position and length of the components that cannot be interpreted are stored. 12. The method according to claim 10, characterized in that all evaluation results after step aa) -dd) being represented. 13. The method according to claim 10, characterized in that all evaluation results in one user interface with a selection function for the depth of information for every single message. 14. The method according to claim 13, characterized in that the data of the selected message in a separate output area in the user interface being represented. 15. The method according to claim 13, characterized in that the user interface the messages of a hex file in the form of a tree structure. 16. The method according to claim 15, characterized in that the graphical user interface the news according to their order in the hex file in represents a tree structure.   17. The method according to claim 13, characterized in that the non-interpretable part of the message as unknown in the user interface. 18. The method according to claim 17, characterized in that the non-interpretable part of a message as is reported unknown and in the case of Selection as a table with the hex code and associated ASCII and EBCDIC interpretation in Output area of the user interface is displayed. 19. The method according to claim 17, characterized in that the data types that are not in the hex code of the interpretable part of the message are included can be assigned subsequently. 20. The method according to claim 19, characterized in that the subsequent specification of the data types via User dialogue takes place. 21. The method according to claim 19, characterized in that the determined data type according to its assignment is inserted into the tree structure. 22. The method according to claim 20, characterized in that the part of the message identified as unknown in the representation of the user interface in custom renamed and the hex code Representation for this part of the message at Selection is represented by the values obtained. 23. The method according to claim 1, characterized in that the distributed application is based on CORBA architecture.   24. Device for troubleshooting in a distributed application, comprising at least:

• a) a storage means with at least one file with protocol information of a distributed application
• b) a tool for handling the log data according to process steps 1-23.

25. The device according to claim 24, characterized in that the storage medium and the tool are part of one Data processing devices are. 26. The device according to claim 24, characterized in that the storage medium and the tool in different Data processing devices are arranged over a Means of communication are interconnected. 27. The device according to claim 26, characterized in that the means of communication is the intranet or Internet is. 28. Computer program product stored in the internal memory of a digital calculator is stored, containing parts of Software code for executing the method according to Claims 1-23 when the product is on the computer is performed.