WO2004056071A1

WO2004056071A1 - Communication method between servers with data format conversion and device therefor

Info

Publication number: WO2004056071A1
Application number: PCT/EP2003/051007
Authority: WO
Inventors: Jean-Paul Carmona
Original assignee: Sema
Priority date: 2002-12-17
Filing date: 2003-12-15
Publication date: 2004-07-01
Also published as: AU2003298359A1; FR2848759A1

Abstract

The invention concerns a method and a device for communication among a plurality of client servers (4) and a plurality of application servers (5), the client servers (4) being connected to a single MCMA server (7) which in turn is connected to the set of application servers (5), such that any service call from a client server addressed to a given application server, is first addressed by said client server to the MCMA server (7) for the latter to retransmit same to the application server (5) concerned and to transmit back possible data from the application server (5) to the client server (4). The invention is characterized in that it comprises at least one incoming and/or outgoing conversion chain capable of converting the calls written in the MCMA server language and format into language and format expected by the client server (4) and/or the application server (5) and of converting the replies from the client server (4) and/or the application server (5) written in the client server and/or application server language and format into replies written in the MCMA server language and format.

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.

There are different servers of distinct 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 here defined generally as any computer processing, this term covers both the provision of specific information such as an account number, 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 transactions linked to the management of deposit accounts, a credit server which manages the loans granted by the bank to its customers, a stock market management server (stock market engine Investiciel marketed by the company 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 the client servers and the application servers via the MCMA server is not entirely satisfactory insofar as it is necessary to relatively complex or unsuitable implementation, in particular as regards:

- 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 the 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 well as 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.

According to a general definition of the invention, the method uses an incoming and / or outgoing conversion chain capable of converting the written calls in language and format of the MCMA server into the language and format expected by the client and / or application server and converting the responses from the client server and / or the application server written in the language and format of the client server and / or the application server into responses written in the language and format of the MCMA server.

Such a method thus makes it possible to frame, facilitate and simplify the work of integrating an external client system (client interface) and / or an external application system (application server) by despite differences in format, language and protocol between client and / or application servers and the MCMA server.

According to another aspect of the invention, each incoming or outgoing conversion chain (the MCMA server can have incoming conversion chains and / or outgoing conversion chains) comprises:

- an incoming or outgoing connector, integrated into the MCMA server,

a client or application connection, inserted between the incoming or outgoing connector and the client or application server, and capable of communicating in the language, format and protocol of the MCMA server, and

an integration element forming an adapter / converter connected to the client or application connection on the one hand and to the client or application server on the other hand, said converter being able to convert written calls or responses into language and format MCMA in language and format expected by the client or application server and vice versa.

Preferably, the language and format of the MCMA server are of the text file type written in extensible markup language of the XML type or the like.

In practice, the language, format and protocol of the client server and / or the application server belong to the group formed by “flat” text or binary files, object serialization of the java, C ++, Visual Basic, or similar type. and IP, HTTP, CORBA / IIOP, JRMP, DCOM, COM, COM + or similar protocols. According to another aspect of the invention, each incoming or outgoing conversion chain is able to communicate according to a communication protocol according to which 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 service call intended to be returned to said client server and a method capable of encapsulating the call to one or more target application servers and / or to provide for any processing provided by the MCMA server.

In practice, the MCMA server upon receipt of the action executes the latter in synchronous or asynchronous mode by rolling out the method associated with this action to carry out any processing on the attributes / input fields and / or send to (x) target application server (s) concerned the service call in the specific format and protocol expected by said application server (s) via the corresponding outgoing conversion chain.

Each application server called operates its processing and provides the expected service, in its specific format, to the MCMA server, via the corresponding outgoing conversion chain, the MCMA server then operating any processing on the data thus returned by the one or more application servers and values the output attributes of the action which is then sent back to the sending client server, if necessary via the corresponding incoming conversion chain.

Several application servers can be called upon during the execution of the same action. In this case, the different servers application can be called successively or simultaneously depending on the service provided.

The use of action to communicate between client servers and the MCMA server, has the advantage, in an object-oriented programming context, of being relatively simple and easy to implement where one wishes:

- benefit, thanks to the inheritance between the classes, of a pooling of functionalities present in a recurring way in the calls of services and which can thus be implemented in a simple way directly by the MCMA server, such as for example the '' user identification, authorization control, audit of service calls (for example for operation and performance checks, or for their pricing);

- standardize the communication process with client servers;

Other characteristics and advantages of the invention (such as, for example, 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; and

- Figure 5 is a list of connectors and connections 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, the customer interfaces 2 can be fixed digital telephones 2a or mobile 2b, ATMs (not shown), branches receiving mail 2c or faxes 2d, branch sales offices (not shown), ATM machines (not shown), personal computers for home banking using a 2f or minitel 2g 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 specifically according to the technical possibilities of each interface 2 and each network 3. Each interface and its associated network are also called a 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 serves to operate various processing operations, such as for example the identification / authentication of the end user and / or 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), authorization control, audit of service calls or their pricing, ...

Each client server 4 adapts the call made by its corresponding channel, such as for example the WAP client server from of a message sent by a mobile telephone, in a predetermined form and the sending to the MCMA 7 server 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 more particularly consists in presenting 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 / output fields representing the result of the service intended to be returned to said client server and a method capable of encapsulating the call to one or more servers of target applications and / or to provide for 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 the action type which corresponds to the “current account balance” service N »following a request 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 (ii), 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, based on 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 FIG. 3 or else reside partly in the MCMA 7 server and partly in one or more integration servers as illustrated in FIG. 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 wise layer 10 which is used as an interface to access the 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. The latter can also be inherited by several other type of usage object (called "son") 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 as a result for a client, by polymorphism (concept of object-oriented programming): a deposit account, an account savings account and a securities account, 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 mutualisation 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 modification of the 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), we can enrich the usage object "UsageSolde" 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 subdivided into two subsystems: a routing subsystem 13 and an integration subsystem 14 comprising software modules forming conversion chains, called "outgoing", with each of the servers of 'application 5. Only the modules 14a and 14b have been represented corresponding respectively to the banking servers 5a and the stock exchange 5b

The routing subsystem 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, account number , customer number) the application server (s) concerned and therefore the integration module or modules 14 to which to delegate the communication. For the integration modules 14 concerned, the routing subsystem 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 client" will first search, via a service called "CRM" (acronym for Customer Relation Management, that is to say Customer Relationship Management) of the additional service layer 11, the list of account numbers held in the database 15. Then for each account number, will ask the integration layer 12 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 usage object with the results provided by the application server and return the usage object thus informed to the routing subsystem 13 which will return it to it to the plaintiff 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 start of a set of information named "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.

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 in the context 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.

Thus data migrations to a computer system using an action-based communication method and via XML will only require rewriting a program for extracting data from the source system in the form of an XML extraction file corresponding to actions of 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 complete the data flow 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 is 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 intermediate server

MCMA 7. 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.

According to the invention, 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 incoming and outgoing with reference to the 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 functionality specific to this client server, for example if the client server is a WEB server, this module provides the functionality specific to a WEB server and manages data specific to a WEB server), the creation of corresponding XML messages for sending to the MCMA 7 server an action forming a service call, and conversely, the analysis of the messages XML result returned by the MCMA 7 server to reconvert them 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 1 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.

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 message forming a service call in the specific format of the application server, the integration server responsible for, and vice versa, the creation of XML messages to be returned to the server MCMA 7 as a service call result (this result, or this error if applicable, was initially supplied by the application server including the integration server to the load), this module is not responsible for the exchange of 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 attributes / input fields and / or send to the target application server (s) concerned the service call via the corresponding outgoing conversion chain 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, result message in XML format from the MCMA 7 server and returns it. 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 with specific formats and languages to communicate with the MCMA 7 server 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 application server banking is preceded by a header made up of 6 figures aligned on the right and supplemented by zeros figures on the left if necessary then of a space (white, character ASCII 32). This header gives the size of the following text message (number of bytes to read, after the blank), for example: “003585 datal; 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 text message CSV created by the converter module and retrieve 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 write 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 INI format of 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 awaited 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 integration server, the client 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 as well than the first corresponding connection to test it (enrichment of the MCMA 7 server integration kit).

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 application server connection module 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, characterized in that each service call between a client server (4) and the MCMA server (7) cooperates with a first language and format conversion chain and/or in that each service call between the MCMA server (7) and an application server (5) cooperates with a second language and format conversion chain, said second chain conversion being distinct from said first conversion chain.

[2] Method according to claim 1, characterized in that said client servers (4) present the service calls in the form of actions, 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 for possible processing carried out by the MCMA server (7).

[3] 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.

[4] 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

[5] Method according to claim 4, characterized in that the input attributes corresponding to a writing service of the creation or modification type are imported into the corresponding application servers (5) in the format of an XML file, via the MCMA server (7).

[6] Method according to claim 4, characterized in that the output attributes corresponding to a reading service of the search or consultation type are exported from the corresponding application servers (5) in the format of an XML file, via the MCMA server (7).

[7] 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 from an action forming a service call cooperates with said usage layer.

[8] Method according to any one of the preceding claims, characterized in that the computer system (1) is of the type to offer financial services.

[9] Method according to claim 8, characterized in that the client servers (4) cooperate with client interfaces (2) constituted in particular by digital telephones, automatic teller machines, branches, branch sales offices, terminals self-service sales, personal computers for home banking, interactive televisions.

[10] Method according to claim 8, characterized in that the application servers (5) belong to the group formed by customer database managers, financial telephone centers, external financial databases, type applications credit, deposit-savings, title, insurance, and finance.

[11] Method according to claim 1, characterized in that the language, format and/or protocol of the client server (4) and/or the application server (5) belong to the group formed by the text or binary files “to flat”, XML, object serialization of the Java, C++, Visual Basic, Perl, COBOL, PHP or similar types and the IP, HTTP, CORBA/IIOP, JRMP, DCOM, SOAP or similar protocols.

[12] Method according to claim 1, characterized in that each incoming conversion chain comprises an adaptation module and a client connection module (22) integrated into the client server (4) and an associated incoming connector (20) integrated into the MCMA server (7).

[13] Method according to claims 3 and 12, characterized in that said client adaptation module adapts the messages from the format specific to the client server (4) to the XML format of the MCMA server (7) and vice versa, in that said module client connection (22) exchanges XML messages with the MCMA server (7) according to a single type of protocol and in that said incoming connector (20) integrated into the MCMA server (7) is capable of exchanging messages according to the protocol of said client connection (22) and converts XML messages into action type objects in MCMA server technology (7) and vice versa.

[14] Method according to claim 1, characterized in that each outgoing conversion chain uses an integration server (28) interposed between the MCMA server (7) and the corresponding application server (5).

[15] Method according to claim 1, characterized in that each outgoing conversion chain comprises an outgoing connector (24) integrated into the MCMA server (7) and an integration server connection (26) and a converter module integrated into the MCMA server. integration (28).

[16] Method according to claims 3 and 15, characterized in that said converter module adapts the messages from the format specific to the application server (5) to the XML format of the MCMA server (7) and conversely, in that said integration server connection (26) exchanges XML messages with the MCMA server (7) according to a single type of protocol and in that said outgoing incoming connector (24) integrated into the MCMA server (7) is capable of exchanging messages according to the protocol of said integration server connection (26) and operates the conversion of XML messages into action type objects in the MCMA server technology (7) and vice versa.

[17] Communication device between a plurality of client servers (4) and a plurality of application servers (5) each comprising at least one selected application (6), the client servers (4) being connected to a single MCMA server (7) which is in turn connected to all the application servers (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 (7) responsible for the latter of routing it to the application server (5) concerned and of sending back possible information from the application server (5) to the client server ( 4), characterized in that it comprises at least one incoming and/or outgoing conversion chain each capable of converting calls written in the language and format of the MCMA server into the language and format expected by the client server (4) and/or the application server (5) and converting the responses from the client server (4) and/or the application server (5) written in the language and format of the client server and/or application server into responses written in the language and MCMA server format.

[18] Device according to claim 19, characterized in that each incoming and/or outgoing conversion chain is capable of communicating with a client server (4) and/or a server application (5) according to a communication protocol according to which 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 capable of encapsulating the call intended for one or more target application servers and/or of providing for possible processing carried out by the MCMA server.

[19] Device according to claim 18, characterized in that the MCMA server, in response to an action, is able to execute the latter in synchronous or asynchronous mode by unrolling the method associated with this action to carry out possible processing on the input attributes/fields and/or send to the relevant target application server(s) the service call in the specific format and protocol expected by said application server(s) via the corresponding incoming and/or outgoing conversion chain, each called application server carrying out the processing and providing the expected service, in its specific format, to the MCMA server, via the corresponding outgoing conversion chain while the MCMA server then operating possible 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.