WO2004039039A1

WO2004039039A1 - Method for communication between servers and device therefor

Info

Publication number: WO2004039039A1
Application number: PCT/EP2003/050726
Authority: WO
Inventors: Jean-Paul Carmona
Original assignee: Sema
Priority date: 2002-10-25
Filing date: 2003-10-16
Publication date: 2004-05-06
Also published as: FR2846498A1; AU2003288272A1

Abstract

The invention concerns a method and a device for communicating within a distributed computer system (1) a plurality of front office servers (4) including each specific software and hardware means with a plurality of back office servers (5) including each specific software and hardware means and comprising each at least one selected application (6), the front office servers (4) being directly connected to a single multi-channel multi-application (MCMA) server (7) which itself is directly connected to the plurality of back office servers (5). The invention is characterized in that said front office servers (4) present the service calls in the form of an action, said actions being object-oriented programming language classes having a data structure and a method adapted to encapsulate the call addressed to one or more target back office servers (5) and/or to ensure possible processing provided by the MCMA server (7).

Description

COMMUNICATION METHOD BETWEEN SERNORS AND DEVICE FOR IMPLEMENTING SAME

The present invention relates to a method of communication between servers and to a device for its implementation.

In the so-called distributed computer systems, such as in particular the 5 financial computer systems used by the banks or even by the 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).

15

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

20 of particular information such as an account number, such as the calculation of a balance or even a transfer.

The computer system of a bank generally includes a banking application server (example: financial engine marketed by the

25 SAB company) 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 market server for securities management (stock market engine Investiciel marketed by the company SEMA), an insurance server, etc.

30 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 fitted to bank counters, an ATM / ATM server associated with automated teller machines / distributors, a voice server which allows users to access 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.

Historically, each of the client servers was directly connected, as it was created, to each of the application servers which concerned it by dedicated point-to-point links.

The proliferation of application servers and client servers linked to the appearance of new channels such as the Internet and mobile telephony, but also to the development of new financial services such as insurance, makes such a point-to-point architecture extremely difficult to develop, manage, maintain and secure.

Thus, setting up a Web server requires complete writing by the IT teams responsible for developing the computer system, the interface and integration work with each of the application servers to which it is connected. and this, without being able to reuse the developments already carried out, for example for the Minitel server.

In recent years, point-to-point architecture has tended to be replaced by a “hub” type architecture. The connection between the client servers and the application servers is then performed by means of a particular server called MCMA server for multi-channel and multi-application server (also called middleware in English terminology) 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 between the client servers and the application servers via the MCMA server is not entirely satisfactory insofar as it is relatively complex to implement, in particular as regards:

- the pooling of functionalities implemented by the MCMA server on behalf of the client servers.

- integration of a client server with specific technological constraints; - regular changes in application servers

(upgrades, replacement, duplication, etc.);

Furthermore, the system proposed in the prior art does not deal with the import and export of data to or from application servers, within the framework of a project for migrating data from other computer systems for example.

Traditionally, when a data migration between two computer systems must be done (for example the migration of customers of a bank bought in the computer system of the buying bank). The migration process consists in extracting the data in the form of a file from the source computer system and then inserting its data directly into the databases of the various application servers hosting client data (clients' stock portfolios, account balances, etc.) . The extraction programs are made in a specific way according to the possibilities offered by the source system, they generally produce "flat" text extraction files image of the tables of the databases of the system of the purchased bank.

The extraction programs are also made specifically to distribute the data in the extraction files in the corresponding tables of the various application servers hosting client data (clients' stock portfolios, account balances, etc.).

This migration work is often also done within the framework of centralization at national level, of the IT systems (often different) of each regional subsidiary or during the implementation of periodic data flows with the IT system of a partner company. (B2B, ex: redemption of the customer file of a mail order company). At each migration, the programs for creating the extraction files must be done, but the diversity of the data to be migrated most often requires rewriting the programs for inserting the data.

The present invention therefore aims to remedy all these drawbacks.

It concerns a communication process between servers and the corresponding implementation system.

The present invention relates to a method for communicating a plurality of client servers each having specific software and hardware means with a plurality of application servers each having specific software and hardware means and each comprising at least one chosen application. According to this method, the client servers are directly connected to a single MCMA server which in turn is directly connected to all of the application servers, so that any service call from a client server to a server application application, is first sent by said client server to the MCMA server, responsible for routing the latter to the application server concerned and for sending back any information from the application server to the client server .

According to a general definition of the invention, the communication method consists in presenting each service call 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 and any 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 target application servers and / or to provide for any processing provided by the MCMA server.

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 the server (s) ) of target application (s) concerned with the service call in the specific format and protocol expected by said application server (s).

Each application server called performs its processing and provides the expected service, in its specific format, to the MCMA server, which 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. Several application servers can be called upon during the execution of the same action. In this case, the different application servers can be called successively or simultaneously depending on the service provided.

The use of action to communicate between the client servers and the MCMA server has the advantage, in an object-oriented programming context, of being 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: user identification, authorization control, audit of service calls or their pricing; - standardize the communication process with client servers;

- regular modifications in the application servers (replacement, duplication, upgrades).

According to a particular embodiment of the invention, each action is transferable from the client server to the MCMA server or from the MCMA server to the client server in the form of text files written in extensible markup language of the XML type or the like.

Other characteristics and advantages of the invention will become apparent 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; and FIG. 3 is a diagram specifying the structure of the MCMA server implemented in the computer system of FIG. 1.

Referring to Figure 1, the computer system described is a computer system of a financial institution such as 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 belong to the group formed by fixed digital phones 2a or mobile 2b, ATMs (not shown), branches receiving mail 2c or faxes 2d, branch sales offices (not shown) ), DAB self-service ATMs (not shown), personal computers for home banking using an Internet type 2f or minitel 2g 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 manner according to the possibilities techniques 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 each comprising at least one chosen application 6, individualized in 6a to 6e. For example, the servers are of the banking server 5a, stock exchange server 5b, insurance 5c, credit 5d, or other 5th type.

Furthermore, a server 7 is interposed between the client servers 4 and the application servers 5. This MCMA type server (multi-channel and multi-channel application) is directly common to all of the client servers 4 and is able to provide them with all of the services 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 the identification / authentication of the end user and / or the application 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 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 an expected format and protocol. by the MCMA 7 server.

The MCMA server offers several formats and protocols in order to adapt to the technological constraints of a client server 4 and any channel 3. The formats offered by the MCMA 7 server can be “flat” text or binary file, XML file, object serialization (java, C ++, Visual Basic, etc.). The protocols offered by the MCMA 7 server can be IP, HTTP, CORBA / IIOP, JRMP, DCOM, COM, COM +, etc.

According to the invention, the method of communication 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. 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 able to encapsulate the call to one or more target application servers and / or to provide possible processing provided by the MCMA server.

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

The application server 5 housing the target service 6 receives the call from the target service, sent by the MCMA server, according to the specific formats and protocols of the application server 5 and returns the response (service result or error) to the server MCMA 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 service "current account balance N" following a request from 'call (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 server according to the protocol and format of its choice among 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 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 server's specific communication format and protocol of application;

step (vi), the integration layer of the MCMA 7 server 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 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 server 7 is in particular made up of two distinct software layers: the usage layer 10 and the integration layer 12.

According to a definition of the invention, the usage layer 10 is an intermediate layer which supplements, 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 integration layer 12 from the client servers 4.

The usage layer 10 consists in particular of all of the actions available from the MCMA server (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 application servers 5. This view is a representation common to all equivalent data structures in the relevant application servers. 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 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 mutualisation of the formats of exchanges between the client servers and the MCMA 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 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 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 modules, a routing module 13 and an integration module 14 for each application server 5.

The routing module 13 is the entry point for the actions of the usage layer 10. It is responsible for determining according to the data represented by a usage object (eg type of account, account number, n ° of the client) the application server (s) concerned and therefore the integration module (s) 14 to which to delegate the communication. For each integration module 14 concerned, the routing module 13 provides the usage object and the service to be called in the application server.

Each integration module 14 is responsible for communication with a specific application engine according to the formats and protocols expected by this application server. It is also capable of converting specific data structures from the application server into an object of use and vice versa.

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 account numbers held in the 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 module 13 will, depending on the account number and the type of account, determine the integration module 14 concerned and ask it to make the call to the appropriate target service by providing it with the empty usage object. The integration module 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 provided by the application server and return the object of use thus informed to the routing module 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 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 server in the form of a text file. written in extensible markup language such as XML or similar.

Thus, data migrations to a computer system using an action communication and XML method 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 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 server in the form of a text file written in language. extensible markup of XML or similar type.

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

To illustrate this aspect of the invention, consider the following example of an action written in XML.

Message describing the call to the action: <MessageXML version = "V5R2" sense = "call"> <ListActions type- 'array ">

<Actioπ_ListeSoldesTousComptes array = "ListeActions"> <numeroClient> 5010328 </numeroClient> <codeConfidentielCrypte> sY03u </codeConfidentielCrypte> <lireDetailContrat> FALSE </lireDetailContrat> </Action_List>Atist>

This XML call message contains a single action, it could however contain several at the same time (useful in the case of migration for example). The action called is "Action JsteSoldesTousComptes" for the client number "5010328" who has identified himself (presence of the encrypted confidential code). The identification function is not provided by the action "ActionJJsteSoldesTousComptes", but by the action "ActionJdentificationClient" from which it inherits.

The action also has an option "read details of the contract corresponding to the requested accounts" which is not requested here.

Message describing the result of the action: <MessageXML version = "V5R2" sense = "result"><UsteActions type = "array"> <Action_ListeSoldesTousComptes array = "ListeActions"><numeroCIient> 5010328 </numeroClient><C0deConfidentielCrypte> sYO3u </codeConfidentielCrypte><designationClient> M Jean-Paul Carmona </designationClient><lireDetailContrat>

<baπqueKO> </banqueKO> <titresKO> </titresKO>

<cumulValorisatioπ> 0.00 </cumulValorisation> <deviseCumulValorisation> 2 </deviseCumulValorisation> <listSales type = "array">

<soldeComptable> 0.00 </soldeComptable> <soldeComptableOrigine> 0.00 </soldeComptableOrigine> <soldeEspece> 0.00 </soldeEspece> <soldeValeur> 0.00 </soldeValeur> <dateSoldeDepot> 19-Aug-2002 13:00:00 </dateSale

<deviseSoldeDepot> 2 </deviseSoldeDepot> <deviseSoldeDepotOrigine> 0 </deviseSoldeDepotOrigine> <quoteβSoldeTitres> 0 </deviseSoldeTitres> <portefeuillelnvesti> 0.00 </portefeuillelnvesti> <reπ

<soldeEndMonth_less1> 0.00 </soldeEndMonth_less1> <balanceEnd_Is_Less2> 0.00 </soldeEndMonth_Less2> <soldeEndMonth_Less3> 0.00 </soldeEndMonth_Less3> <balanceValeurFinMois_moiπs1> 0.00 <Mount_Main_Main_Main_Main_Main_Main_Main_Main_Main_Main_Main_Main_Main_Main_Main_Main_Main_Main_Main_Main_Main_Main_Main_Main_Main_Main_Main_Main_Main_Main_Main_Mount_Main_Mount_Main_Main_Mount_Main_Mount_Main_window

<balanceValueValue1months3> 0.00 </ balanceValueValueMonths3> <valorisatioπGIobale> 0.00 </ valorisatioπGlobale><valorisationTitres> 0.00 </ valorisatioπTitres><valorisatioπTitresBloques> 0.00 </ valorisatioπTitresBloques><valueLatβnte> 0.00 </valueLatente><valuβRealise> 0.00 </valueRealise

Above the response XML message contains the previously requested action with the results attributes entered. Here the output attribute results in only one usage object "UsageSolde" (because the client concerned has only one account).

The attributes in the "UsageSolde" object represent balances concerning deposit accounts (accounting balance, value, etc.) or securities (Invested portfolio, unrealized gain, etc.) are all empty because the account does not have any money. Information about the relevant account is provided (type, number).

The result attributes used in the context of the degraded mode (“bankKO”, “titlesKO” tags) are empty, indicating that the application servers concerned (potentially of bank or title type) are operational (otherwise, an error message would have has been entered here, the action being able in this case, depending on the type of account, to carry out the balance search in a backup database via the additional service layer 11 of the MCMA server). A “messageAnomaly” tag is also present at the “UsageSolde” object to describe the case of the specific problem with an account.

The output attribute "cumulValorisation" represents the cumulative balances (accounting for deposit or savings accounts and securities valuation for securities accounts) of all the client's accounts. This is an additional functionality provided by the action because each application server does not know the positions of the accounts managed by the other servers.

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 inside a computer system (1) of the distributed type, 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 selected application (6), the client servers (4) being directly connected to a single MCMA server (7) which in turn is directly connected to all of the servers applications (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) at the latter's expense to route it to the application server (5) concerned and to send back any information from the application server (5) to the client server (4), 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 any processing provided by the MCMA server (7).

2. Method according to claim 1, characterized in that said application servers (5) use an integration software layer and that the client servers (4) use a usage software layer (10) deduced from said layer integration (12) and in that the data structure of an action forming a service call cooperates with said usage layer (10).

3. Method according to claim 1 or claim 2, characterized in that the action forming call comprises an identifier corresponding to the identifier of the target application service (5), 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 (4).

4. Method according to any one of the preceding claims, characterized in that each action forming a service call is transferred between servers (4 and 5) in the form of a structured text document written in extensible markup language of the XML type or similar.

5. Method according to claim 3 and 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 and this, via the MCMA server (7).

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

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

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

9. Method according to claim 7, characterized in that the application servers (5) belong to the group formed by customer database managers, financial telephone centers, external financial databases, credit type applications , savings deposit, securities, insurance, and finance.

10. Communication device for implementing the method according to any one of claims 1 to 9, and able to communicate within a computer system (1) of the distributed type, 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 (7) which in turn is directly connected to all the application servers (5), so that any service call from a client server to a given application server , is first sent by said client server to the MCMA server (7), the latter responsible for routing it to the application server concerned and for sending back any information from the application server (5) ve rs the client server (4), characterized in that said client servers (4) are able to present the service calls in the form of 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 for possible processing provided by the MCMA server (7).