WO2004057825A2 - Method for communication between servers with data format conversion and device therefor - Google Patents

Abstract

The invention concerns a method for communication within a distributed computer system (19) between a plurality of client servers (4) provided each with specific software and hardware means and a plurality of application servers (5) provided each with specific software and hardware means and comprising each at least one selected application (6), the client servers (4) being directly connected to a single MCMA server which in turn is directly connected to the plurality of application servers (5), such that any service call from a client server addressed to a specific application server, is first addressed by said client server to the MCMA server for the latter to route same to the application server concerned and to transmit back possible data from the application server to the client server, each service call between a client server (4) and the MCMA server (7) co-operates with a language and format conversion chain. The invention is characterized in that when the MCMA server (7) uses XML and the client server (4-6) HTML, the associated incoming conversion chain includes an adaptation module integrated to the client server (4-6) using a programme written in Java for automatically converting the HTML forms for service call into an MCMA server (7) intelligible XML document.

Description

COMMUNICATION METHOD BETWEEN SERVERS WITH DATA FORMAT CONVERSION AND DEVICE FOR IMPLEMENTING SAME

The present invention relates to communication between servers within a so-called distributed computer system, such as in particular a financial computer system used by banks or by insurance companies.

The evolution of computer technologies in recent years has brought about radical changes in the design of applications. The new fast and high bandwidth telecommunications networks (ISDN, ATM, High Performance Ethernet) have made it possible to interconnect computers in increasingly large networks. This evolution has contributed to the emergence of distributed applications which implement different servers of different natures intended to communicate with each other to manage and process flows of transactions and information. A server is understood here as the combination of computer hardware (hardware) and appropriate software (software).

Thus, a financial computer system includes different so-called client servers (or even front office servers according to English terminology) interconnected with different so-called application servers (or back office servers).

Application servers are more particularly intended to manage databases and to perform specific processing also called services. The term service is defined here generally like any computer processing, this term covers both the provision of specific information such as an account number, as well as the calculation of a balance or a transfer.

The computer system of a bank generally includes a banking application server (example: financial engine marketed by SAB) which processes all operations linked to the management of deposit accounts, a credit server which manages the loans granted by the bank to its customers, a stock exchange server for securities management (Investiciel stock market engine marketed by SEMA), an insurance server, etc.

Client servers are intended to allow employees and users of the bank to access the various application servers from specific communication interfaces and networks, also called channels, to provide (update operations, etc. ) or recover (interrogation operations, etc.) of data through requests called service calls. Indeed, each request received by an application server generates the execution of a corresponding service by the latter.

As client servers used by a bank's computer system, we can cite a server managing the computers equipping the bank counters, an ATM / ATM server associated with the ATMs / ATMs, a voice server which allows users to access the application servers by means of a telephone, a Web server to access these servers via the Internet, a Minitel server, a WAP server, the servers of partners of the financial organization, etc. Such an architecture is essential to make it possible to obtain, by a simple call from a digital telephone questioning a financial institution such as a bank, the balance of a current account or even to charge a sum drawn during a '' a withdrawal from a bank machine and provide its holder with information on the new balance after this operation.

For a few years, the connection between the client servers and the application servers has been carried out by means of a particular server called MCMA server for multi-channel and multi-application server (also called middleware in English terminology). Saxon) to which all client servers and all application servers are connected.

Such an MCMA server ensures the routing of data between the servers but also is capable of achieving a certain number of additional functionalities. The MCMA server therefore acts as the sole application server for the client servers and as the sole client server for the application servers.

Thanks to this architecture, the development of a new client server requires only a single connection job to the MCMA server. The MCMA server is then able to provide this new client server with all of the services available on the application servers, according to a chosen communication method. It is obviously the same when it comes to adding a new application server.

Document WO-A-98/24040 describes such a server. Such a solution makes it possible to access each application server independently of the connections connecting the MCMA server to the client servers.

However, the communication method proposed in the prior art between client servers and application servers via the MCMA server is not entirely satisfactory insofar as it is relatively complex or unsuitable to implement, in particular in that which concerns: - the pooling of functionalities implemented by the MCMA server on behalf of client servers; - import / export of data to or from application servers, as part of a project to migrate data from other IT systems, for example; - regular changes in application servers

(upgrades, replacement, duplication, etc.).

Furthermore, the system proposed in the prior art does not deal with the integration of a client server and / or an application server having a technology different from that of the MCMA server, in particular with regard to the language. , the format or even the communication protocol which are generally different from the format of the MCMA server.

Traditionally, when an adaptation of the client interface must be made to the format, language and protocol expected by the MCMA server, the IT team responsible for this adaptation develops so-called intermediate or "middleware" programs dedicated to this adaptation. However, the IT team in charge of the client interface may be different from that in charge of the MCMA server. The same applies to the application server, the development of which may be specific.

This results in relatively long and costly development times for intermediate programs. In addition, the maintenance of the resulting system is relatively more complex, as is the identification of the components responsible for malfunction or reduction in system performance.

The present invention overcomes these drawbacks.

It relates to a method, and a device for its implementation, of communication between a plurality of client servers and a plurality of application servers each comprising at least one chosen application, the client servers being connected to a single MCMA server which is in turn connected to all of the application servers, so that any service call from a client server to a given application server is first addressed by said client server to the MCMA server it is up to the latter to route it to the application server concerned and to send back any information from the application server to the client server.

The method according to the invention is characterized in that when the MCMA server uses XML and the client server uses HTML, then the associated incoming conversion chain comprises an adaptation module integrated into the client server using a program written in Java language, also called servlet, intended to automatically convert HTML forms using service in an understandable XML document from MCMA server and vice versa.

According to another characteristic of the method which is the subject of the invention, the servlet reuses the names of the parameters of the HTML tag "input na e" as names of opening and closing XML tags, while the values of the HTML input parameters are converted into values of XML tags.

According to another characteristic of the method which is the subject of the invention, the HTML forms processed by the servlet include hidden parameters containing instructions controlling the running of said program.

According to another characteristic of the method which is the subject of the invention, the HTML forms processed by the servlet include hidden parameters containing information such as the type of service call or even usage classes defining XML tags.

According to another characteristic of the method which is the subject of the invention, the HTML forms processed by the servlet include hidden parameters containing information such as the XSL files necessary for the conversion of the XML response from the MCMA server into an HTML document.

According to another characteristic of the method which is the subject of the invention, the servlet transfers the service call to the MCMA server after having converted it to XML format by passing through a client connection module integrated into the client server capable of communicating with an incoming connector. associated with the MCMA server. According to another characteristic of the method which is the subject of the invention, the client servers present the service calls in the form of an action, these actions being classes in object-oriented programming language which have a data structure and a method capable of encapsulating the call to one or more target application servers and / or to provide for possible processing provided by the MCMA server.

According to another characteristic of the method which is the subject of the invention, each action forming a service call is transferred between servers in the form of a structured text document written in extensible markup language of the XML type or the like.

According to another characteristic of the method which is the subject of the invention, the action forming a call comprises an identifier corresponding to the identifier of the target service, input attributes representing the parameters of the service call and possible output attributes representing the result of the service intended to be returned to said client server

According to another characteristic of the method which is the subject of the invention, the application servers use an integration software layer and that the client servers use a usage software layer deduced from said integration layer and in that the structure of data from a service call action cooperates with said usage layer.

Other characteristics and advantages of the invention (such as the simplification / reliability of regular modifications in application servers: replacement, duplication, upgrades) will appear in the light of the detailed description below and of the drawings in which:

- Figure 1 is a schematic representation of a computer system implementing the communication method between client servers and application servers according to the invention;

- Figure 2 illustrates the communication method according to the invention;

- Figure 3 is a diagram detailing the structure of the MCMA server implemented in the computer system of Figure 1;

- Figure 4 schematically shows an incoming conversion chain and an outgoing conversion chain according to the invention; - Figure 5 is a list of connectors and connections according to the invention; and

- Figure 6 details a module of an incoming conversion chain operating the HTML / XML conversion according to the invention.

With reference to FIG. 1, the computer system described by way of example is the computer system of a financial institution and more precisely of a bank. This computer system referenced 1 provides a plurality of financial services managed by specialized application servers and accessible by employees or users through a plurality of client interfaces 2.

For example, customer interfaces 2 can be fixed digital telephones 2a or mobile phones 2b, ATMs

(not shown), branches receiving 2c mail or 2d faxes, branch sales offices (not shown), DAB self-service ATMs (not shown), personal computers for home banking using a 2g or minitel 2f Internet connection, 2nd interactive televisions, etc.

These client interfaces 2 are connected by appropriate networks 3, individualized in 3-1 to 3-6, to client servers 4, individualized in 4-1 to 4-6. The servers 4 are developed in a specific way according to the technical possibilities of each interface 2 and of each network 3. Each interface and its associated network are also called channel.

The computer system 1 further comprises a plurality of application servers 5, such as for example, a bank server 5a, a stock exchange server 5b, an insurance server 5c, a credit server 5d, or other 5e. Each of these servers 5 implements each comprising at least one specific application 6, respectively referenced 6a to 6e.

Furthermore, a server 7 is interposed between the client servers 4 and the application servers 5. This server 7, called MCMA (acronym for Multi Channel and Multi Application) is common to all of the client servers 4 and suitable for their provide all of the applications available 6 on the application servers 5 to which it is also connected, according to a chosen communication method.

It should be noted that preferably, the MCMA 7 server is not only used to route data from client servers to application servers and vice versa, but also is used to operate various processing operations, such as for example identification / authentication of the end user and / or of the client server, degraded mode management (for example management of replicated databases making it possible to provide information despite the unavailability of the application servers concerned), control of authorization, audit of service calls or their pricing, ...

Each client server 4 adapts the call sent by its corresponding channel, such as for example the WAP client server from a message sent by a mobile phone, in a predetermined form and the sending to the MCMA server 7 according to a format and protocol expected by the MCMA 7 server.

The MCMA 7 server offers several formats and protocols in order to adapt to the technological constraints of a client server 4 and any network 3. The formats offered by the MCMA 7 server can be binary file (serialization of Java object, or C ++, Visual Basic, etc.) or "flat" text, XML file.

The protocols offered by the MCMA 7 server can be IP, HTTP, CORBA / IIOP, JRMP, DCOM, COM, COM +, etc.

The means used to allow communication between the client servers and the MCMA server 7 include software modules constituting a so-called "incoming" conversion chain which will be detailed later.

The communication method between the client servers 4 and the application servers 5 of the distributed computer system 1 is structured around the concept of action. This process is more particularly to present each service call in the form of an action.

As a reminder, an action is a class in object-oriented programming language (Java, C ++, etc.), having attributes / input fields representing the parameters of the service call and possible attributes / fields of output representing the result of the service intended to be returned to said client server and a method able to encapsulate the call to one or more target application servers and / or to provide possible processing provided by the MCMA 7 server.

Thus, each service corresponds to an action which encapsulates the call intended for the target application server or servers via the MCMA 7 server or else processing implemented directly by the MCMA 7 server.

The application server 5 housing the target service 6 receives the call from the target service, sent by the MCMA server 7, according to the specific formats and protocols of the application server 5 and returns the response (service result or error) to MCMA 7 server always according to its specific formats and protocols of the application server 5.

With reference to FIG. 2, the communication method comprises the following steps:

- step (i), instantiation

This involves creating, for example by the minitel 4-6 server, a class instance (according to the terminology of object-oriented programming) of action type which corresponds to the service "current account balance N" following a call request (request) emanating from a 2g client interface, in this case a minitel used by a user who wishes to know the balance of his current account;

- step (ii), the minitel 4-6 server values the input attributes of the action according to the data supplied by the user and sends the action to the MCMA 7 server according to the protocol and format of its choice from those proposed by the latter (“anAction” is an instance (an object, a variable) of the class (of type) “FxAction” (an FxAction is the technical name which designates generic action);

- step (iii), the MCMA 7 server receives the action and executes it by rolling out the associated method. This associated method has a behavior which varies according to the values of all or part of the input attributes. It is among other things here that additional functionalities can be provided such as user identification, authorization control, audit of service calls, etc .;

step (iv), the integration layer which will be described in more detail below of the MCMA server 7 is requested by the action "current account balance" so that it makes the corresponding target service call on the application server concerned (here the bank server 5a) according to the specific communication formats and protocols of the latter. (entryPoint.invoke (uneAction) is an instruction in object language, in this case it is the instruction which causes the method associated with any action "uneAction" to run in the MCMA 7 server); step (v), the application server executes the requested service described by the call, namely the reading or the calculation of the account balance and returns the result corresponding to the MCMA 7 server according to the format and the specific communication protocol of the application server;

- Step (vi), the integration layer of the MCMA server 7 restores the results data supplied by the application server to the method associated with the action. It therefore values the action result attributes, as a function of the data received by the application server 5a. It is among other things here that additional functionalities can be provided such as the audit of service responses, pricing, degraded mode (ex: in case of error, read the balance in the database replicated daily), etc. .

- step (vii), When the method associated with the action is finished, the MCMA 7 server returns the action to the minitel 2g via the minitel 4-6 server;

- step (viii), the minitel receives and displays the result.

Referring to FIG. 3, the structure of the MCMA server 7 will be more particularly detailed.

Preferably, the software architecture of the MCMA 7 server is in particular made up of two distinct software layers: a usage layer 10 and an integration layer 12. It should be noted that the integration layer can be entirely resident in the MCMA 7 server as described in Figure 3 or else reside in part in the MCMA 7 server and partly in one or more integration servers as illustrated in Figure 4.

The usage layer 10 is an intermediate layer which completes, simplifies and facilitates the use of the services provided by the application servers 5. It is the usage layer 10 which is used as an interface to access the d layer. integration 12 from client servers 4.

The usage layer 10 is made up in particular of all the actions available from the MCMA server 7 (see description above) and of “object of use” type classes.

A usage object can be considered as a view of one or more data structures used by the application servers 5. This view is a representation common to all the equivalent data structures in the application servers concerned. For example, the usage object "UsageAccount" could be used to represent a deposit account of a bank server 5a, or even a securities account of the stock exchange server 5b.

The inheritance mechanism provided by the class concept (object-oriented programming) further strengthens the pooling of information. For example, deposit accounts could be represented by "UsageCompteDépôt" usage objects that inherit attributes (member data) from the usage usage "UsageCompte" and that only have the additional attributes specific to an deposits compared to an abstract and generic "UsageCompte" account. This the latter can also be inherited by several other types of usage object (known as "sons") such as "UsageCompteEpargne", "UsageCompteTitres", etc. Thus an action representing the service "list of accounts of a client" can provide the list of all types of accounts hosted by all application servers managing accounts. Such an action has an output attribute of the “UsageCount table” type which will contain, for example in profit for a client, by polymorphism (concept of object-oriented programming): a deposit account, a savings account and an account titles, each managed by different application servers.

Thus the set of usage objects facilitates and simplifies the representation of data structures which are by definition variable depending on the application server. The objects of use allow the mutualization of the formats of exchanges between the client servers and the MCMA 7 server whatever the application server concerned.

The usage layer 10 also makes it possible to stabilize the formats supplied to the client servers in the event of modification in an application server 5, or the replacement of one of them by a new application server. For example, if we consider that the bank server 5a has a data structure "account balance" which aggregates the accounting balances, value and species of an account, and these different balances are therefore represented in the class "UsageSolde" in order to be available to client servers. The replacement of the bank server 5a by a new application server which does not have a cash balance, will not entail any modification of the usage object "UsageSolde" and therefore will not require the modification of client servers. The missing information will either be filled in at a default value, or calculated by the MCMA 7 server.

It should be noted that if the new banking application server has new information concerning the balance (ex: balance at the end of the previous month), the usage object "UsageSolde" may be enriched with a new attribute.

The usage layer 10, by these contributions in simplification and stabilization of the formats of exchanges with the client servers, thus facilitates the management of regular modifications in the application servers (replacement, duplication, evolutions).

The information contained in the usage data classes comes from the application servers 5. For example, the accounting balance data of the account usage object comes from the bank server 5a. To enhance their output attributes, the actions of the usage layer call the integration layer 12 (and the additional services layer 11 for the functionalities of the MCMA server 7 which are not available in the application servers).

Thus, it is not the usage layer 10 which is in charge of communication with the application servers 5 but the integration layer 12.

The integration layer 12 is divided into two subsystems: a routing subsystem 13 and an integration subsystem 14 comprising software modules forming conversion chains, called "outgoing", with each of the application servers 5. Only the modules 14a and 14b have been represented corresponding respectively to the banking servers 5a and the stock exchange 5b

The sub-routing system 13 is the entry point for the actions of the usage layer 10. It is responsible for determining as a function of the data represented by a usage object (eg type of account, number of the account, customer number) the application server (s) concerned and therefore the integration module (s) 14 to whom to delegate the communication. For the integration modules 14 concerned, the sub-routing system 13 provides the usage object and the service to be called in the application server.

The integration modules 14 constituting an outgoing conversion chain are therefore responsible for communication with a specific application server 5 according to the formats and protocols expected by this application server. They are also capable of converting specific data structures from the application server into an object of use and vice versa. Such an outgoing conversion chain will be explained in more detail later.

The work performed by each component of the MCMA server 7 will be illustrated in the following example: consultation of the account X of a client Y on the application server 5a.

The action "list of balances of all accounts of a customer" will first search, via a service called "CRM" (acronym of Customer

Relation Management (i.e. Customer Relationship Management) of the additional service layer 11, the list of accounts held in the database 15. Then for each account number, will ask the integration layer 12 for the corresponding balance by providing it with a usage object "UsageSolde" with unspecified balances. The routing subsystem 13 will, depending on the account number and the type of account, determine the outgoing conversion chain of the integration subsystem 14 concerned and ask it to make the call to the appropriate target service in it. providing the empty object of use. The integration subsystem 14 will call the target service via the formats and protocols expected by the application server concerned, fill the object of use with the results supplied by the application server and return the object d usage thus informed to the routing subsystem 13 which will return it to the requesting action.

To transmit the actions forming a service call between the various servers of the computer system 1, files written preferably with a structuring language also called extensible markup language, such as XML (English acronym for extensible Markup Language) are used. .

A structured document is a collection of sets of information, each associated with a type and attributes, and composed together according to mainly hierarchical relationships. Such a document makes it possible in particular to distinguish the different subsets of information making up the document. In contrast, in a so-called linear document, the content information of the document is mixed with the presentation and typing information.

A structured document includes separation marks for the different sets of information in the document. In the case of XML format, these marks called “tags” are of the form “<b>” (opening tag) and “</b>” (closing tag), the first marker indicating the beginning of a set of information called “b And the second the end of this set.

Unlike HTML (HyperText Markup Language), XML is not semantically frozen. It allows you to define your own tags, which makes it adaptable and therefore able to store all types of information.

A structured document is associated with what is called a structure diagram or DTD (Document Type Definition) defining in the form of rules the structure and the type of information of each set of information in the document. A schema is made up of nested groups of information set structures, these groups can be ordered sequences, groups of alternative elements or groups of necessary elements, ordered or unordered.

The XML documents received by the servers of the computer system 1 are processed by a corresponding application programming interface (API, Application Programming Interface) written in object oriented language and serving as an XML parser (or XML parser) to analyze and decode the tags of these documents.

Thus, each action (representing a usage service and the usage data used if applicable) is associated with a description written in XML language. zu

Such a markup language makes it possible to provide data formats without being restricted to a technical platform, be it hardware or software.

In addition, the representation in the form of text written in XML language of each action makes it possible to simply create, via a simple text editor, an XML file describing one or more service call actions.

The result of its actions, also written in XML, will also be easy to interpret from a simple text editor.

It is interesting to rely on an extensible markup language of the XML type within the framework of data import / export functions in association with call requests (input attributes and output attributes respectively).

The implementation of such an XML type language is therefore done by associating an XML tag with each action, these tags themselves containing a tag for each input attribute and for each output attribute of the actions.

Very advantageously, the input attributes of the actions which correspond to processing of writing, creation or modification of data, are transferred (injected / imported) into the application servers via the MCMA 7 server in the form of a file. text written in extensible markup language such as XML or similar.

Data migrations to a computer system using an action-based and XML communication process will only require rewriting a data extraction program from the source system as an XML extraction file corresponding to actions by the MCMA 7 server.

In addition, any creation of new actions that correspond to write processing will be an additional data import solution for the next migration. For example, the creation of a new action, following a new need for a WEB client server, intended for address creation, will facilitate future imports of email addresses from a source computer system or will make it possible to complete the flow of data from a partner company providing data from people to prospect.

Likewise, the output attributes of actions which correspond to processing of reading, searching or consulting data are transferred (extracted / exported) from the corresponding application servers via the MCMA 7 server in the form of a text file written in Extensible markup language such as XML or the like.

The advantages provided by the actions that can be described in XML are therefore also valid in the context of data export, when the bank is purchased or when periodic data flows are set up with the IT system of a partner company (B2B ).

When the current action (call request containing new data to be written in the requested target service) corresponds to a write service in the system (creation, modification, etc.), the operation is then called "import multi-engine "because the data in the XML file supplied as input are injected into the system via the MCMA 7 intermediate server.

Conversely, when the action used corresponds to a read service in the system (search, consultation, etc.), the operation is then called "multi-engine export", because the resulting XML file contains an extraction of the data from the system via the MCMA 7 intermediate server.

Such import / export of data in XML has the advantage of simplifying the processing of actions in an IT environment with several client servers and several service servers, via an MCMA 7 server.

The communications between the client servers 4 and the MCMA server 7 on the one hand, and between the MCMA server 7 and the application servers 5 on the other hand, use software conversion chains, called respectively inbound and outbound with reference to MCMA 7 server. The only invariant of these conversion strings is the use of XML messages representing actions to communicate with the MCMA 7 server.

Each incoming conversion chain is capable of ensuring communication between a given client server 4 and the MCMA server 7 according to a chosen communication protocol.

An incoming conversion chain is made up of different modules implemented on the client server 4 and on the MCMA server 7. Client server side 4 we have a client adapter module and a client connection module

The client adapter module adapts messages of the format specific to the client server to the XML format of the MCMA 7 server. The client adapter module is loaded, following a request (message to the specific format of the client server) initiated by the functional module of the client server ( “functional module” means the module providing the core of the functionalities specific to this client server, for example if the client server is a WEB server, this module provides the functionalities specific to a WEB server and manages data specific to a server WEB), the creation of corresponding XML messages for sending to the MCMA 7 server an action forming a service call, and vice versa, the analysis of the XML messages result returned by the MCMA 7 server to convert them back into a message in a format recognized by the client server or in error if necessary. This module is not responsible for exchanging XML messages.

The client connection module (or PLUG IN) 22 is responsible for communication 21 with an incoming connector (or IN connector) 20 of the MCMA server 7. This module is written in the technology of the client server. It is responsible for exchanging XML messages with a single type of incoming connector from the MCMA 7 server via a single type of protocol. It is only responsible for exchanging XML messages, not for their creation on sending or their analysis on reception.

According to the invention, in the case where the adapter module operates on a client server 4, such as the Web server, relying on HTML forms, the adapter module preferably uses a Servlet Java also called SERVLET ADAPTER. Such a module is more particularly detailed with reference to FIG. 6.

The CGI standard (Common Gateway Interface) is the standard which defines dynamic WEB pages (ie which call a server which performs processing such as reading from a database or writing, etc.) HTML forms are used (HTML tag <form action≈ "... server address ....">) with input areas (<input> tag) and buttons (<input type = "button" or "submit"> tag). A Servlet (contraction of "server applet") is a Java program which is executed by an http server and which allows you to dynamically build HTML or XML pages. This program or servlet is called by the HTML document by the <form> tag which has an "action≈" attribute which points to this program.

The object of this SERVLET ADAPTER program written in Java language is to automate the transcription of data from HTML forms managed by the client server into corresponding XML documents forming service calls to the MCMA 7 server. More specifically, the program concerns the conversion of HTML forms input data in XML tags and vice-versa.

Consider for example a user wishing to know the balance of his account on the Internet. The user then uses his personal computer 2f, a resident browser of the Netscape Communicator ™ type and an appropriate telecommunications operator (service provider) to access the Internet and more particularly to the website of his financial institution. This site is hosted on a 4-6 web server. Connection to the 4-6 server is carried out in a conventional manner via the URL address of this site. Having been connected to the site of his bank, the user will then move from the home page and request a particular service such as the balance of his current account.

In response to this request, the Web server will load into a database the HTML page corresponding to the called service (in this case "current account balance consultation"), and have it displayed on the user's computer. This page consists of an HTML form or document comprising in particular a certain number of fields to be filled in by the user, for example the number of the current account whose balance is requested. The user therefore fills in the requested data and sends it back to the Web server 4-6 in the form of a corresponding URL address. Preferably, this sending is operated in POST mode, that is to say by masking the data, in particular for reasons of confidentiality.

This HTML document is returned with the data entered by the user directly to the adapter module and more particularly to the SERVLET ADAPTER program, for example thanks to a masked code of type <form action- 'servlet url "> where" servlet url " is the address of the program housed in the web server.

It is the responsibility of the adapter module to build a service call corresponding to the XML format upon receipt of this document.

First of all, the program deduces from a certain number of hidden tags in the form corresponding information such as for example the service call considered or the XSL files (Extensible Stylesheet Language) needed to convert responses from MCMA 7 server to HTML pages. These hidden tags also contain instructions of type "servlet: do" whose values are for example "call" which is the instruction to convert the form into XML and send it to the MCMA 7 server via the client connection module, or "build" which is the instruction to convert the document to XML but without sending it to the MCMA server

7, the transfer taking place with the transcription of a subsequent HTML document comprising the "call" instruction to which the first document will be concatenated. The "call" instruction is for example written in the form:

<input type = "hidden" name = "servlet: do" value = "call">

The hidden tags having been processed, the SERVLET ADAPTER program also processes the data entered by the user data which constitute the parameters of the service call, i.e. the attributes of the action corresponds to the '' service call considered (in this case the current account balance call).

The transcription of this data in XML format is carried out by the SERVLET ADAPTER program as follows: the names of the parameters of the HTML tag "input name" are automatically converted into opening and closing XML tags with the same names. The values of the HTML input parameters are converted into the values of the XML tags (values located between the associated opening and closing tags).

Consider the following example:

The initial HTML code <input name = "accountNumber" type = "text"></input> is converted to XML code <numeroCompte> 1234234516942103 l </numeroCompte> after the user is entered 12342345169421031 as the account number whose balance is requested.

Thus the sequences of input zones of the HTML document constitute the XML file to be sent to the business server. Building the web page using the "name" attribute of each tag in this way allows the call to the business server to be defined at the same time, resulting in significant development time savings.

Obviously a certain number of XML tags can be hidden like for example the tags defining the beginning of usage classes. We thus have:

<input type = "hidden" name- 'UsageEntiteTitulaire name = holder "> ... <input type =" hidden "name =" / UsageEntiteTitulaire "> which is transcribed in: <UsageEntiteTitulaire> ... </ UsageEntiteTitulaire>

The HTML document having been converted to the XML format expected by the MCMA 7 server and sent to the latter, the response is treated in a similar way thanks to the indication of the XSL page to be used to display the result on the screen of the user's computer via the appropriate HTML page.

On the MCMA 7 server side, there is therefore an incoming connector 20, encapsulated in the MCMA server 7 and written in the technology of the MCMA server 7. This connector comprises a communication module and a conversion module. The communication module is suitable for communicating with "customer connections" (PLUG IN) using the same protocol (indeed, several customer connections, each written in a different technology such as VisualBasic or Java for example, can be compatible with the same connector incoming if they are based on the same communication protocol).

The conversion module converts an XML message into an action type (in the sense of object-oriented programming) in MCMA 7 server technology and vice versa, this module is commonly called the "XML parser".

Each outgoing conversion chain is capable of ensuring communication between an application server 5 and the MCMA server 7 according to a chosen communication protocol.

An outgoing conversion chain is made up of different modules implemented on the MCMA server 7 and on a separate server called the integration server 28.

On the MCMA 7 server side, there is an outgoing integration connector (or OUT connector) 24, encapsulated in the MCMA 7 server and written in the technology of the MCMA 7 server. This connector comprises a communication module and a conversion module.

The communication module is suitable for communicating with integration server connections (or PLUG OUT) 26, using the same protocol (in fact, several integration server connections, each written in a different technology such as C or COBOL for example, can be compatible with the same incoming connector if they are based on the same communication protocol);

The module for converting an object (in the sense of object-oriented programming) of the action type, in MCMA 7 server technology, into an XML message and vice versa. It is the same “XML parser” module as that used in the “incoming connector” if the same XML format is used (note: an MCMA 7 server can have several different XML formats: canonical, compact, etc.)

On the integration server side 28 there is therefore a connection module, integration server (or PLUG OUT) 26, a converter module and an application server connection module.

The integration server connection module 26 is responsible for communication 23 with an outgoing integration connector 24 of the MCMA server 7, this server connection module is encapsulated in the integration server, is written in the server technology d integration, it is responsible for exchanging XML messages with a single type of connector coming out of the MCMA 7 server via a single type of protocol, it is only responsible for exchanging XML messages, not for their analysis the reception of the call or their creation to the sending of the response.

The converter module converts messages in XML format from the MCMA 7 server into messages in the format specific to the application server, including the integration server, the converter module is responsible for analyzing XML messages representing actions forming service calls sent by the MCMA 7 server to convert them into a service call message in the specific format of the application server, including the integration server, and vice versa, creating XML messages to return to the MCMA 7 server as a result of a service call (this result, or this error if applicable, was initially provided by the application server (including the load integration server), this module is not responsible for exchanging messages.

The application server connection module is responsible for communicating messages with the application server, including the load integration server via a communication protocol specific to this application server, it is only responsible for the exchange of messages, not from their creation to sending or from their analysis to reception.

According to the communication protocol chosen for the incoming or outgoing chain, each service call is presented in the form of an action which is a class in object-oriented programming language, having attributes / input fields representing the parameters of the call of the service intended to be returned to said client server and a method able to encapsulate the call to a target server and / or to provide possible processing provided by the MCMA server 7.

The target server (MCMA 7 server, in the event of an incoming chain, application server in the event of an outgoing chain) in response to an action, is able to execute the latter in synchronous or asynchronous mode by rolling out the method associated with this action. For the same XML message the corresponding action is not the same if it is in the MCMA 7 server or in the integration server. The associated method will therefore not do the same work depending on whether one is in the incoming conversion chain (action of the MCMA 7 server) or the outgoing conversion chain (action of the integration server).

Thus for the incoming conversion chain, the XML message corresponds to an action by the MCMA 7 server, the corresponding method is executed in the MCMA 7 server. It generally allows any processing to be carried out on the input attributes / fields and / or send the service call via the corresponding outgoing conversion chain to the target application server (s) concerned so that it retransmits the service to the corresponding application server. When it receives the result of the service call, the MCMA 7 server, via the action method being executed, then performs any processing on the data thus returned by the application server (s) and values the output attributes of the action which is then sent back to the sending client server, via the corresponding incoming conversion chain and in the format chosen by the latter.

In the case of an outgoing conversion chain, the XML message corresponds to an action of the integration server, the corresponding method is executed in the integration server. It generally makes it possible to convert the XML message into a message forming a call for services in the specific format of the application server including the integration server, then to send it to this application server via the specific protocol of the application server to provide the service. When it receives the result of the service call, the integration server, via the action method being executed, converts the result message to the specific format of the application server for which it is responsible, message result in XML format of the MCMA 7 server and the return. To carry out its work, the integration server relies on the modules presented above during the description of the components of the outgoing conversion chain.

In practice, the incoming conversion chain allows a client server 4 having specific formats and language to communicate with the MCMA server 7 whose language and format are different from these specific language and format.

For example, consider that the client server 4 is a dynamic Web server written in ASP.Net, to access application servers via the Internet. The client server 4 uses for format XML messages which are different from the XML format of the MCMA server 7, and let us consider that on the MCMA server side 7, written for example in Java, the incoming connector 20 uses the SOAP protocol.

The corresponding incoming conversion chain therefore requires the client server side development of a client adaptation module to transform the XML messages from the client server into messages in XML format from the MCMA 7 server and vice versa. The client server 4 will also host a client branching module 22 written in ASP.Net and using the SOAP protocol in order to communicate with incoming connector 20 to send the XML message created by the client adaptation module and recover the response from the MCMA server 7 .

The MCMA 7 server can also include outgoing software conversion chains. For example, consider that the application server 5 is a banking application server written in COBOL, it uses flat text messages for format with data delimited by special characters such as "; »(CSV format). The banking application server also uses the IP protocol for its communications with client systems as follows: each text message sent or received by the banking application server is preceded by a header consisting of 6 digits aligned to the right and supplemented by zeros on the left if necessary, then a space (white, ASCII character 32). This header gives the size of the following text message (number of bytes to read, after the blank), for example: "003585 datai; data2; ... ". Consider furthermore that on the MCMA 7 server side (written for example in C ++), the outgoing connector 24 uses the IIOP protocol.

The corresponding outgoing conversion chain therefore requires the development of an independent integration server written for example in Java to adapt the calls sent by the MCMA 7 server in XML via the IIOP protocol to calls of text messages in CSV format via the protocol IP as described above and vice versa. The application server 5, like the MCMA server 7, will not undergo any modification. To perform its work, the integration server 28 hosts the "integration server connection module" 26 written in Java and using the IIOP protocol in order to communicate with outgoing connector 24 to receive the XML messages forming a service call sent by the MCMA 7 server. The heart of the integration server is the converter module, written in Java, responsible for converting XML messages from the MCMA 7 server to a text message in CSV format expected by the banking application server 5. Finally, the server integration must be completed by the development of an application server connection module, written in Java and using the IP protocol (as described above) in order to communicate with the banking application server to send the CSV text message created by the converter module and recover the response from the banking application server.

The “converter” module of the integration server or the “client adaptation” module of the client server can, depending on the language used and the formats to be converted, be based on products from the market for software package development tools to facilitate their work.

For example, converting XML to flat files and vice versa can be implemented using an XSLT "Xalan" parser from the Open Source organization "Apache". Another case in point: converting an XML format to another XML format, or to database tables, can be implemented by a converter based on the “Liquid Data” product, sold by company "BEA".

Generally, the execution of service calls is of the synchronous or asynchronous type. The incoming connectors 20 and / or outgoing 24 are synchronous or asynchronous.

With reference to FIG. 5, a list lists the different formats and languages capable of being converted by the conversion chains according to the invention. Each connector of the MCMA 7 server, whether incoming or outgoing, is associated with a protocol which may belong to the group formed by the protocols IP, HTTP, CORBA / IIOP, JRMP, DCOM, COM, COM +, SOAP or the like.

Each connector can be associated with client or integration server connections, dedicated to the connector protocol and written in one of the languages belonging to the group formed by Java, C ++, Visual Basic, COBOL, PHP, PERL or the like.

Preferably, the choice of connector associated with an application server is done by setting up the MCMA 7 server. This setting indicates information such as the outgoing connector used and the data necessary for it to establish a connection to the server. 'integration. For example, an outgoing IP connector will have IP connection parameters such as the IP address and port of the integration server and the time after which it considers that the integration server will no longer respond (time out). Example of definition of these parameters in a file in format

INI from Microsoft Windows (case where the MCMA 7 server would be written for example in Visual Basic):

[TCPIPJDUT] Host26 = 192.5.60.183 Port26 = 6868 TimeOut26 = 5

The software conversion chains according to the invention make it possible to reduce the costs of integration and operation of the MCMA 7 server with the client servers and the application servers by: - structuring the terms of integration of any client server with the MCMA 7 server (XML representing an action forming a service call provided by the MCMA 7 server, client connection, incoming connector);

- structuring the methods of integration of the MCMA 7 server with any application server (XML representing an action forming a service call expected by the MCMA 7 server, outgoing connector, connection to the integration server, integration server);

- pooling the communications layers on the MCMA 7 server side (reuse of incoming connectors for all client servers, reuse of outbound connectors for all application servers);

- preparing adaptation work for client servers (client connections are already provided by the MCMA 7 server development team, they are tested for the language used by the client server, the protocol and the incoming connector chosen);

preparing the development of the integration server (the integration server connection provides the starting strain for the integration server.

In practice, it is preferable that the client connections 22 and the application integration server connections 26 be developed by the same IT team as that responsible for developing the connectors of the MCMA server 7. If according to the language with which it is written the client server or the server integration, the customer connection does not exist, it is this team that is best placed to carry out this new module (enrichment of the "integration kit" of the corresponding connector and therefore enrichment of the MCMA 7 server). For the same reasons, if the incoming or outgoing connector does not exist depending on the protocol chosen, the team responsible for developing the MCMA 7 server must develop the missing connector and the corresponding first connection to test it ( enrichment of the MCMA server integration kit 7).

The IT team in charge of developing inbound connectors, outbound connectors, client connections and server connections, will advantageously set up trace functionalities (creation of log files) when sending / receiving messages to facilitate identification of the component responsible for malfunction in the event of a breakdown or the identification of the "bottleneck" component in the event of performance problems.

Thus the specific developments (carried out by an integration project team) necessary for the integration of a client server or an application server with the MCMA 7 server are reduced to a minimum:

- for the integration of a new client server: development of the client adaptation module and development of the "glue" code between these two modules and the third functional module;

for the integration of a new application server: development of the converter module, development of the module application server connection and development of the "glue" code between these three modules.

These specific developments are also made more reliable by the reuse of existing connectors and connections that have already been tested.

Obviously, the illustrated embodiments have been given only by way of examples and are in no way limitative of all the solutions that can be implemented thanks to the present invention.

Claims

[1] Method for communicating within a distributed type computer system (1), a plurality of client servers (4) each having specific software and hardware means with a plurality of application servers (5 ) each having specific software and hardware means and each comprising at least one chosen application (6), the client servers (4) being directly connected to a single MCMA server which is in turn directly connected to all of the servers application (5), so that any service call from a client server to a given application server is first addressed by said client server to the MCMA server, the latter being responsible for routing it to the server application concerned and to pass back any information from the application server to the client server, each service call between a client server (4) and the MCMA server (7) cooperates with a language conversion chain and formats, characterized in that when the MCMA server (7) uses the XML language and the client server (4-6) the HTML language, then the associated incoming conversion chain comprises an adaptation module integrated into the client server (4-6) using a program written in Java language intended to automatically convert HTML forms calling for service into an XML document understandable by MCMA server (7) and vice versa. [2] Method according to claim 1, characterized in that said program reuses the names of the parameters of the HTML tag "input name" as names of opening and closing XML tags, while HTML input parameter values are converted to XML tag values. [3] Method according to claim 1, characterized in that said HTML forms processed by said program include hidden parameters containing instructions controlling the progress of said program. [4] Method according to claim 1, characterized in that said HTML forms processed by said program include hidden parameters containing information such as the type of service call or even usage classes defining XML tags. [5] Method according to claim 1, characterized in that said HTML forms processed by said program include hidden parameters containing information such as the XSL files necessary for converting the XML response from the MCMA server (7) into an HTML document. [6] Method according to claim 1, characterized in that said program transfers the service call to the MCMA server (7) after converting it to XML format via a client connection module (22) integrated into the client server (4-6) capable of communicating with an associated incoming connector (20) integrated into the MCMA server (7). [7] Method according to claim 1, characterized in that said client servers (4) present the service calls in the form action, these actions being classes in object-oriented programming language which have a data structure and a method capable of encapsulating the call to one or more target application servers (5) and/or to provide possible processing provided by the MCMA server (7). [8] Method according to claim 1, characterized in that each action forming a service call is transferred between servers in the form of a structured textual document written in extensible markup language of the XML type or the like. [9] Method according to claim 1, characterized in that the action forming a call comprises an identifier corresponding to the identifier of the target service, input attributes representing the parameters of the service call and possible attributes of output representing the result of the service intended to be returned to said client server [10] Method according to claim 1, characterized in that said application servers use an integration software layer and that the client servers use a usage software layer deduced from said integration layer and in that the structure data of an action forming a service call cooperates with said usage layer.