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

Communication method between servers with data format conversion and device therefor Download PDF

Info

Publication number
WO2004056071A1
WO2004056071A1 PCT/EP2003/051007 EP0351007W WO2004056071A1 WO 2004056071 A1 WO2004056071 A1 WO 2004056071A1 EP 0351007 W EP0351007 W EP 0351007W WO 2004056071 A1 WO2004056071 A1 WO 2004056071A1
Authority
WO
Grant status
Application
Patent type
Prior art keywords
server
mcma
client
application
servers
Prior art date
Application number
PCT/EP2003/051007
Other languages
French (fr)
Inventor
Jean-Paul Carmona
Original Assignee
Sema
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/547Remote procedure calls [RPC]; Web services
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/541Interprogram communication via adapters, e.g. between incompatible applications
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L29/00Arrangements, apparatus, circuits or systems, not covered by a single one of groups H04L1/00 - H04L27/00 contains provisionally no documents
    • H04L29/02Communication control; Communication processing contains provisionally no documents
    • H04L29/06Communication control; Communication processing contains provisionally no documents characterised by a protocol
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network-specific arrangements or communication protocols supporting networked applications
    • H04L67/10Network-specific arrangements or communication protocols supporting networked applications in which an application is distributed across nodes in the network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network-specific arrangements or communication protocols supporting networked applications
    • H04L67/28Network-specific arrangements or communication protocols supporting networked applications for the provision of proxy services, e.g. intermediate processing or storage in the network
    • H04L67/2823Network-specific arrangements or communication protocols supporting networked applications for the provision of proxy services, e.g. intermediate processing or storage in the network for conversion or adaptation of application content or format
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network-specific arrangements or communication protocols supporting networked applications
    • H04L67/42Protocols for client-server architectures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Application independent communication protocol aspects or techniques in packet data networks
    • H04L69/08Protocols for interworking or protocol conversion
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Application independent communication protocol aspects or techniques in packet data networks
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32High level architectural aspects of 7-layer open systems interconnection [OSI] type protocol stacks
    • H04L69/322Aspects of intra-layer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/328Aspects of intra-layer communication protocols among peer entities or protocol data unit [PDU] definitions in the presentation layer, i.e. layer six
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Application independent communication protocol aspects or techniques in packet data networks
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32High level architectural aspects of 7-layer open systems interconnection [OSI] type protocol stacks
    • H04L69/322Aspects of intra-layer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329Aspects of intra-layer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer, i.e. layer seven

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

PROCESS SERVER COMMUNICATION WITH FORMAT DATA CONVERSION AND DEVICE FOR ITS IMPLEMENTATION

The present invention relates to communication between servers within a distributed computer system said as including financial computer system used by banks or by insurance companies.

There are various different types of servers designed to communicate with each other to manage and process flow of transactions and information. A server is defined here as a combination of hardware (hardware) and appropriate software (software).

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

The application servers are specifically designed to manage databases and carry out specific treatments also called services. The term service is here broadly defined as any computer processing, this term covers both the provision of particular information such as an account number, the calculation of a balance or a transfer.

The computer system of a bank generally has a bank application server (eg financial engine marketed by SAB) which handles all operations related to the management of deposit accounts, a credit server that handles loans the bank to its clients, a stock market server management securities (stock engine Investiciel marketed by SEMA), an insurance server, etc.

Customers servers are for them to allow employees and users of the bank to access the various application servers for specific interfaces and communication networks, also called channels, to provide (updating operations, etc. ) or retrieve (query operations, etc.) of data across applications called service calls. Indeed, each request received by an application server generates the execution of a corresponding service by the latter.

As customers servers used by the computer system of a bank include a server managing computers equipping bank counters, ATM / DAB server associated with machines / automated machines, a voice server that allows users to access application servers using a telephone, a Web server to access these servers via the Internet, Minitel server, a WAP server, the partner server of the financial institution, etc.

Such an architecture is essential to allow to obtain by simple call of a digital telephone interviewing a financial institution such as a bank, the balance of a checking account or even to impute a current account the amount levied during a withdrawal at a bank cash machine and provide the holder the information about the new balance after this operation. In recent years, the connection between client servers and application servers is being made through a particular server said MCMA server for multi-channel and multi-application server (also called middleware in terminology Anglo Saxon) which are connected all client servers and all application servers.

Such MCMA server provides the routing of data between servers, but also is able to perform a number of additional features. The MCMA server therefore acts single application server for client server and single client server application servers.

With this architecture, the development of a new client server requires only one connection work MCMA server. MCMA the server is then able to provide this new client server all available services on the application servers, according to a selected communication method. It is obviously the same, when it comes to add a new application server.

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

This solution allows access to each application server independently of the connections linking the MCMA server to client servers.

However, the communication process proposed in the prior art between client servers and application servers via the MCMA server is not entirely satisfactory since it is relatively complex implementation or inappropriate, particularly as Concerning:

- pooling functionality implemented by the MCMA server on behalf of the client server;

- import / export data to or from the application servers as part of a data migration project from other computer systems, for example;

- regular changes in the application servers (changes, replacement, duplication, etc.).

Moreover, the system proposed in the prior art does not address the integration of a client server and / or an application server with a different technology than the MCMA server, especially regarding the language , format or communication protocol that are generally different from the MCMA server format.

Traditionally, when an adaptation of the client interface must be done in the format, language and protocol expected by the MCMA server, the IT team responsible for this adaptation develops programs called intermediate or "middleware" dedicated to this adaptation.

Now the IT team responsible for the client interface may be different from that responsible for the MCMA server. It is the same application server, whose development can be specific.

This results in development time relatively long and costly intermediate programs. Moreover, maintenance of the resulting system is relatively complex, as the identification of 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, communication between a plurality of client servers and a plurality of application servers each comprising at least one selected application client servers being connected to a single server which MCMA is in turn connected to all application servers, so any service call from a client server to a particular application server, is first sent by said client server server MCMA to charge it to route to the application server in question and to trace back any application server information to the client server.

According to a general definition of the invention, the method uses an incoming conversion chain and / or adapted to convert outbound calls written in language and MCMA server language format and size expected by the client server and / or application and converting customer server responses and / or written language application server and client server format and / or application server language written response and MCMA server format.

Such a method thus provides a framework, to facilitate and simplify the integration job from a client external system (client interface) and / or an external application system (application server) despite differences of format, language and protocol between client servers and / or application server and the MCMA.

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

- a connector incoming or outgoing integrated in MCMA server,

- a connection customer or application, interposed between the incoming or outgoing connector and the client or the application server, and adapted to communicate in the language, format and protocol MCMA server, and

- an integration element adapter / converter connected to the connection customer or application on the one hand and client server or the other application, said converter being adapted to convert calls or messages and responses language screen MCMA expected in language and format the client or application server and vice versa.

Preferably, the language and the MCMA server format are text file types written in Extensible Markup Language XML type or the like.

In practice the language, format and client server protocol and / or application server belong to the group formed by text or binary files "flat", serializing java object types, C ++, Visual Basic, or similar and IP, HTTP, CORBA / IIOP, JRMP, DCOM, COM, COM +, or the like. According to another aspect of the invention, each incoming or outgoing conversion chain is adapted to communicate according to a communication protocol according to which each service call is presented in the form of an action which is an object-oriented programming language class , having attributes / input fields representing the call of service parameters to be returned to said client server and a method capable of encapsulating the call to one or more target application servers and / or provide potential treatments provided by the MCMA server.

In practice, the MCMA server upon receipt of the action it performs synchronous or asynchronous mode by scrolling the method associated with this action to make potential treatments on the attributes / input fields and / or send to (x) server (s) target application (s) concerned (s) the service call in the format and specific protocol expected by said one or more application servers via the corresponding outgoing conversion chain.

Each application server called operates processing and provides the expected service in its specific format, the MCMA server via the corresponding outgoing conversion chain, the MCMA server then operating potential treatments on the data and returned by the or application servers and enhances the output attributes of the action is then raised to the client server transmitter, where applicable via the corresponding incoming conversion chain.

Multiple application servers can be requested during the execution of the same action. In this case, the various application servers can be called successively or simultaneously depending on the service provided.

The use action to communicate between clients and servers MCMA server has the advantage, in the context of object-oriented programming, to be implemented relatively simple and easy it is desired:

- benefit through inheritance between classes, a pooling features found repeatedly in service calls and can thus be implemented in a simple way by the MCMA server, such as the identification of the user, enabling control, auditing service calls (eg for operating controls, performance, or to their pricing);

- standardize the communication process with customers servers;

Other features and advantages of the invention (eg simplification / reliability of regular changes in the application servers: replacement, duplication, developments) will be apparent from the following detailed description and drawings in which :

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

- Figure 2 illustrates the communication method according to the invention; - Figure 3 is a diagram indicating the structure of the MCMA server implemented in the computer system of Figure 1;

- Figure 4 shows schematically an incoming conversion chain and an outgoing conversion chain according to the invention; and

- Figure 5 is a list of connectors and connections of the invention.

Referring to Figure 1, the computer system described as an example is the computer system of a financial institution and more specifically a bank. This computer system referenced 1 provides a plurality of financial services managed by specialized application servers and accessed by employees or users through a plurality of interfaces 2 customers.

For example, interfaces customers 2 can be fixed digital telephones 2a or mobile 2b, ATMs ATMs (not shown), branches receiving 2c mail or 2d faxes, branch sales offices (not shown) of ATM self-service ATMs (not shown), personal computers for home banking using an internet connection type 2f 2g or minitel, interactive televisions 2nd, etc.

These interfaces client 2 are connected by suitable networks 3, individualized 3-1 to 3-6, to client servers 4, individualized 4-1 to 4-6. 4 servers are specifically developed according to the technical possibilities of each interface 2 and 3. Each of each network interface and its associated network are still called channel.

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

Moreover, a server 7 is sandwiched between clients and servers 4 application servers 5. This server 7, called MCMA (acronym for Multi Channel and Multi Application) is common to all clients and servers capable of their 4 provide the set of applications available 6 of the application servers 5 to which it is connected, according to a selected communication method.

Note that preferably the MCMA server 7 is not only used to route customer data servers to application servers and vice versa but also serves to operate various treatments, such as identification / authentication the end user and / or client server, the degraded mode management (eg replicated database management to provide information despite the availability of application servers affected), control enabling auditing Service calls or pricing, ...

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

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

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

The means used for communication between clients and servers MCMA 7 server include software modules constituting a so-called conversion chain "incoming" that will later be detailed.

The communication method between client servers and four application servers 5 of the distributed computing system 1 is built around the concept of action. This process in particular is to present each service call as an action.

Remember, an action is a class in object-oriented programming language (Java, C ++, etc.), with attributes / fields representing input parameters of the service call and possible attributes / fields representing output the result of the service to be returned to said client server and a method capable of encapsulating the call to one or more target application servers and / or provide potential treatments provided by the server 7 MCMA.

Thus, each service is an action that encapsulates the call to the target or application servers via the MCMA server 7 or treatments implemented by the MCMA 7 server.

The application server 5 accommodating the target service 6 receives the call the target service, output from the MCMA server 7 according to the specific protocols and formats of the application server 5 and returns the result (result of service or error) to MCMA server 7 again according to its specific protocols and formats of the application server

5.

Referring to Figure 2, the communication method comprises the following steps:

- step (i), II instantiation is to create, for example by Minitel server 4-6, a class instance (in the terminology of object-oriented programming) type action that corresponds to the service "current account balance N "following a call request (request) from a client interface 2g, in this case of a minitel used by a user that wants to know the balance of its current account;

- step (ii), the Minitel server 4-6 enhances the action of input attributes in accordance with data supplied by the user and sending the action to MCMA server 7 according to the protocol and format of his choice from those proposed by the latter ( "someAction" is an instance (an object, a variable) of the class (type) "FxAction" (a FxAction is the technical name that refers to generic share);

- step (iii), the MCMA server 7 receives the action and performs unwinding the associated method. This combined method has a behavior that varies depending on the values ​​of some or all of the input attributes. This is among other things here that can be provided additional functionality such as user identification, control, empowerment, auditing service calls, etc .;

- step (iv) the integration layer which will be described in more detail after the MCMA server 7 is urged by the action "current account balance" for it carries the corresponding target on the service call application server in question (here the bank server 5a) according to the specific formats and communication protocols of the latter. (EntryPoint.invoke (someAction) is an object language instruction, in this case it is the instruction which causes the unwinding of the method associated with some action "someAction" in the MCMA server 7);

- step (v), the application server running the requested service described by the call to learn reading or calculating the account balance and returns the result corresponding to the MCMA server 7 according to the specific format and communication protocol application server;

- step (vi), the server integration layer MCMA 7 restores the data results provided by the application server to the method associated with the action. This then promotes the attributes results of the operation, based on data received by the application server 5a. This is among other things here that can be provided additional functionality such as auditing service answers, pricing, degraded mode (eg in case of error, read the basic balance data replicated daily), etc. .

- step (vii) When the method associated with the action is completed, the MCMA server 7 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 7 server will be more particularly detailed.

Preferably, the software architecture of MCMA server 7 is in particular constituted by two distinct software layers: a wear layer 10 and an integration layer 12. It should be noted that the integration layer may be completely resident in the MCMA server 7 as described in Figure 3 or alternatively reside partly in the MCMA server 7 and in part in one or more integration servers as shown in figure 4.

The wear layer 10 is an intermediate layer that complements, facilitates and simplifies the use of services provided by the application servers 5. It's wise to layer 10 is used as an interface to access the layer 12 integration from client servers 4. the wear layer 10 is made including all actions available from the MCMA 7 server (as described hereinabove) and type classes "object of use".

A custom object can be considered as a view of one or more data structures used by the application servers 5. This view is a common representation at all equivalent data structures in the servers of the applications concerned. For example, the object of use "UsageCompte" can be used to represent a deposit account of a bank server 5a, or a securities account server scholarship 5b.

The inheritance provided by the concept of class mechanism (OOP) further strengthens the sharing of information. For example, deposit accounts may be represented as usual "UsageCompteDepôt" objects that inherit the attributes (data members) of the object of use "UsageCompte" and who have the additional attributes specific to an account deposits relative to an abstract and generic account "UsageCompte". The latter can also be inherited by several other type of object use (called "son") as "UsageCompteEpargne", "UsageCompteTitres" etc. Thus an action representing the service "list of accounts of a client" will provide a list of all types of accounts hosted by all application servers managing accounts. Such action has an output attribute of type "table UsageCompte" that contain, for example result for a client, polymorphism (concept of object-oriented programming) a deposit account, a savings account and a titles, each managed by a different application servers.

Thus all objects of use facilitates and simplifies the representation of data structures that are inherently variable depending on the application server. The objects - use allow the pooling of exchange formats between clients and servers 7 MCMA server regardless of the application server in question.

The use 10 layer also helps stabilize formats provided to client server when changes in an application server 5, or replace one of them with a new application server. For example, if one considers that the bank server 5a has a data structure "account balance" that aggregates accounting balances, value and kind of an account, and these balances are therefore represented in the class "UsageSolde" to be available to customers servers. The replacement of the bank server 5a by a new application server that does not have sort of balance, do not modify the object of use "UsageSolde" and therefore will not require modification of client servers. Missing information will be populated with a default value, calculated by the MCMA 7 server.

Note that if the new banking application server has new information regarding the balance (ie end of previous month balance), we can enrich the object of use "UsageSolde" a new attribute. The use 10 layer, for these contributions in simplifying and stabilizing exchange formats with client servers and facilitates the management of regular changes in application servers (replacement, duplication, developments).

The information by the use of data classes from application servers 5. For example, the balancing account given of the use object comes from the bank server 5a. To enhance their output attributes, the shares of the use of layer called the integration layer 12 (and layer additional services 11 for features of MCMA server 7 that are not available in the application servers).

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

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

The routing subsystem 13 is the stock entry point of the wear layer 10. It is responsible for determining based on the data represented by an object of use (eg, account type, account number of the No. client) or the application servers involved and therefore the integrations or modules 14 to delegate that communication. For integration modules 14 concerned, the routing subsystem 13 provided the use of object and the service to call in the application server.

The integration modules 14 constituting an outgoing conversion chain are thus responsible for communication with a specific application server 5 according to the formats and protocols expected by the application server. They are also able to convert specific data structures from the application server to use object and vice versa. Such outgoing conversion chain will be detailed later.

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

The action "list of balances of all accounts of a client" will first look through a service called "CRM" (acronym for Customer Relation Management, that is to say, Managing Customer Relations) the additional service layer 11, the list of accounts held numbers in the database 15. Then, for each account number, will ask the integration layer 12 the corresponding balance by providing an object of use " UsageSolde "filled with non balances. The routing subsystem 13 will, depending on the account number and account type, determine the outgoing conversion chain of sub-system integration 14 question and ask him to call the appropriate target service in him providing the vacuum use object. The integration subsystem 14 will call the target service through the expected formats and protocols for the application server in question, fill the object of use with the results provided by the application server and return the object use and inquired sub routing system 13 which will return him to action plaintiff.

To transmit the shares forming service calls between the servers of the computer system 1 is used files written preferably with a structured language also called extensible markup language, such as XML (acronym for Extensible Markup Language) .

A structured document is a collection of sets of information each associated with a type and attributes, and compounds them by mainly hierarchical relations. Such a document allows in particular to distinguish the different subsets of information composing the document. In contrast, in a linear said document, the information content of the document are mixed with presentation and typing information.

A structured document includes pins separation of different sets of document information. In the case of XML, these markers called "tags" are of the form "<b>" (opening tag) and "</ b>" (end 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 static. It defines its own tags, which makes it adaptable and therefore able to store all kinds of information. A structured document is associated with what is called a structure schema or DTD (Document Type Definition), defining in the form of rules the structure and the type of information each set of information of the document. A schema is composed of nested groups of information sets of structures, which groups may be ordered sequences, groups of alternative elements or groups of necessary elements, ordered or unordered.

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

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

Such a markup language used to provide data formats without restricting itself to a technical platform which either hardware or software.

Moreover, the representation of text written in XML every action creates only via a simple text editor, an XML file describing one or more call stock services. The result of his actions, also written in XML will also easily interpreted from a simple text editor.

It is interesting to build on an extensible markup language XML as part of import / export of data in combination with call requests (respectively input and output attributes attributes).

The implementation of such an XML-based language is thus associating an XML tag for each action, these tags containing them even one tag for each input attribute for each share of output attribute.

Very advantageously, the actions of input attributes that correspond to write processes, creation or modification of data are transferred (injected / imported) in application servers via the MCMA 7 server as a file text written in extensible markup language XML type or the like.

Thus the data migration to a computer system using a communication method per share and require only XML rewriting extraction program data as XML extraction file source system corresponding to the actions of the server 7 MCMA.

Additionally, any creation of new share that corresponds to a write processing will import a solution of additional data for a future migration. For example the creation of a new action following a new need for a Web client server, intended for creation of address, facilitate future import email from a source computer system addresses or will complete the flow data from a partner company providing data of people to prospect.

Similarly, shares of output attributes that match the playback treatment, research or consulting data are transferred (removed / exported) corresponding application servers via the MCMA server 7 in the form of a written text file extensible markup language XML type or the like.

The benefits provided by XML describable actions are therefore also valid in the context of data export, upon redemption of the bank or the establishment of periodic data stream with the computer system of a partner company (B2B ).

When the current action (call request containing new data to write to the requested target service) is a writing service in the system (creation, modification, etc.), the operation is called "import multi-engine "because the data in the XML file inputted are injected into the system via the intermediary server MCMA 7.

Conversely, when the action used is a reading service in the system (research, consulting, etc.), the operation is called "multi-engine export" as the result XML file contains an extraction of data system via the intermediate server

MCMA 7. Such XML import / export data has the advantage of simplifying the action processing in a computer environment to multiple client servers and multiple service servers through an MCMA 7 server.

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

Each incoming conversion circuit is adapted to provide communication between a specific client and the server 4 MCMA server 7 according to a selected communication protocol.

An incoming conversion chain consists of different modules implemented on the client server 4 and the server 7 MCMA.

client server 4 side was a client adapter module and a client connecting module

The client adapter unit adapts messages to the client server specific format in XML format from MCMA server 7. The client adapter module is loaded, following a request (message format specific client server) initiated by the functional module of the client server ( by "functional unit" means the module providing the heart specific to this client server features, eg if the client server is a web server, this module provided specific functionality to a web server and manages data specific to a server WEB), the creation of corresponding XML messages to send to the MCMA server 7 of an action forming service call, and vice versa, from the analysis of XML messages returned by the server MCMA 7 to convert the message into a format in recognized by the client server or error if any. This module is not responsible for the exchange of XML messages.

The client connecting module (or PLUG IN) 22 is responsible for communication with an incoming one connector (or IN connector) 20 of MCMA server 7. This module is writing in client server technology. It is responsible for the exchange of XML messages with a single type of connector incoming MCMA server 7 via only one type of protocol. It is only in charge of the exchange of XML messages, not their creation to sending or analysis at the reception.

MCMA server side 7 there is therefore an inbound connector 20, encapsulated in the MCMA server 7 and writing in MCMA server technology 7. This connector comprises a communication module and a conversion module.

The communication module is adapted to communicate with "clients connections" (PLUG IN) using the same protocol (indeed, several customers connections, write each in a different technology as Visual Basic or Java, for example, may be compatible with one connector incoming they rely on the same communication protocol). The conversion module converts an XML message object (in the sense of object-oriented programming) action type in technology MCMA 7 server and vice versa, this module is commonly called the "XML parser".

Each outgoing conversion circuit is adapted to provide communication between an application server 5 and the MCMA server 7 according to a selected communication protocol.

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

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

The communication module is adapted to communicate with the integration server connections (or PLUG OUT) 26, using the same protocol (indeed, several integration server hook-write each in a different technology such as C or COBOL e.g., may be compatible with the same connector used if they are based on the same communication protocol);

The conversion module of an object (in the sense of object-oriented programming) action type in the MCMA 7 server technology, XML and conversely message. This is the same "XML parser" module as used in the "inbound connector" if the same XML format is used (note: MCMA 7 server can have several different XML formats: Canon, compact, etc.)

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

The integration server connection module 26 is responsible for communication 23 with an outgoing connector integration 24 of MCMA server 7, the server connection module is encapsulated in the integration server is writing in technology server integration, he is responsible for the exchange of XML messages with a single type of outbound connector server MCMA 7 via a single protocol type, it is responsible only for the exchange of XML messages, not their analysis the receipt of the appeal or taken to sending the response.

The converter module converts the messages in XML format from MCMA server 7 messages in the specific format to the application server where the integration server to the load, the converter module is responsible for parsing the XML messages representing actions forming service calls issued by the MCMA server 7 to convert the message in forming service call in the specific format of the application server with the integration server to the load, and vice versa, creating XML messages back to the server MCMA 7 as service call result (this, or this error if any, was originally provided by the application server including the integration server to the load), this module is not responsible for exchange messages. The application server connection module is responsible for communicating messages with the application server where the integration server to the load via a specific communication protocol to the application server, it is loaded as the exchange of messages, not their creation to sending or analysis at the reception.

According to the communication protocol selected for the incoming or outgoing chain, each service call is presented as an action which is a class in object-oriented programming language, with attributes / fields representing input parameters of call service to be returned to said client server and a method capable of encapsulating the call to a target server and / or provide potential treatments provided by the server 7 MCMA.

The target server (MCMA server 7 in case of incoming channel, application server in case of outgoing channel) in response to an action, is capable of performing the latter in synchronous or asynchronous mode by scrolling the method associated with that 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 be the same job according to whether one is in the incoming conversion chain (action MCMA server 7) or the outgoing conversion chain (action of the integration server).

As for the inbound conversion chain, the XML message corresponds to an action of the MCMA 7 server, the corresponding method is executed in the MCMA server 7. It generally allows operation potential treatments on the attributes / fields and input / or send the (x) server (s) target application (s) concerned (s) the service call through the corresponding outgoing conversion string to retransmit the service to the corresponding application server. Upon receiving the result of the service call, the MCMA 7 server via the method of the action running, then operating potential treatments on the data and returned by the server or application and values ​​the output attributes of the action is then raised to the client server transmitter via the corresponding incoming conversion chain and 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 usually converts the XML message in forming post service call in the specific format of the application server with the integration server to load, then send it to the application server via the specific protocol application server to provide the service. Upon receiving the result of the service call, the integration server, via the method of the action in progress, the result converted message to the specific format of the application server under its load, Message results in XML format from MCMA server 7 and returns it. To carry out its work, the integration server is based on the modules presented above in 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 language to communicate with the MCMA server 7 whose language and format are different from those specific language and format.

For example, consider the client server 4 is a dynamic web server write in ASP.Net, to access the application via the Internet servers. The client server 4 uses XML for message format that are different from XML format MCMA server 7, and consider that MCMA 7 server side, for example written in Java, the inbound connector 20 using the SOAP protocol.

The corresponding inbound conversion chain therefore requires the client server-side development of a customer adaptation module to transform XML messages to XML messages client server server MCMA 7 and vice versa. The client server 4 also host a client connection unit 22 and write in ASP.Net using the SOAP protocol to communicate with connector 20 used to send the XML message created by the client adaptation module and retrieve the response from the server 7 MCMA .

The MCMA 7 server can also include channels outgoing software conversion.

For example, consider that the application server 5 is a banking application server write COBOL he uses to flat text message format with data delimited by special characters like "; "(CSV). The banking application server also uses for its communications with client systems, IP as follows: each text message sent or received by the bank application server is preceded by a header consisting of 6 numbers right-aligned and filled with zeros if necessary digits to the left then a space (white, ASCII character 32). This header gives the size of the text message that follows (number of bytes to read, after the blank), eg "003585 Datal; data2; ... ". Consider also that server side MCMA 7 (writing for example in C ++), the outgoing connector 24 uses IIOP.

The corresponding outgoing conversion chain requires the development of an independent integration server written in Java for example to adapt the calls made by the MCMA 7 XML server via IIOP in text messages call in CSV format via the protocol IP as described above, and vice versa. The application server 5, as the MCMA 7 server, will not undergo any change. To do its work, the integration server 28 hosts the "integration server connection module" 26 write in Java and using IIOP to communicate with outbound connector 24 to receive XML messages forming service call issued by the MCMA server 7. the heart of the integration server is the converter module, write in Java, responsible for converting XML messages MCMA server 7 text messages in CSV format expected by the bank application server 5. Finally, the server integration should be complemented by the development of an application server connection module, write in Java and using the IP protocol (as described previously) to communicate with the bank application server to send the text message CSV created by the converter unit and retrieve the response from the bank application server. The module "converter" of the integration server or the "customer adaptation" module client server can depending on the language used and formats to convert rely on products from computer software development tools to facilitate market their work.

For example, the conversion to XML files flat and vice versa can be set up based on an XSLT parser "Xalan" of the body open source "Apache". Other cases: converting one XML format to another XML format, or to database tables can be set up by a converter that uses the product "Liquid Data", sold by company "BEA".

In general, the execution of the service call is synchronous or asynchronous. Incoming connectors 20 and / or outgoing 24 are synchronous or asynchronous.

Referring to Figure 5, a list lists the format and language that may be converted by the conversion chain of the invention.

Each connector 7 MCMA server, whether incoming or outgoing, is associated with a protocol that may belong to the group consisting of IP, HTTP, CORBA / IIOP, JRMP, DCOM, COM, COM +, SOAP or the like.

Each connector can be associated client connections or integration server, dedicated to the protocol of the connector 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 the connector associated with an application server that fact by MCMA server setting 7. This setting specifies the information such as the outbound connector used and data necessary for it to establish a connection to the server 'integration. For example, an IP outbound connector will have IP connection parameters such as IP address and port of the integration server and the time at which it considers that the integration server will not respond (timeout).

Example of setting these parameters in the INI file format for Microsoft Windows (7 MCMA case the server would write for example in Visual Basic):

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

software conversion chains according to the invention can reduce integration costs and operating 7 MCMA server with client servers and application servers:

- structuring the integration rules for any client with the server 7 MCMA server (XML representing an action forming call service provided by the server MCMA 7 customer connection, incoming connector);

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

- pooling the server side communication layers MCMA 7 (reuse of connectors used for all client servers, reuse of outgoing connectors for all application servers);

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

- preparing the development of the integration server (the integration server connection provided the starting strain of the integration server.

In practice, it is preferable that the customer connections 22 and application integration server connections 26 is developed by the same IT team as responsible for the development of the MCMA server connectors 7. If based on the language that is writing the client or server integration server, the client connection does not exist, it is this team that is best placed to performed this new module

(Enrichment "integration kit" of the corresponding connector and thus enriching the MCMA server 7). For the same reasons, so depending on the protocol the incoming or outgoing connection does not exist, it is the development team server MCMA 7 which must develop the missing connector and the first branch corresponding to test ( enrichment of the integration kit MCMA server 7).

The IT development team incoming connectors, connectors outgoing, customer connections and server connections, advantageously will establish trace functionality (log file creation) when sending / receiving messages for easy identification the component responsible for dysfunction in case of breakdown or identification of the component "bottleneck" in case of performance problems.

Thus specific developments (made by an integration project team) needed to integrate a client server or application server with the MCMA 7 server are minimized:

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

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

These specific developments are also made reliable by reusing already proven connectors and existing connections. Of course, the illustrated embodiments have been given only as examples and are in no way limiting the set of solutions that can be implemented with the present invention.

Claims

[1] A method for communicating within a computer system (1) of distributed type a plurality of customer servers (4) each having software means and specific hardware with a plurality of application servers (5 ) each having specific software and material and each comprising at least one selected application (6), the customer server (4) being directly connected to a single MCMA server which in turn is directly connected to all servers of Application (5), so that all service call from a client server to a particular application server, is first sent by said client server load MCMA server for it to route it to the server Application concerned and to trace back any application server information to the client server, wherein each service call from a client server (4) and serveu r MCMA (7) cooperates with a first conversion chain languages ​​and formats and / or in that each call between the service server MCMA (7) and an application server (5) cooperates with a second conversion chain languages ​​and formats, said second conversion chain being distinct from said first conversion chain.
[2] The method of claim 1, characterized in that said customer servers (4) have service calls in the form of action, these actions being programming language object-oriented classes which have a data structure and a method adapted to encapsulate the call to one or more target application servers (5) and / or provide potential treatments provided by the MCMA server (7).
[3] The method of claim 1, characterized in that forming each action service call is transferred between servers in the form of a structured text document written in Extensible Markup Language XML type or the like.
[4] The method of claim 1, characterized in that the action forming call includes an identifier corresponding to the identifier of the target service, the input attributes representing the parameters of the service call and any attributes output representing the result of the service to be returned to said client server
[5] The method of claim 4, characterized in that the input attributes corresponding to a writing service creation or modification type are imported into the corresponding application servers (5) the format of an XML file and, MCMA via the server (7).
[6] The method of claim 4, characterized in that the output attributes corresponding to a mark type sense service or consultation are exported from the corresponding application servers (5) the format of an XML file and, via the MCMA (7) server.
[7] The method of claim 1, characterized in that said application servers use a software layer integration and client servers use a software layer derived from said usage integration layer and in that the structure dune action of forming data service call cooperates with said wear layer.
[8] A method according to any one of the preceding claims, characterized in that the computer system (1) is of the type to provide financial services.
[9] The method of claim 8, characterized in that the customer server (4) cooperate with client interfaces (2) constituted in particular by digital telephones, ATMs, branches, branch sales offices, terminals selling self-service, personal computers for home banking, interactive televisions.
[10] The method of claim 8, characterized in that the application servers (5) belong to the group formed by guests database managers, financial call centers, external financial databases, type applications credit, deposit savings, title, insurance, and finance.
[11] The method of claim 1, characterized in that the language, format and / or protocol of the client server (4) and / or application server (5) belong to the group consisting of text files or binary "in flat ", XML, java object serialization of type C ++, Visual Basic, Perl, COBOL, PHP or similar and IP, HTTP, CORBA / IIOP, JRMP, DCOM, SOAP or the like. [12] The method of claim 1, characterized in that each incoming conversion chain comprises an adaptation module and a client connecting module (22) integrated with the client server (4) and an incoming connector (20) integral with the associated MCMA (7) server.
[13] Method according to claims 3 and 12, characterized in that said client adaptation module adapts messages specific format to the client server (4) in XML format from MCMA server (7) and vice versa, in that said module client terminal (22) exchange XML messages with MCMA server (7) according to a single protocol type and in that said incoming connector (20) integrated in MCMA server (7) is adapted to exchange messages according to the protocol of said customer connection (22) and operates the conversion of XML messages into action type object in technology MCMA server (7) and vice versa.
[14] The method of claim 1, characterized in that each outgoing conversion chain uses an integration server (28) interposed between the MCMA server (7) and the application server (5) matching.
[15] The method of claim 1, characterized in that each outgoing conversion chain comprises an outgoing connector (24) integrated in MCMA server (7) and an integration server connection (26) and a converter module integrated in server integrating (28).
[16] A process according to 3 to 15 claims, characterized in that said converter module adapts messages specific format to the application server (5) in XML format from MCMA server (7) and vice versa, in that said connection server integrating (26) the XML exchange messages with the MCMA server (7) according to a single protocol type and in that said outgoing inbound connector (24) integrated in MCMA server (7) is adapted to exchange messages according to the protocol said integration server connection (26) and operates the conversion of XML messages into action type object in technology MCMA server (7) and vice versa.
[17] A communication between a plurality of customer 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 server MCMA (7) which is in turn connected to all application servers (5), so that all service call from a client server to a particular application server, is first addressed said client server MCMA server (7) to charge it to route to the application server (5) concerned and to trace back any application server information (5) to the client server ( 4), characterized in that it comprises at least one entering conversion chain and / or outgoing each adapted to convert messages and calls language MCMA server language format and size expected by the client server (4) and / or the application server (5) and for converting the responses of s erver customer (4) and / or application server (5) written in language and client server format and / or written application server in response language and MCMA server format.
[18] Device according to claim 19, characterized in that each incoming conversion chain and / or outgoing is adapted to communicate with a client server (4) and / or an application server (5) according to a communication protocol according to wherein each service call is presented in the form of an action which is an object-oriented programming language class having attributes / input fields representing the call of service parameters to be returned to said client and server a method capable of encapsulating the call to one or more servers to target applications and / or provide potential treatments provided by the MCMA server.
[19] Device according to claim 18, characterized in that the MCMA server in response to an action, is capable of performing the latter in synchronous or asynchronous mode by scrolling the method associated with this action to make possible treatments on attributes / input fields and / or send the (x) server (s) target application (s) concerned (s) the service call in the specific format and protocol expected by said one or more application servers via the incoming conversion chain and / or corresponding outgoing, each application server called operating the treatment and providing the expected service in its specific format, MCMA server via the corresponding outgoing conversion chain while operating MCMA server then d possible processing on the data and returned by the one or more application servers and enhances the output attributes of the action is then raised to the sending client server, via the c hate corresponding incoming conversion.
PCT/EP2003/051007 2002-12-17 2003-12-15 Communication method between servers with data format conversion and device therefor WO2004056071A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
FR0216249A FR2848759A1 (en) 2002-12-17 2002-12-17 Client and application server communicating method for e.g. financier computer system, involves converting call responses written in client or application format into format written in multi-channel multi-application server format by string
FR0216249 2002-12-17

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
AU2003298359A AU2003298359A1 (en) 2002-12-17 2003-12-15 Communication method between servers with data format conversion and device therefor

Publications (1)

Publication Number Publication Date
WO2004056071A1 true true WO2004056071A1 (en) 2004-07-01

Family

ID=32338968

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2003/051007 WO2004056071A1 (en) 2002-12-17 2003-12-15 Communication method between servers with data format conversion and device therefor

Country Status (2)

Country Link
FR (1) FR2848759A1 (en)
WO (1) WO2004056071A1 (en)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020038340A1 (en) * 2000-08-14 2002-03-28 I2 Technologies Us, Inc. Network application program interface facilitating communication in a distributed network environment
US20020138582A1 (en) * 2000-09-05 2002-09-26 Mala Chandra Methods and apparatus providing electronic messages that are linked and aggregated

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020038340A1 (en) * 2000-08-14 2002-03-28 I2 Technologies Us, Inc. Network application program interface facilitating communication in a distributed network environment
US20020138582A1 (en) * 2000-09-05 2002-09-26 Mala Chandra Methods and apparatus providing electronic messages that are linked and aggregated

Also Published As

Publication number Publication date Type
FR2848759A1 (en) 2004-06-18 application

Similar Documents

Publication Publication Date Title
US5179660A (en) System for reducing communications overhead in distributed database transactions by serializing in order related requests into single transmission message and receiving transmission response
US7725385B2 (en) System and method for facilitating the handling of a dispute using disparate architectures
US6754833B1 (en) Method for generating and distributing telecom and internet revenue
US6601057B1 (en) Method and apparatus for generating and modifying multiple instances of an element of a web site
US7035944B2 (en) Programmatic management of software resources in a content framework environment
US6012050A (en) Multi-transaction service system
US7444302B2 (en) Online system for fulfilling loan applications from loan originators
US7152207B1 (en) Method and apparatus for providing conditional customization for generating a web site
US5963925A (en) Electronic statement presentment system
US6185567B1 (en) Authenticated access to internet based research and data services
US7668913B1 (en) Method and apparatus for generating a web site with dynamic content data from an external source integrated therein
US6826700B1 (en) Method and apparatus for a web application server to automatically solicit a new password when an existing password has expired
US7200804B1 (en) Method and apparatus for providing automation to an internet navigation application
US20030023527A1 (en) Systems and methods for facilitating agreement generation and negotiation via an agreement modeling system
US20040003347A1 (en) System and method for providing on-line services for multiple entities
US6792607B1 (en) Databinding using server-side control objects
US20030191832A1 (en) Method and apparatus for controlled establishment of a turnkey system providing a centralized data aggregation and summary capability to third party entities
US20010045963A1 (en) Method and apparatus for binding user interface objects to application objects
US20070288890A1 (en) System, method and apparatus to allow for a design, administration, and presentation of computer software applications
US20040226027A1 (en) Application interface wrapper
US20030212904A1 (en) Standardized transmission and exchange of data with security and non-repudiation functions
US6850893B2 (en) Method and apparatus for an improved security system mechanism in a business applications management system platform
US7752634B1 (en) Non-intrusive personalization of web services
US20100106546A1 (en) Systems and methods for executing business processes over a network
US6701352B1 (en) Method and apparatus for importing information from a network resource

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established
32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 69(1) EPC DATED 230905, FORM 1205A

122 Ep: pct app. not ent. europ. phase
NENP Non-entry into the national phase in:

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP