FR2846498A1 - METHOD FOR COMMUNICATION BETWEEN SERVERS AND DEVICE FOR IMPLEMENTING SAID METHOD - Google Patents

Abstract

Method and device 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 (7) which is in turn directly connected to all of the servers applications (5), 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 suitable method to encapsulate the call to one or more target application servers (5) and / or to provide for any processing performed by the MCMA server (7).

Description

The present invention relates to a method of communication between

  servers and 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 by the insurance companies, there are different servers of different natures intended to communicate with each other to manage and process data flows. transactions and information. A server is understood here as the combination of computer hardware (hardware) and appropriate software (software).

  Thus, a financial computer system comprises different servers called customers (or front office according to the English terminology)

  interconnected to different so-called application servers (or back office).

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

a balance or a transfer.

  The computer system of a bank generally comprises a bank application server (example: financial engine marketed by the SAB company) which processes all the operations related to the management of deposit accounts, a credit server which manages the loans granted. by the bank to its clientele, a stock market securities management server (Investiciel exchange engine marketed by SEMA), an insurance server, etc. The client servers are intended to allow employees and users of the bank to access different application servers from specific interfaces and communication networks, also called channels, to provide (update operations, etc.). ) or retrieve 5 (query operations, etc.) data through queries called service calls. Indeed, each request received by a server

  application generates the execution of a corresponding service by the latter.

  As client servers used by the computer system of a bank, there may be mentioned a server managing the computers equipping the counters of the banks, a ATM / ATM server associated with ATMs / ATMs, a voice server that allows users to access to the application servers by means of a telephone, a web server for accessing these servers via the lnternet, a Minitel server, a WAP server, the servers of the partners of the financial organization, etc. Such an architecture is essential to obtain by simply calling a digital telephone interviewing a financial institution such as a bank, the balance of a current account or even to charge 20 of a current account the amount taken during a withdrawal to a distributor of banknotes and provide the holder with information on the new

balance after this operation.

  Historically, each of the client servers was directly connected, as it was being created, to each of the application servers that

  concerned by dedicated point-to-point links.

  The proliferation of application servers and client servers linked to the emergence of new channels such as the Internet and mobile telephony, but also to the development of new financial services such as insurance, makes such an architecture extremely point-to-point. difficult to

  develop, manage, maintain and secure.

  Thus, the setting up of a Web server assumes the complete writing by the 5 IT teams in charge of developing the computer system, the interface and the integration work with each of the application servers to which it is connected and can not reuse

  developments already made 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 carried out via a particular server called MCMA server for multi-channel server and multiapplication (also called middleware in the English terminology) 15 which are connected all client servers and all application servers. Such an MCMA server provides routing of data between the servers but is also able to perform a number of additional features. The MCMA server acts as a single application server for client servers and a single client server for

application servers.

  With this architecture, the development of a new client server requires only one connection job to the MCMA server. The MCMA server is then able to provide this new client server with all 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. 30

  The document WO-A-98/24040 describes such a server.

  Such a solution provides access to 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 since it is relatively complex to implement, in particular as regards: common features implemented by the server

  MCMA on behalf of the client servers.

  - the integration of a client server with specific technological constraints; - regular changes in the application servers (evolutions, replacement, duplication, etc.); Furthermore, the system proposed in the prior art does not deal with the importlexport of data to or from application servers, 20 as part of a project for migrating data from other systems.

computer for example.

  Traditionally, when a data migration between two computer systems is to be done (for example the migration of customers 25 from a redeemed bank into the bank's computer system.

  buyer). The migration process consists of extracting the data from the source computer system as a file and then inserting its data directly into the databases of the different application servers hosting client data (stock portfolio of the 30 clients, account balances, etc.). ).

  The extraction programs are made specifically according to the possibilities offered by the source system, they generally produce extraction files texts "flat" image of the tables of the bases of

  data from the system of the bank purchased.

  Extraction programs are also made specifically to distribute the extraction file data in the corresponding tables of the different application servers hosting applications.

  customer data (customer portfolio, account balances, etc.).

  Migration work is also often done in the context of centralization at the national level, computer systems (often different) of each regional subsidiary or when setting up periodic data flows with the IT system of a partner company. 15 (B2B, ex: redemption of the client file of a mail order company). With each migration, the programs of creation of the files of extraction are to be made, but the diversity of the data to be migrated

  most often requires rewriting the data insertion programs.

  The present invention therefore aims to remedy all these disadvantages.

  It relates to a method of communication between servers and on 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 is in turn directly connected to all the application servers, so that any service call from a client server to a server given application server, is first sent by said client server to the MCMA server by the latter to route it to the application server concerned and to return any information from the application server to the server. 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 15 to be returned to said client server and a method capable of encapsulating the call to one or more application servers

  targets and / or to provide for possible treatments provided by the MCMA server.

  The MCMA server upon receipt of the action executes the latter in synchronous or asynchronous mode by scrolling the method associated with this action to make possible processing on the attributes / input fields and / or send to the server (s). s) target application (s) concerned the service call in the format and specific protocol expected by said application server or servers.

  Each called application server performs its processing and provides the expected service, in its specific format, to the MCMA server, which then processes 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 requested when performing 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 it is desired: to benefit, thanks to the inheritance between classes, of a pooling of features that are recurrently present in the service calls and which can thus be simply covered directly by the MCMA server, for example: the identification of the user, the authorization control, the audit of service calls or their pricing; - standardize the communication process with the client servers; - regular changes in application servers

  (replacement, duplication, evolutions).

  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 the language of the client server.

  Extensible markup of the XML type or the like.

  Other features and advantages of the invention will become apparent from the following detailed description and drawings in which:

  FIG. 1 is a schematic representation of a computer system covering the method of communication between client servers and application servers according to the invention; FIG. 2 illustrates the communication method according to the invention; and FIG. 3 is a diagram specifying the structure of the MCMA server set in

  in the computer system of Figure 1.

  With reference to FIG. 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, the client interfaces 2 belong to the group consisting of fixed digital 2a or mobile 2b telephones, GAB ATMs (not shown), branches receiving 2c mail or 2d faxes, branch sales offices (not shown). ), DAB self-service cash dispensers (not shown), personal computers for home banking using an Internet 2f or Minitel 2g connection, interactive 2nd 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 420 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 still called channels.

  The computer system 1 further comprises a plurality of application servers 5 each comprising at least one selected application 6, individualized at 6a to 6e. For example, the servers are of the server type

  bank 5a, stock server 5b, insurance 5c, credit 5d, or other 5th.

  Moreover, a server 7 is interposed between the client servers 4 and the 30 application servers 5. This server of the MCMA type (multi-channel and multi-client)

  application) is directly common to all the client servers 4 and is able to provide them with all the services available 6 on the application servers 5 to which it is also connected, according to a method of

chosen communication.

  It should be noted that, preferably, the MCMA server 7 is not only used to route data from the client servers to the application servers and vice versa but also serves to perform various processing, such as for example the identification / authentication of the end user and / or the application server 10, the degraded mode management (eg management of replicated databases to provide information despite the unavailability of the relevant application servers), the authorization check, the audit of

  service calls or their pricing, ...

  Each client server adapts the call transmitted 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 sending it to the server

  MCMA 7 according to a format and protocol expected by the MCMA server 7.

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

  According to the invention, the communication method between the client servers 4 and the application servers 5 of the distributed computer system 1 is articulated around the notion of action. This method consists more particularly of presenting each service call as 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 any attributes / output fields representing the result of the service intended to be returned to said client server 5 and a method able to encapsulate the call destined for one or more target application servers and / or to provide for possible treatments

provided by the MCMA server.

  Thus, according to the invention, each service has an action that encapsulates the call intended for the target application server (s) via the MCMA server 7 or else processing implemented directly by the server.

MCMA server.

  The application server 5 housing the target service 6 receives the target service call, issued 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 target server. MCMA server always according to its formats and protocols

  specific to the application server 5.

  With reference to FIG. 2, the communication method comprises the following steps: step (i), instantiation It is a question of creating, for example by the minitel server 4-6, an instance of class (according to the terminology of object-oriented programming) of action type which corresponds to the service "balance of the current account N" following a request for a request (request) from a client interface 2g, in this case a minitel used by a user which wants to know the balance of his current account; it - step (ii), the minitel server 4-6 values the input attributes of the action according to the data provided by the user and sends the action to the MCMA server according to the protocol and the format of his choice among those proposed by the latter ("anAction" is an instance (an object, a variable) of the class (of the type) "FxAction" (an FxAction is the technical name which designates generic action); - step (iii), the The MCMA server 7 receives the action and executes it by unwinding the associated method, which method has a behavior that varies according to the values of all or some of the input attributes. additional functionalities such as the identification of the user, the authorization check, the audit of service calls, etc. - step (iv), the integration layer that will be described in greater detail hereinafter after the server MCMA 7 is requested by the action "current account balance" to make it perform 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. 20 (entryPoint. Invoke (anAction) is an instruction in object language, in this case it is the instruction that causes the method associated with any action "anAction" in the MCMA server) to proceed; step (v), the application server executes the requested service described by the call namely reading or calculating the account balance and returns the result corresponding to the MCMA server 7 according to the specific communication format and protocol of the application server; step (vi), the integration layer of the MCMA server 7 renders the results data provided by the application server to the method associated with the action. This therefore values the result attributes of the action, according to the data received by the application server 5a. It is here, among others, that additional functionalities can be provided such as the audit of service responses, pricing, degraded mode (eg in case of error, read the balance in database replicated daily), etc .; step (vii), When the method associated with the action is completed, the MCMA server returns the action to the minitel 2g via the minitel server 4-6; step (viii), the minitel receives and displays the result Referring to Figure 3, the structure of the MCMA server 7 will be more

particularly detailed.

  Preferably, the software architecture of the MCMA 7 server consists in particular of two distinct software layers: the layer

  use 10 and the integration layer 12.

  According to one definition of the invention, the usage layer 10 is an intermediate layer which completes, simplifies and facilitates the use of the services provided by the application servers 5. It is the usage layer 10 which is used as an interface to access the integration layer 12 since

the client servers 4.

  The usage layer 10 consists in particular of the set of actions

  available from the MCMA server (see description above) and classes

of type "object of use".

  A usage object can be viewed as a view of one or more data structures used by the 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" can be used to represent a deposit account of a bank server 5a, or a securities account of the stock exchange server 5b. The inheritance mechanism provided by the class concept (object-oriented programming) further enhances the sharing of information. For example, the deposit accounts could be represented by "UsageDateDotDuty" objects that inherit attributes (member data) from the "UsageAccount" usage object and that only have the additional attributes specific to an account. of deposits against an abstract account and generic "UsageAccount". The latter can also be inherited by several other types of object of use 15 (called "son") such as "UsageCompteEpargne", "UsageCompteTitres", etc. Thus an action representing the service "list of accounts of a client" can provide a list of all types of accounts hosted by all application servers managing accounts. Such an action has an output attribute of "UsageCountTable" which will contain, for example as a result for a client, by polymorphism (concept of object-oriented programming): a deposit account, a savings account and

  a securities account, each managed by different application servers.

  Thus the set of usage objects facilitates and simplifies the representation of the data structures which are by definition variable according to the application server. The objects of use allow the sharing of the exchange formats 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 provided 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 cash of an account, and these different balances are therefore represented in the class "UsageSolde "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 result in a modification of the "UsageSold" usage object and therefore will not require the modification of the client servers. Missing information will either be filled out at a

  default value, calculated by the MCMA server.

  It should be noted that if the new bank application server has 15 new information concerning the balance (ex: end balance of the previous month), we can enrich the "UsageSolde" usage object with a new attribute. The usage layer 10, by these contributions simplifying and stabilizing the 20 exchange formats with the client servers, thus facilitates the support of regular changes 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 object of use account comes from the bank server 5a. To value their output attributes, the usage layer actions call the integration layer 12 (and the supplementary services layer 11 for MCMA server features that are not available in the application servers).

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

integration 12.

  The integration layer 12 is compartmentalized 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 layer 10 of 10. It is responsible for determining according to the data

  represented by a usage object (ex: type of account, account n0, client n0) the application server or servers concerned and therefore the integration module or modules 14 to whom to delegate the communication. For each integration module 14 concerned, the routing module 13 provides the object of use 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 able to convert specific data structures from the application server into a purpose object.

and vice versa.

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

  The action "list of balances of all accounts of a customer" will first search through a service called "CRM" (acronym for Customer Relation Management, that is to say Customer Relationship Management) of the supplementary service layer 11, the list of the account numbers held in the database 15. Then for each account number, will ask the integration layer 12 the corresponding balance by providing an object d 'UsageSolde' use with unspecified balances. The routing module 13 will, depending on the account number 5 and the type of account, determine the integration module 14 concerned and ask him to make the appropriate target service call by providing the empty use 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 module of routing 13 which him

  will return to the plaintiff action.

  In order to transmit the service call actions between the different servers of the computer system 1, files preferably written with a structuring language also called extensible markup language, such as XML (expandable acronym) are used.

Markup Language).

  A structured document is a collection of information sets each associated with a type and attributes, and composed between them according to

  primarily hierarchical relationships. Such a document makes it possible in particular to distinguish the different subsets of information composing 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 benchmarks for separating different

  sets of information from the document. In the case of the XML format, these markers called "tags" are of the form "<b>" (opening tag) and "</ b>" (closing tag), the first mark indicating the beginning of a

  set of information named "b" and the second the end of this set.

  Unlike HTML (HyperText Markup Language), the XML language is not semantically fixed. It allows to define its 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 document type definition (DTD) structure defining

  rules the structure and type of information of each set of information in the document. A schema consists of nested groups of information set structures, which groups can be ordered sequences, groups of alternative elements, or groups of necessary, ordered, or unordered elements.

  The XML documents received by the servers of the computer system 1 are processed by a corresponding Application Programming Interface (API) written in an object-oriented language and serving as an XML parser (or XML parser) for analyzing and decoding. the

tags of these documents.

  Thus, for each action (representing a usage service and the usage data used where appropriate) is associated a description written in XML.

  Such a markup language makes it possible to provide data formats without being limited to a technical platform that is either 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 his actions, also written in XML will also be easy to interpret from a simple text editor. It is interesting to rely on an XML-type extensible markup language in the context of data import / export functions in association with the call requests (respectively input attributes and output attributes). 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 that correspond to write, create or modify data processing operations are transferred (injected / imported) into the application servers via the MCMA server in the form of a file. text written in markup language

extensible XML or similar type.

  Thus migrations of data to a computer system using an action communication method and XML will only require rewriting of the source system's data retrieval program as an XML retrieval file corresponding to actions of the system.

MCMA server.

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

people to prospect.

  Likewise, the output attributes of the actions that correspond to read, search or data lookup processes are transferred (extracted / exported) from the corresponding application servers via the MCMA server in the form of a text file written in language markup

extensible XML or similar type.

  The benefits provided by actions that can be described in XML are therefore also valid in the context of data export, when the bank is bought or when periodic data flows are set up with the bank.

  computer 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 input XML file is fed into the system via the MCMA intermediate server 7.

  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 result XML file contains a data extraction 30 from the system via the MCMA 7 Intermediate Server.

  Such importlexport of data in XML has the advantage of simplifying the processing of the actions in a multi-computer environment

  client servers and multiple service servers via an MCMA 7 server.

  To illustrate this aspect of the invention, consider the following example of action written in XML. Message describing the call of the action <MessageXML version = "V5R2" meaning = "call"> 10 <ActionList type = "array"> <ActionListSalesAllCom ptes array = "ActionList"> <clientNumber> 5010328 </ clientNumber> <trustConfigCrypt > sYO3u </ codeConfidentielCrypte> <lIireDetailContrat> FALSE </ IireDetailContract> 15 </ Action_ListeSoldesAllAccount> <IListActions> </ MessageXML> This call XML message contains only one action, but it could contain several actions at one time (useful in the case of migration for example). The action called is "Action_ListSoldAllAccount" for the customer number "5010328" who has identified himself (presence of the encrypted PIN). The function of identification is not provided by the action "Action_ListSoldesAllCounts", but by the action

  "ActionIdentificationClient" it inherits.

  The stock also has an option "read detail of the corresponding contract

  to the requested account "which is not requested here.

  Message describing the result of the action: <MessageXML version = "V5R2" meaning = "result"> <ActionList type = "array"> <ActionListSalesAllAccount array = "ActionList"> <clientNumber> 5010328 </ clientNumber> <trustCryptKey> sYO3u </ codeConfidentialCrypt> <designationClient> M John Paul Carmona </ nameClient> <readContractDetail> FALS E </ ContractLease> <KOBack> </KOBack> <KOtacks> </KOtacks> <WrapUpValue> 0. 00 </ accorValue> <recalculationValue> 2 </ recalendCalculator> 10 <solverList type = "array"> <UsageSolder array = "listSolder"> <recCountAccount /> <advertCode> 0 </ yearCode nc> <forumCode /> <accountTypeCode> 2 </ accountTypeCode> <accountNumber> 01 501032801 </ accountNumber> <accountControlNumber> 01501032801 </ n accountControlUn> <defectMessage /> <assignments> 0.00 </ assignments> <cumulValue> 0.00 </ accumValue> <balanceSave> 0.00 </ balanceAccountable > <balanceCountableOrigin> 0.00 </ balanceCountableOrigin> <SpecSet> 0. 00 </ balanceSpec> <balanceValue> 0.00 </ balanceValue> <dateSolderDepot> 19-Aug2002 13:00:00 </ dateSolderDepot> <billDateOut> 2 </ billOutPlot> <signOutputOpticDom> 0 </ targetOpbitOutput> <billOurDemory> 0 </ currencySolderTitles> <netfile> 0.00 </ netfileillinvesti> 30 <revenue> 0.00 </ revenue> <balanceMore minus1> 0.00 </ balanceFinMinutes1> <balanceFinMonth2> 0.00 </ balanceFinOver2> <balanceFinOver3> 0. 00 </ balanceFinOver3> <balanceValueEndMinutes1 <0. 00 </ balanceValueEndMonths <1> 35 <balanceValueEndMinutes <2> 0. 00 </ balanceValueEndMonths <2> <balanceValueEndMinutes <3> 0. 00 </ balanceValueEnd less3> <globalValue> 0. 00 </ globalValuation> <valuationTitles> O.00 </ valuationTitle> <valuationTitleBlock> O.00 </ valuationTitleBlock> <valueLatente> O.0O </ valueLatente> 5 <valueRealise> O.00 </ valueRealise> <valueRealiseRM> O . 00 </ valueRealiseRM> <liquidite type = "array" /> </ UsageSolid> </ listSoldes> </ Action_ListSoldAllAccount> </ ActionList> </ MessageXML> Above the response XML message contains the previously requested action with the attributes results filled. Here the output attribute results in only one usage object "UsageSold" (because the client

  concerned has only one account).

  The attributes in the "UsageSold" object represent balances 20 relating to deposit accounts (balance, value, etc.) or securities (invested portfolio, unrealized gain, etc.) are all empty because the account does not have 'money. Information concerning the account concerned is

provided (type, number).

  The result attributes used in the context of the degraded mode (tags "bankKO", "titlesKO") are empty, indicating that the concerned application servers (potentially of type bank or titles) are operational (otherwise, an error message would have Here, the action can, depending on the type of account, carry out the search for a balance in a backup database via the service layer.

  additional 11 of the MCMA server).

  A tag "messageAnomalie" is also present at the object "UsageSolde" to describe the case specific problem to

an account.

  The output attribute "cumulEvaluation" represents the cumulative balances

  (accounting for deposit or savings accounts and securities valuation for securities accounts) of all customer accounts. This is an additional feature provided by the action because each application server does not know the positions of the accounts managed by the other 10 servers.

  Of course, the illustrated embodiments have been given only by way of examples and are not absolutely limiting of all the

  solutions that can be implemented by virtue of the present invention.

Claims (10)

  A 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 possessing 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 is in turn directly connected to the set 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) with the latter to route it to the application server (5) concerned and to return any information from the application server (5) to the client server (4), characterized in that said client servers (4) ) presen Initiate service calls in the form of actions, which actions are object-oriented programming language classes that have a data structure and method capable of encapsulating the call to one or more application servers. targets (5) and / or to be   possible processing 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 (12) and that the data structure of a   service call action cooperates with said usage layer (10).   3. Method according to claim 1 or claim 2, characterized in that the calling action comprises an identifier corresponding to the identifier of the target application service (5), input attributes representing the parameters of the service call and any output attributes representing the result of the service to be returned to said client server (4).   4. A method according to any one of the preceding claims, characterized in that each service call action 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 the like.   5. Method according to claim 3 and claim 4, characterized in that the input attributes corresponding to a write service of the type 15 creation or modification are imported into the corresponding application servers (5) in the format of a file. XML 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) to 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 provide 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, automated teller machines, branches, branch sales offices, terminal terminals, sale 5 self-service, personal computers for home banking, interactive TVs.   9. Method according to claim 7, characterized in that the application servers (5) belong to the group formed by managers of 10 customer databases, financial telephone centers, databases.   external financial data, credit, deposit savings, securities, insurance, and finance applications.   10. Communication device for implementing the method according to any one of claims 1 to 9, and able to communicate to the   within a distributed type computer system (1), a plurality of client servers (4) each having specific hardware and software means with a plurality of application servers (5) each having specific hardware and software means and each comprising at least one selected application (6), the client servers (4) being directly connected to a single MCMA server (7) which is in turn directly 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) in charge of the latter to route it to the server. concerned application and to return back any information from the application server (5) to the client server (4), characterized in that said client servers (4) are able to present the service calls in the form ac these actions being object-oriented programming language classes 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).