WO2004061650A2

WO2004061650A2 - A method and system for improving message syntactic analysis in a message broker

Info

Publication number: WO2004061650A2
Application number: PCT/EP2003/015014
Authority: WO
Inventors: Marc Fiammante
Original assignee: International Business Machines Corporation; Compagnie Ibm France
Priority date: 2003-01-07
Filing date: 2003-11-14
Publication date: 2004-07-22
Also published as: EP1584027A2; WO2004061650A3; AU2003303604A8; CN1735863A; AU2003303604A1

Abstract

A method is disclosed for enhancing a Message Broker operating in a data processing system with a parser for an e-mail like type of messages. The method comprises an initial step of generating, with a context free programming language generator, the source code of a compiler by providing to said generator the rules of a LL(k) grammar corresponding to the syntax of said e-mail like type messages; then, creating an executable code with said compiler source code and, installing and generating in the Message Broker the executable code as a new parser for said e-mail like type of messages; when a message is received and identified by the Message Broker as being of said e-mail like type, parsing said message as a context free programming language with the executable code; usually the logical representation of the message built in memory by the compiler is used by the translator and link-editor to create an executable code from the message. In the case of the present invention, the logical representation of the message which is the output of the preceding step execution is used by the following processing step of the Message Broker.

Description

A METHOD AMD SYSTEM FOR IMPROVING MESSAGE SYNTACTIC ANALYSIS IN A MESSAGE BROKER

The present invention generally relates to Enterprise Application Integration programs and more particularly to the function of message analysis performed by the Message Broker which transforms the content of a message received from a first application to make it comprehensible by the target application.

Background of the Invention

With the use of Message Oriented Middleware (MOM) programs, the heterogeneous applications can communicate without being aware of the communication means between them. Using an asynchronous communication protocol, MOM programs provide message management between applications which become loosely coupled in a connectionless mode. The MOM takes care of the message transport layer and manages message queues for the applications. However, each application using the service of the MOM, needs to know the format of the messages of the application it communicates with.

In order to provide a deeper Enterprise Application Integration (EAI) , applications are adapted to appears as transaction oriented using use real-time messaging mechanism

(e.g. Publish/subscribe, request/reply, synchronous, asynchrounous ) to communicate. A new programming layer, the

Message Broker programs, is responsible for looking into the message content to identify the message type, look at the corresponding message format, identify the logical content of the message, modify the message content if necessary, initiate the formatting adaptation to the target application and route the message to a MOM queue or directly to the target application. One example is the WebSphere MQIntegrator V2

(noted WMQI in the present document) of IBM (IBM, WebSphere and MQIntegrator are trademarks of IBM Corporation in certain countries) .

The Message Brokers currently sold by the EAI software manufacturers support either binary form (C language or Cobol messages) messages, tagged messages optionally including fixed formats (such as SWIFT, EDI or FIX messages) or tagged but flexible, self-describing messages such as with XML protocol.

A Message Broker may be generated with different parsers, each of them performing the syntactical analysis of a different message type. Usually, Message Broker programs provide an interface to add more parsers. However, the Message Brokers are not able to support more highly flexible syntax messages such as e-mail messages. This type of messages is well known under the name of context free language based messages. In the rest of the document they will be named ^λ e-mail like' type messages. WMQI Message Broker supports for XML type messages or Cobol like Custom Wire Format messages or tagged messages. These e-mail like type messages are messages having a more complex structure which cannot be described by COBOL or C structures or tags. As an example, an e-mail address can include optional comments between "(" and ")" at any place in the address. According to the RFC2822 describing e-mail syntax, the expression Dupont.(I am the greatest) Marc @(the)Vegas.WBA is a valid address and is equivalent to Dupont.Marc@Vegas.WBA or even to Dupont(I am).(the) Marc(greatest)@(The)Vegas(in nevada).WBA. If a message contains such a variable content text, fixed parsing cannot handle it and tags description using the "(" would lead to too complex definition because of the occurence of such a comment at any location. In addition, these messages contain a syntactic structure that cannot be described with fixed tags because their interpretation is relying on a large sequence of tokens rather than one simple tag/value or even tag/subtags recursive sequences. Consequently, the solution consisting in modifying the message broker parsers as of today would lead to a huge amount of code to be repeatedly executed for applying the tagged or data structured message token discovery to multiple any location in the message, i.e. as many times as these locations are authorized by the syntax of these highly flexible messages. Furthermore, all the new cases could not be covered by such an syntactical analysis . One other drawback of this approach would be a poor level of quality of the corresponding code for maintenance purpose .

It is noted that to enrich the current Message Brokers with new parsers, one can use the parser plug-in API provided by most of the Message Brokers as of today. WMQI provides a C language API to add a parser so that it will handle any given message type or format provided that a suitable parser is available. Any new parser plugged in a Message Broker should also be adapted to provide output format compatible with the logical message representation in memory as expected by the other functions (routing, formatting) of the Message Broker. Summary of the Invention

It is an object of the present invention to add to a Message Broker parsers able to handle highly flexible syntax messages such as e-mail messages.

These objects are achieved by the use of a method as claimed in claims 1 to 6 for enhancing a Message Broker operating in a data processing system with a parser for an e-mail like type of messages. The method comprises an initial step of generating, with a context free programming language generator, the source code of a compiler by providing to said generator the rules of a LL(k) grammar corresponding to the syntax of said e-mail like type messages; then, creating an executable code with said compiler source code and, installing and generating in the Message Broker the executable code as a new parser for said e-mail like type of messages; when a message is received and identified by the Message Broker as being of said e-mail like type, parsing said message as a context free programming language with the executable code; usually the logical representation of the message built in memory by the compiler is used by the translator and link-editor to create an executable code from the message. In the case of the present invention, the logical representation of the message which is the output of the preceding step execution is used by the following processing step of the Message Broker.

These objects are also reached with the computing system comprising means adapted for carrying out the method according to anyone of claims 1 to 6.

The context free language based messages can be based on a LL(k) grammar because the syntax of these messages can be analyzed on the basis of a set of LL(k) grammar rules that one person skilled in the art can easily define. The LL(k) grammars up to now known for high level programming language compilation, are particularly adapted to the syntactical analysis of context free language based messages.

With the use of LL(k) grammar, the token discovery process is adapted to context free language based messages, thus avoiding the weakness of the algorithms based on repeated token discovery process used with tagged or data structured. One consequence is the good quality of the corresponding code to perform the syntactical analysis and the simplicity of the maintenance of that code .

One advantage of the present invention is the possibility to reuse existing LL(k) grammar based programming language compiler generators which are generally used by the developers to generate a new compiler corresponding to a new high level programming language that they have created.

With the solution of the present invention, a customer buying a Message Broker to build an EAI environment can use the parser plug in interface of the Message Broker to add the e-mail like type message parser. A Message Broker program manufacturer can enrich the program by adding such a parser in the Message Broker program. Using the solution of the present invention, a Message Broker program manufacturer can also includes as a program component a compiler generator and its corresponding Tree adaptation component and let the user plugging himself the parser in the Message Broker to process any type of e-mail type messages he desires. Brief Description of the Drawings

Fig. 1 illustrates an EAI environment allowing a set of heterogeneous applications to communicate together;

Fig. 2 shows the logical blocks of a Message Broker according to the preferred embodiment, implemented as a program executing in a computing system;

Fig. 3 shows the general flow chart of the method of the Message Broker according to the preferred embodiment;

Fig. 4 shows the flow chart of the method to generate a parser used in the method for brokering messages according to the preferred embodiment;

Fig. 5 shows the flow chart of the method for parsing e-mail like type messages according to the preferred embodiment .

Detailed Description of the preferred embodiment

Fig.l illustrates the use of a Message Broker (105) in the Enterprise Application Integration programs for a typical business environment. A set of applications (140) may operate on different computers communicating through local (150) or wide area networks (130) , either public or private. The EAI programs are preferably installed and operates on a separate computer (100) connected to the application computers. Any applications may receive messages from other applications and send back answers or sends new requests to other applications through the EAI computer. Standalone customers (110, 120) are connected through a Public network to an SMTP server (140) can also communicate with the applications through the EAI programs. The applications which communicate through the EAI programs may use different programming languages depending on the time they were developed, they may also use on the computers different hardware and operating systems. A MOM software (115) uses a common transport protocol such as HTTP or TCP/IP to perform asynchronous communication with the applications. The messages received by the MOM are sent to the Message Broker which looks into their content and route them to the queue of the MOM for a target application. The Message Broker software layer has been adapted to the application environment, he knows the message formats, the processing rules and supports different types of messages. The Message Broker, according to the preferred embodiment of the invention, is able to receive e-mail like type messages.

Fig. 2 describes the program logical blocks of the Message Broker (200) according to the preferred embodiment. The dotted lines describe the path used by a e-mail like type message in the Message Broker logical blocks. The Message Broker receives messages from applications through an INPUT/OUTPUT interface logical block (250) . The INPUT/OUTPUT interface may be of different type: the Message Broker may have a direct API interface with an application (241, 215) or may have an interface to the MOM which handles (235, 245, 265) a common transport layer for all the applications (HTTP as an example) . The output of this interface logical block is a byte stream containing information which needs to be processed by the Message Broker and transmitted to the target application. An e-mail like type message is received via the MOM (245) by the Message Broker. A message type identification block (255) switches the message byte stream to one of the parser logical blocks (260, 265, 270) . A parser performs a syntactical analysis of the messages and provides as output either an exception error if the message contains syntactical errors, or a logical representation of the message in memory, that the Message Broker uses to build the exact format as expected by the target applications. In Fig. 2 more than one parser are represented, each of them corresponding to a specific message type. Some parsers may be provided by the Message Broker, other ones may have been added using the parser plug-in API available in most of the Message Brokers. The e-mail like type message is sent to a specific parser (270) which is a context free grammar based programming language compiler created according to the preferred embodiment as described later in reference of the same figure. The result of the syntactical analysis of the message byte stream performed by the parser is a logical representation of the message stored in memory. It is noted that most of the Message Brokers have a tree based representation of the message. According to the type of compiler used as a e-mail type message parser, the logical representation of the message created by the parser could need to be adapted to the logical representation in memory used by the following logical block of the Message Broker (280) . Accordingly, a new logical block (275) illustrates the adaptation which is reformatting a tree based representation of the message into a new tree based representation as expected by the Message Broker following processing logical blocks. The tree is then used to create a message content as expected by the target application in the Message Content Processing logical block (280) . The process is performed according to processing rules (290) defined by the EAI environment administrator. The processing rules are used to analyze a specific message semantic content (a message format to update a banking account, for instance) and to perform logical routing. According to specific processing rules, in the processing rules may also be enriched to have the Message Content Processing logical block (280) may be to computed a new field as expected by for a target application. The message content in is then sent to one or more target application (s) or one or more specific message queue in the MOM through the INPUT/OUTPUT interface logical block (250) . The message formats (295) are applied on the output interface (250) for producing the physical byte stream as expected by the target application (s) .

According to the preferred embodiment, the Message Broker includes a new logical block, a compiler generator for LL(k) grammar based programming languages (242) . It can be a compiler generator of the prior art such as Java Compiler Compiler ( ^λJava Compiler Compiler' is a trademark of Sun Microsystems) abbreviated as JAVACC, for Java code or ANTLR Parser Generator freely download able from the ANTLR web site at http: //www.antlr . orq/ . for Java code or C ++ code. The compiler generator provides an interface to the programmer

(230) to enter the grammar rules. In output, the compiler generator provides a source code in a certain language which must be compiled and transformed into a machine readable

(executable) code as any source code. The resulting executable code is a compiler based on the LL(k) grammar defined in the generator. It is used as a new parser for syntactic analysis of the new e-mail like type messages received by the Message Broker. As a matter of fact, the input byte stream which is the e-mail like type message content is parsed by the LL(k) Grammar Based Compiler logical block as if it is a programming language source code. The output of the block (270) is a logical representation of the e-mail like type message stored in the memory of the computer. A new logical block (275) is also added which reads the logical representation of the message in memory and adapts it to the logical (generally tree based) representation of the message as expected by the next activated logical block of the Message Broker (280) which processes and formats the message for the target application. It is noted that the logical representation of the message content provided in output of a LL(k) Grammar Compiler is also tree based. The Tree Adaptation logical blocks consists in a rearrangement of the tree in memory.

Usually, the programmers inventing a new programming language use the LL(k) grammar based compiler generators for creating a compiler for their new language. The compiler generator provides an interface to the programmer to describe the grammar rules. The compilers of the prior art provide a programming language to enter the LL(k) grammar rules. A graphical user interface could also used to enter the grammar rules. Once the grammar rules are entered, the programmer activates the generator which provides in output the source code of the new compiler. The programmer compiles the new compiler source code and obtains an executable program which is used to compile the source code which will be created using the new programming language. The new compiler reads the new programming language source code file and performs a syntactical analysis of the code. The new compiler is first used by the programmer to identify all the errors in the code. During the development of programs written with this new programming language, this syntactic error detection is used to 'debug' the source code. One usual performance criterion of a compiler is first its capacity to detect programming language errors. When the compiler has been executed without any error, it stops, having stored in memory a logical representation of the analyzed source code. This output is used by the translator and link-editor to create the executable code. This later program is created by the compiler developer. This is a program which reads the logical representation of the analyzed source code which has been stored in memory by the compiler and creates an executable code which can be executed by the computer.

When the LL(k) Grammar based Compiler is used in the preferred embodiment, to parse e-mail like type messages, if there is no syntactical error, the logical representation in the memory of the e-mail like message is used for the following operations of the Message Broker. One adaptation program will modify the representation in the memory of the computer for the Message Broker.

This is made possible because each e-mail like type message syntax can be well defined by the rules of a LL(k) Grammar. To one type of e-mail like type message corresponds to a specific LL(k) grammar. This point will be illustrated in reference to the example of e-mail message analysis provided later in the present document.

A e-mail like type message parser can be added to a Message Broker by defining the LL(k) grammar corresponding to this e-mail like type message, creating a LL(k) grammar compiler logical block, (created by a compiler generator in the preferred embodiment) , and, creating an adaptation logical block corresponding to this compiler (or corresponding to all the compilers created by the compiler generator in the preferred embodiment) , this logical block being able to read the logical representation in memory of a message parsed by the compiler to the representation as used in the Message Broker .

The use of a LL(k) grammar based compiler to parse e-mail message type is possible because the e-mail message type syntax is close to a high level programming language and well defined by grammar rules. Typically LL grammars (k being the maximum number of lookahead that is the maximum number of tokens to discover before finding a terminal and check the rule) , which first L stands for left to right scanning of the

5 input message and the second L for producing the leftmost derivation (also known as top down parsing) . The parsers first find children of the root and so on. It also produces syntax trees which could be mapped to the syntax trees of most of the Message Brokers. The LL grammar compilers are able to parse

.0 any kind of input including non printable binary input, which makes it even more suitable for EAI type of message parsing.

Fig 3 shows the general flowchart of the method of a Message Broker according to the preferred embodiment. According to the preferred embodiment, before operating the

L5 Message Broker which supports e-mail like type messages, the EAI administrator has to create the corresponding parser. To do this, he performs two initial steps which can be done in parallel. One initial step consists in generating a LL(k) grammar based programming language compiler executable

20 program. One other initial step consists in creating a program able to read a logical representation in memory of a source code file which has been compiled by the compiler and to create an equivalent logical representation of the source code in a way compatible with the Message Broker. This second step 5 is optional in the case where the generator memory representation is compatible with the Message Broker. If one uses an existing compiler generator of a different manufacturer than the manufacturer of the Message Broker, he will have to perform this adaptation program. If the compiler 0 generator is developed for the purpose of the Message Broker, the representation will be directly the representation of the Message Broker. This adaptation program is created for the creation of the first e-mail like type message parser with a generator. Once created, the adaptation program will be used 5 for all the parsers generated with the same generator. It is noted that the compiler of LL(k) grammar based programming language use in memory a tree based representation of the compiled code. Most of the Message Brokers use also a tree based logical representation of the messages they process.

When the e-mail like type parser is created it is generated in the Message Broker in order for the Message Type Identification to recognize this type of message and to sends it to the new parser. The tools for generating and installing a new parser in a Message Broker are part of the Message Brokers basic functions. The new e-mail like type message parser, once installed is used by the Message broker to interface applications using this type of message. Assuming that the Message Broker receives a byte stream from the EAI interface, the first step consists in identifying the type of message. In the Message Type Identification logical block are used some information in the message headers or specified in its own properties to determine how the message body is parsed:

- If the message has a recognizable routing header, the domain identified in the header is used to decide which message parser is invoked.

- If the message does not have a recognizable header, or the header does not identify the domain, but the properties in the Message Type Identification logical block indicate the domain of the message, the parser specified by the property is invoked. The parser specified can be a plug-in parser such as an e-mail like type message parser.

- If the message domain cannot be identified, the message is handled as a binary object.

Once the message type is identified, and if it is an e-mail like type message, the byte stream is sent to the corresponding e-mail like type parser which has been created with the one or two step initialization procedure. In the following step, the byte stream is syntactically analyzed by the LL(k) Grammar based compiler as if it was a programming language source code. The result of analyze may be a syntactical error because the message is not recognizable. When the e-mail like type syntax is correct the result is a (usually tree based) logical representation of the input message which is located in the memory of the computer. This representation is adapted in the next step. As stated before, this last step is optional depending on how the parser has been created. The next step consists in processing the content of this message as if this was an XML or Cobol type message. The last step consists in routing this e-mail like type message to the target application as done for any type of message in the Message Broker. These two last steps have not changed in the Message Broker.

Fig. 4 describes the steps of initialization of a parser able to support e-mail like type messages in the Message Broker. This initialization is performed usually by the EAI programs administrator who needs to interface new applications supporting this kind of messages. The first step consist is activating a LL(k) grammar compiler generator which could have been developed for this purpose or which could be JAVACC or ANTLR. For the following illustrative example later in the document, ANTLR is used. The administrator enters the grammar rules defining the syntax of the e-mail like type messages the new application supports . In the illustrative example later in the document, the messages are e-mail messages as defined in RFC2822. The generator creates the parser source code and the administrator creates an executable code with this code. If necessary, a message logical representation adaptation program is created to map the tree structures that the compiler creates in memory to the tree structure defined in the Message Broker if they are not compatible. When the administrator wants to add a second e-mail like type parser, we will only not repeat the last step for logical representation adaptation. The last step consists in including the compiler and, possibly, the adaptation program in the Message Broker, using the parser plug-in API, for instance.

Fig. 5 shows the flowchart of the e-mail like type parsing operation as performed in a Message Broker according 5 to the preferred embodiment. The first step consists in reading the byte stream corresponding to the message to be parsed which is transmitted by the Message Broker. The second step consists in activating the compiler which performs the parsing by discovering the syntax used and compare to the

L0 grammar rules which have been stored during the phase of compiler generation, in the preferred embodiment. Simultaneously to the analysis, the compiler builds the logical representation of the message in memory. If the compiler finds a syntactical error, it stops and an exception

L5 message is sent to the Message Broker which, itself, sends an error message to the source application. If the compiler completes the syntactical analysis with no error, it gives back to the Message Broker a reference of the logical representation of the message in memory. If a adaptation is

20 needed the reference is given to the logical representation adaptation program which starts automatically and maps the referenced logical representation of the message to a representation adapted to the Message Broker. The adaptation message gives back to the Message Broker a reference to the

25 adapted logical representation of the message.

As an example, an EAI administrator may decide to create and include in the Message Broker a parser for RFC2822 defined e-mail messages according to the preferred embodiment. The administrator may use ANTLR, a compiler Generator freely

30 download able from the ANTLR web site at http: //www. antlr.org/ . for Java code or C ++ code. ANTLR provides a text entry to describe the grammar. The RFC2822 is used to enter the grammar rules using a code as follows:

class eMailParser extends Parser; options { buildAST=true; } /* Build a syntax tree */ message : (fields)* ; fields :( from to sender reply_to subject return_path date 0 received message_id ) (CRLF I body ) ; body : Body { #body = #([BODY,"Body text: "],#body); } ; /* { #body = .. } creates a dummy tree root named "Body text:" */ 5 from : "From:"^Λ { parseAddress(##); } ; /* the "^Λ" makes "From:" the root of the AST */

/*parseAddress(##) switches to the eMail address parser */ sender : "Sender: "^Λ { parseAddress(##); } ; reply_to: "Reply-To: "^Λ { parseAddress(##); } ; 0 to : "To:"^Λ { parseAddress(##); } ; subject : "Subject: "^Λ utext ; message_id: "Message-ID: "^Λ utext ; return_path: "Return-Path: "^Λ { parseAddress(##); } ; received: "Received: "^Λ (FWS | WS)* Atom utext; 5 date : "Date: "^Λ utext; utext : ( Atom | FWS | NO_WS_CTL | WS

[ Comma | Dot [ At | Colon | Semicolon j Lt I Gt I Escape | KEYWORD I Other_Ascii 0 )* ; class eMailLexer extends Lexer; /* Extract of the lexical analysis see full lexer in the provided source*/ protected Atext : (ALPHA | DIGIT | // Any character except controls, 5 "!" | "#" I // Space, and specials.

"$" | "%"j // Used for atoms "/ir" I '"" I "*" I "4-" I " " I "/" I "=" I "?" I

"Λ" I " " I " " I » f II I ιι|" 1 'i i " I n_^,'^!^ •

Atom : (Atext)+ ( ':' {$setType(KEYWORD);} )? ; 0

With the ANTLR compiler generator more than one grammar can be entered: this fits to a characteristic of e-mail message syntax as described in RFC2822 which can be described with two grammars, one for the message itself, one for the -5 e-mail address. Not all the compiler generator accept the entry of more than one grammar . However, the person skilled in the art knows how to describe the syntax of e-mail in one grammar in the case where the generator does not accept the entry of more than one grammar .

Once the text describing the grammar is entered ANTLR is executed and creates an output source code file, in C++ language in the example , which is the source code of a compiler able to parse e-mail messages . An executable code corresponding to this compiler source code is created which will be the main component of the e-mail parser . If the administrator uses this ANTLR generator for the first time and if the tree representation of the generated compilers is not compatible with the Message Broker , he must create a second executable code to read a tree representation in memory created by a compiler itself created with ANTLR and to create one other logical representation as used by the Message Broker in which the e-mail parser will be included. This tree structure is described in the ANTLR documentation .

The following e-mail is provided as a byte stream to the e-mail parser :

Received: from x.y.test by example.net via TCP with ESMTP id ABC12345 for <mary@example.net>; 21 Nov 1997 10:05:43 -0600

Received: from machine.example by x.y.test; 21 Nov 1997 10:01:22 -0600

From: John Doe <jdoe@machine.example> To: Mary Smith <mary@example.net>, from@domain,":sysmail"@

Some-Group.Some-Org,Guess.(I am the greatest) Who @(the)Vegas.WBA

Reply-To: reply ©domain

Sender: sender@domain

Subject: Saying Hello, test of a subject with @ special \ ( characters ) ( inside of the #~ subject

Date: Fri, 21 Nov 1997 09:55:06 -0600

Message-ID: <1234@local.machine.example>

This is a message just to say hello. So, "Hello". Once parsed according to the method described the following tree is obtained:

Message — + — > Received: from x. etc

+ — > Received: from machine, etc

+ — > From: + — > Angle address + — > display-name : John Doe

+ — > local-address: jdoe

+ — > domain : machine.example

+ — > To: + — > Angle address + — > display-name : Mary Smith

10 I I + — > local-address: mary

+ — > domain : example.net

+ — > Classic address+ — > local-address: from ^■ + — > domain : domain

L5

+ — > Quoted address + — > local-address: :sysmail

+ — > domain : Some-Group.Some-Org

+ — > Classic address+ — > local-address: Guess. Who .0 I + — > domain : Vegas.WBA

+ — > Reply-To: + — > Classic address+ — > local-address: reply

+ — > domain : domain

25 + — > Sender: + — > Classic address÷ — > local-address: sender

+ — > domain : domain

+ — > Subject: Saying Hello, test of a subject

+— > Date: Fri, 21 Nov 1997

30 +---> Message-ID: <1234@local.machine

+ — > Body of message This is a message

Then, the e-mail parser main program is written. It comprises the instructions for reading the e-mail message byte stream provided by the Message Broker and activate the

35 compiler component created with ANTLR. The main program further comprises the instruction to read the output of the compiler execution which is double as it comprises the syntax error messages and a reference to a tree based representation of the e-mail message built by the compiler. If there are

10 error messages, the program ends and the error messages can be read in memory. If there is no error message the reference is given to the second executable code created for tree adaptation, the main program receives after tree adaptation the reference of logical representation of the e-mail message which can be used by the Message Broker. It is noted that, as the compiler has been generated using two grammars, two trees will be built in memory by the compiler and two references will be given as output of the compiler. The tree adaptation is performed for the two trees and the e-mail parser main program result comprises two references of logical representations of the e-mail message which can be used by the Message Broker.

In the example, the e-mail parser program just created can be included in WMQI using the C language parser API. The Message Broker will call the e-mail parser with the e-mail byte stream in input and receives the error messages or a reference to a the e-mail message tree if the e-mail had a correct syntax. The Message Broker transmits the error message to the source application having originating it. If there is no error, the Message Broker uses the two tree references given by the parser to process the message content (280) as described in reference to Fig. 2.

Claims

1. A method for enhancing a Message Broker operating in a data processing system with a parser for an e-mail like type of messages, said method comprising the steps of: - generating, with a context free programming language generator, the source code of a compiler by providing to said generator the rules of a LL(k) grammar corresponding to the syntax of said e-mail like type messages;

- creating an executable code with said compiler source code; - installing and generating in the Message Broker the executable code as a new parser for said e-mail like type of messages;

- when a message is received and identified by the Message Broker as being of said e-mail like type, processing said message as a context free programming language with the executable code;

- reading the logical representation of the message built in memory in output of the preceding step execution and using it in the following processing step of the Message Broker.

2. The method of claim 1 wherein the step of reading the logical representation of the message further comprises a step of modifying this logical representation to adapt it to a format accepted by the following processing step of the Message Broker.

3. The method of anyone of claims 1 or 2 wherein the step of processing said message with the executable code does not complete by building a logical representation of the message in memory but rather completes by sending back to the Message Broker an exception error on the syntax of the message because the LL(k) grammar rules where not matched in said message.

4. The method of anyone of claims 1 to 3 wherein the LL(k) grammar rules are provided to the compiler generator, in the generating step, through a programming language.

5. The method of anyone of claims 1 to 3 wherein the LL(k) grammar rules are provided to the compiler generator, in the generating step, through a graphical user interface.

6. The method of anyone of claims 1 to 5 wherein the logical representation of the message built in memory by the processing of said message the executable code is a tree based representation.

7. A computing system comprising means adapted for carrying out the method according to anyone of claims 1 to 6.