[go: up one dir, main page]

WO2004057825A2 - Procede de communication entre serveurs avec conversion de format des donnees et dispositif pour sa mise en oeuvre - Google Patents

Procede de communication entre serveurs avec conversion de format des donnees et dispositif pour sa mise en oeuvre

Info

Publication number
WO2004057825A2
WO2004057825A2 PCT/EP2003/051013 EP0351013W WO2004057825A2 WO 2004057825 A2 WO2004057825 A2 WO 2004057825A2 EP 0351013 W EP0351013 W EP 0351013W WO 2004057825 A2 WO2004057825 A2 WO 2004057825A2
Authority
WO
WIPO (PCT)
Prior art keywords
server
mcma
client
servers
xml
Prior art date
Application number
PCT/EP2003/051013
Other languages
English (en)
Other versions
WO2004057825A3 (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
Application filed by Sema filed Critical Sema
Priority to AU2003303162A priority Critical patent/AU2003303162A1/en
Publication of WO2004057825A2 publication Critical patent/WO2004057825A2/fr
Publication of WO2004057825A3 publication Critical patent/WO2004057825A3/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/08—Protocols for interworking; Protocol conversion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/2871—Implementation details of single intermediate entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Definitions

  • the present invention relates to communication between servers within a so-called distributed computer system, such as in particular a financial computer system used by banks or by insurance companies.
  • a server is understood here as the combination of computer hardware (hardware) and appropriate software (software).
  • a financial computer system includes different so-called client servers (or even front office servers according to English terminology) interconnected with different so-called application servers (or back office servers).
  • Application servers are more particularly intended to manage databases and to perform specific processing also called services.
  • service is defined here generally like any computer processing, this term covers both the provision of specific information such as an account number, as well as the calculation of a balance or a transfer.
  • the computer system of a bank generally includes a banking application server (example: financial engine marketed by SAB) which processes all operations linked to the management of deposit accounts, a credit server which manages the loans granted by the bank to its customers, a stock exchange server for securities management (Investiciel stock market engine marketed by SEMA), an insurance server, etc.
  • a banking application server (example: financial engine marketed by SAB) which processes all operations linked to the management of deposit accounts
  • a credit server which manages the loans granted by the bank to its customers
  • a stock exchange server for securities management Investiciel stock market engine marketed by SEMA
  • an insurance server etc.
  • Client servers are intended to allow employees and users of the bank to access the various application servers from specific communication interfaces and networks, also called channels, to provide (update operations, etc. ) or recover (interrogation operations, etc.) of data through requests called service calls. Indeed, each request received by an application server generates the execution of a corresponding service by the latter.
  • a server managing the computers equipping the bank counters an ATM / ATM server associated with the ATMs / ATMs, a voice server which allows users to access the application servers by means of a telephone, a Web server to access these servers via the Internet, a Minitel server, a WAP server, the servers of partners of the financial organization, etc.
  • Such an architecture is essential to make it possible to obtain, by a simple call from a digital telephone questioning a financial institution such as a bank, the balance of a current account or even to charge a sum drawn during a '' a withdrawal from a bank machine and provide its holder with information on the new balance after this operation.
  • MCMA server for multi-channel and multi-application server (also called middleware in English terminology). Saxon) to which all client servers and all application servers are connected.
  • Such an MCMA server ensures the routing of data between the servers but also is capable of achieving a certain number of additional functionalities.
  • the MCMA server therefore acts as the sole application server for the client servers and as the sole client server for the application servers.
  • the development of a new client server requires only a single connection job to the MCMA server.
  • the MCMA server is then able to provide this new client server with all of the services available on the application servers, according to a chosen communication method. It is obviously the same when it comes to adding a new application server.
  • the communication method proposed in the prior art between client servers and application servers via the MCMA server is not entirely satisfactory insofar as it is relatively complex or unsuitable to implement, in particular in that which concerns: - the pooling of functionalities implemented by the MCMA server on behalf of client servers; - import / export of data to or from application servers, as part of a project to migrate data from other IT systems, for example; - regular changes in application servers
  • the system proposed in the prior art does not deal with the integration of a client server and / or an application server having a technology different from that of the MCMA server, in particular with regard to the language. , the format or even the communication protocol which are generally different from the format of the MCMA server.
  • the present invention overcomes these drawbacks.
  • It relates to a method, and a device for its implementation, of communication between a plurality of client servers and a plurality of application servers each comprising at least one chosen application, the client servers being connected to a single MCMA server which is in turn connected to all of the application servers, so that any service call from a client server to a given application server is first addressed by said client server to the MCMA server it is up to the latter to route it to the application server concerned and to send back any information from the application server to the client server.
  • the method according to the invention is characterized in that when the MCMA server uses XML and the client server uses HTML, then the associated incoming conversion chain comprises an adaptation module integrated into the client server using a program written in Java language, also called servlet, intended to automatically convert HTML forms using service in an understandable XML document from MCMA server and vice versa.
  • a program written in Java language also called servlet
  • the servlet reuses the names of the parameters of the HTML tag "input na e" as names of opening and closing XML tags, while the values of the HTML input parameters are converted into values of XML tags.
  • the HTML forms processed by the servlet include hidden parameters containing instructions controlling the running of said program.
  • the HTML forms processed by the servlet include hidden parameters containing information such as the type of service call or even usage classes defining XML tags.
  • the HTML forms processed by the servlet include hidden parameters containing information such as the XSL files necessary for the conversion of the XML response from the MCMA server into an HTML document.
  • the servlet transfers the service call to the MCMA server after having converted it to XML format by passing through a client connection module integrated into the client server capable of communicating with an incoming connector. associated with the MCMA server.
  • the client servers present the service calls in the form of an action, these actions being classes in object-oriented programming language which have a data structure and a method capable of encapsulating the call to one or more target application servers and / or to provide for possible processing provided by the MCMA server.
  • each action forming a service call is transferred between servers in the form of a structured text document written in extensible markup language of the XML type or the like.
  • the action forming a call comprises an identifier corresponding to the identifier of the target service, input attributes representing the parameters of the service call and possible output attributes representing the result of the service intended to be returned to said client server
  • the application servers use an integration software layer and that the client servers use a usage software layer deduced from said integration layer and in that the structure of data from a service call action cooperates with said usage layer.
  • FIG. 1 is a schematic representation of a computer system implementing the communication method between client servers and application servers according to the invention
  • FIG. 3 is a diagram detailing the structure of the MCMA server implemented in the computer system of Figure 1;
  • FIG. 4 schematically shows an incoming conversion chain and an outgoing conversion chain according to the invention
  • - Figure 5 is a list of connectors and connections according to the invention.
  • FIG. 6 details a module of an incoming conversion chain operating the HTML / XML conversion according to the invention.
  • the computer system described by way of example is the computer system of a financial institution and more precisely of a bank.
  • This computer system referenced 1 provides a plurality of financial services managed by specialized application servers and accessible by employees or users through a plurality of client interfaces 2.
  • customer interfaces 2 can be fixed digital telephones 2a or mobile phones 2b, ATMs
  • branches receiving 2c mail or 2d faxes branches receiving 2c mail or 2d faxes, branch sales offices (not shown), DAB self-service ATMs (not shown), personal computers for home banking using a 2g or minitel 2f Internet connection, 2nd interactive televisions, etc.
  • client interfaces 2 are connected by appropriate networks 3, individualized in 3-1 to 3-6, to client servers 4, individualized in 4-1 to 4-6.
  • the servers 4 are developed in a specific way according to the technical possibilities of each interface 2 and of each network 3.
  • Each interface and its associated network are also called channel.
  • the computer system 1 further comprises a plurality of application servers 5, such as for example, a bank server 5a, a stock exchange server 5b, an insurance server 5c, a credit server 5d, or other 5e.
  • application servers 5 such as for example, a bank server 5a, a stock exchange server 5b, an insurance server 5c, a credit server 5d, or other 5e.
  • Each of these servers 5 implements each comprising at least one specific application 6, respectively referenced 6a to 6e.
  • a server 7 is interposed between the client servers 4 and the application servers 5.
  • This server 7, called MCMA is common to all of the client servers 4 and suitable for their provide all of the applications available 6 on the application servers 5 to which it is also connected, according to a chosen communication method.
  • the MCMA 7 server is not only used to route data from client servers to application servers and vice versa, but also is used to operate various processing operations, such as for example identification / authentication of the end user and / or of the client server, degraded mode management (for example management of replicated databases making it possible to provide information despite the unavailability of the application servers concerned), control of authorization, audit of service calls or their pricing, ...
  • Each client server 4 adapts the call sent by its corresponding channel, such as for example the WAP client server from a message sent by a mobile phone, in a predetermined form and the sending to the MCMA server 7 according to a format and protocol expected by the MCMA 7 server.
  • the MCMA 7 server offers several formats and protocols in order to adapt to the technological constraints of a client server 4 and any network 3.
  • the formats offered by the MCMA 7 server can be binary file (serialization of Java object, or C ++, Visual Basic, etc.) or "flat" text, XML file.
  • the protocols offered by the MCMA 7 server can be IP, HTTP, CORBA / IIOP, JRMP, DCOM, COM, COM +, etc.
  • the means used to allow communication between the client servers and the MCMA server 7 include software modules constituting a so-called "incoming" conversion chain which will be detailed later.
  • the communication method between the client servers 4 and the application servers 5 of the distributed computer system 1 is structured around the concept of action. This process is more particularly to present each service call in the form of an action.
  • an action is a class in object-oriented programming language (Java, C ++, etc.), having attributes / input fields representing the parameters of the service call and possible attributes / fields of output representing the result of the service intended to be returned to said client server and a method able to encapsulate the call to one or more target application servers and / or to provide possible processing provided by the MCMA 7 server.
  • object-oriented programming language Java, C ++, etc.
  • each service corresponds to an action which encapsulates the call intended for the target application server or servers via the MCMA 7 server or else processing implemented directly by the MCMA 7 server.
  • the application server 5 housing the target service 6 receives the call from the target service, sent by the MCMA server 7, according to the specific formats and protocols of the application server 5 and returns the response (service result or error) to MCMA 7 server always according to its specific formats and protocols of the application server 5.
  • the communication method comprises the following steps:
  • the minitel 4-6 server values the input attributes of the action according to the data supplied by the user and sends the action to the MCMA 7 server according to the protocol and format of its choice from those proposed by the latter (“anAction” is an instance (an object, a variable) of the class (of type) “FxAction” (an FxAction is the technical name which designates generic action);
  • the MCMA 7 server receives the action and executes it by rolling out the associated method.
  • This associated method has a behavior which varies according to the values of all or part of the input attributes. It is among other things here that additional functionalities can be provided such as user identification, authorization control, audit of service calls, etc .;
  • step (iv) the integration layer which will be described in more detail below of the MCMA server 7 is requested by the action "current account balance” so that it makes the corresponding target service call on the application server concerned (here the bank server 5a) according to the specific communication formats and protocols of the latter.
  • entityPoint.invoke (uneAction) is an instruction in object language, in this case it is the instruction which causes the method associated with any action "uneAction” to run in the MCMA 7 server);
  • step (v) the application server executes the requested service described by the call, namely the reading or the calculation of the account balance and returns the result corresponding to the MCMA 7 server according to the format and the specific communication protocol of the application server;
  • the integration layer of the MCMA server 7 restores the results data supplied by the application server to the method associated with the action. It therefore values the action result attributes, as a function of the data received by the application server 5a. It is among other things here that additional functionalities can be provided such as the audit of service responses, pricing, degraded mode (ex: in case of error, read the balance in the database replicated daily), etc. .
  • step (vii) When the method associated with the action is finished, the MCMA 7 server returns the action to the minitel 2g via the minitel 4-6 server;
  • the minitel receives and displays the result.
  • the structure of the MCMA server 7 will be more particularly detailed.
  • the software architecture of the MCMA 7 server is in particular made up of two distinct software layers: a usage layer 10 and an integration layer 12.
  • a usage layer 10 can be entirely resident in the MCMA 7 server as described in Figure 3 or else reside in part in the MCMA 7 server and partly in one or more integration servers as illustrated in Figure 4.
  • the usage layer 10 is an intermediate layer which completes, simplifies and facilitates the use of the services provided by the application servers 5. It is the usage layer 10 which is used as an interface to access the d layer. integration 12 from client servers 4.
  • the usage layer 10 is made up in particular of all the actions available from the MCMA server 7 (see description above) and of “object of use” type classes.
  • a usage object can be considered as a view of one or more data structures used by the application servers 5. This view is a representation common to all the equivalent data structures in the application servers concerned.
  • the usage object "UsageAccount” could be used to represent a deposit account of a bank server 5a, or even a securities account of the stock exchange server 5b.
  • deposit accounts could be represented by "UsageCompteDépôt” usage objects that inherit attributes (member data) from the usage usage "UsageCompte” and that only have the additional attributes specific to an deposits compared to an abstract and generic "UsageCompte” account.
  • This the latter can also be inherited by several other types of usage object (known as “sons”) such as "UsageCompteEpargne", “UsageCompteTitres”, etc.
  • an action representing the service "list of accounts of a client” can provide the list of all types of accounts hosted by all application servers managing accounts.
  • Such an action has an output attribute of the “UsageCount table” type which will contain, for example in profit for a client, by polymorphism (concept of object-oriented programming): a deposit account, a savings account and an account titles, each managed by different application servers.
  • polymorphism cept of object-oriented programming
  • the set of usage objects facilitates and simplifies the representation of data structures which are by definition variable depending on the application server.
  • the objects of use allow the mutualization of the formats of exchanges between the client servers and the MCMA 7 server whatever the application server concerned.
  • the usage layer 10 also makes it possible to stabilize the formats supplied to the client servers in the event of modification in an application server 5, or the replacement of one of them by a new application server.
  • the bank server 5a has a data structure "account balance" which aggregates the accounting balances, value and species of an account, and these different balances are therefore represented in the class "UsageSolde" in order to be available to client servers.
  • the replacement of the bank server 5a by a new application server which does not have a cash balance will not entail any modification of the usage object "UsageSolde" and therefore will not require the modification of client servers.
  • the missing information will either be filled in at a default value, or calculated by the MCMA 7 server.
  • the usage object "UsageSolde" may be enriched with a new attribute.
  • the usage layer 10 by these contributions in simplification and stabilization of the formats of exchanges with the client servers, thus facilitates the management of regular modifications in the application servers (replacement, duplication, evolutions).
  • the information contained in the usage data classes comes from the application servers 5.
  • the accounting balance data of the account usage object comes from the bank server 5a.
  • the actions of the usage layer call the integration layer 12 (and the additional services layer 11 for the functionalities of the MCMA server 7 which are not available in the application servers).
  • the integration layer 12 is divided into two subsystems: a routing subsystem 13 and an integration subsystem 14 comprising software modules forming conversion chains, called "outgoing", with each of the application servers 5. Only the modules 14a and 14b have been represented corresponding respectively to the banking servers 5a and the stock exchange 5b
  • the sub-routing system 13 is the entry point for the actions of the usage layer 10. It is responsible for determining as a function of the data represented by a usage object (eg type of account, number of the account, customer number) the application server (s) concerned and therefore the integration module (s) 14 to whom to delegate the communication. For the integration modules 14 concerned, the sub-routing system 13 provides the usage object and the service to be called in the application server.
  • a usage object eg type of account, number of the account, customer number
  • the integration module (s) 14 to whom to delegate the communication.
  • the sub-routing system 13 provides the usage object and the service to be called in the application server.
  • the integration modules 14 constituting an outgoing conversion chain are therefore responsible for communication with a specific application server 5 according to the formats and protocols expected by this application server. They are also capable of converting specific data structures from the application server into an object of use and vice versa. Such an outgoing conversion chain will be explained in more detail later.
  • each component of the MCMA server 7 will be illustrated in the following example: consultation of the account X of a client Y on the application server 5a.
  • Relation Management i.e. Customer Relationship Management
  • the integration layer 12 will ask the integration layer 12 for the corresponding balance by providing it with a usage object "UsageSolde" with unspecified balances.
  • the routing subsystem 13 will, depending on the account number and the type of account, determine the outgoing conversion chain of the integration subsystem 14 concerned and ask it to make the call to the appropriate target service in it. providing the empty object of use.
  • the integration subsystem 14 will call the target service via the formats and protocols expected by the application server concerned, fill the object of use with the results supplied by the application server and return the object d usage thus informed to the routing subsystem 13 which will return it to the requesting action.
  • files written preferably with a structuring language also called extensible markup language, such as XML (English acronym for extensible Markup Language) are used. .
  • a structured document is a collection of sets of information, each associated with a type and attributes, and composed together according to mainly hierarchical relationships. Such a document makes it possible in particular to distinguish the different subsets of information making up the document. In contrast, in a so-called linear document, the content information of the document is mixed with the presentation and typing information.
  • a structured document includes separation marks for the different sets of information in the document.
  • these marks called “tags” are of the form “ ⁇ b>” (opening tag) and “ ⁇ /b>” (closing tag), the first marker indicating the beginning of a set of information called “b And the second the end of this set.
  • HTML HyperText Markup Language
  • a structured document is associated with what is called a structure diagram or DTD (Document Type Definition) defining in the form of rules the structure and the type of information of each set of information in the document.
  • DTD Document Type Definition
  • a schema is made up of nested groups of information set structures, these groups can be ordered sequences, groups of alternative elements or groups of necessary elements, ordered or unordered.
  • the XML documents received by the servers of the computer system 1 are processed by a corresponding application programming interface (API, Application Programming Interface) written in object oriented language and serving as an XML parser (or XML parser) to analyze and decode the tags of these documents.
  • API Application Programming Interface
  • XML parser or XML parser
  • each action (representing a usage service and the usage data used if applicable) is associated with a description written in XML language. zu
  • markup language makes it possible to provide data formats without being restricted to a technical platform, be it hardware or software.
  • the input attributes of the actions which correspond to processing of writing, creation or modification of data are transferred (injected / imported) into the application servers via the MCMA 7 server in the form of a file.
  • Data migrations to a computer system using an action-based and XML communication process will only require rewriting a data extraction program from the source system as an XML extraction file corresponding to actions by the MCMA 7 server.
  • any creation of new actions that correspond to write processing will be an additional data import solution for the next migration.
  • the creation of a new action following a new need for a WEB client server, intended for address creation, will facilitate future imports of email addresses from a source computer system or will make it possible to complete the flow of data from a partner company providing data from people to prospect.
  • the output attributes of actions which correspond to processing of reading, searching or consulting data are transferred (extracted / exported) from the corresponding application servers via the MCMA 7 server in the form of a text file written in Extensible markup language such as XML or the like.
  • the operation is then called “import multi-engine "because the data in the XML file supplied as input are injected into the system via the MCMA 7 intermediate server.
  • Such import / export of data in XML has the advantage of simplifying the processing of actions in an IT environment with several client servers and several service servers, via an MCMA 7 server.
  • the only invariant of these conversion strings is the use of XML messages representing actions to communicate with the MCMA 7 server.
  • Each incoming conversion chain is capable of ensuring communication between a given client server 4 and the MCMA server 7 according to a chosen communication protocol.
  • An incoming conversion chain is made up of different modules implemented on the client server 4 and on the MCMA server 7.
  • Client server side 4 we have a client adapter module and a client connection module
  • the client adapter module adapts messages of the format specific to the client server to the XML format of the MCMA 7 server.
  • the client adapter module is loaded, following a request (message to the specific format of the client server) initiated by the functional module of the client server ( “functional module” means the module providing the core of the functionalities specific to this client server, for example if the client server is a WEB server, this module provides the functionalities specific to a WEB server and manages data specific to a server WEB), the creation of corresponding XML messages for sending to the MCMA 7 server an action forming a service call, and vice versa, the analysis of the XML messages result returned by the MCMA 7 server to convert them back into a message in a format recognized by the client server or in error if necessary.
  • This module is not responsible for exchanging XML messages.
  • the client connection module (or PLUG IN) 22 is responsible for communication 21 with an incoming connector (or IN connector) 20 of the MCMA server 7.
  • This module is written in the technology of the client server. It is responsible for exchanging XML messages with a single type of incoming connector from the MCMA 7 server via a single type of protocol. It is only responsible for exchanging XML messages, not for their creation on sending or their analysis on reception.
  • the adapter module in the case where the adapter module operates on a client server 4, such as the Web server, relying on HTML forms, the adapter module preferably uses a Servlet Java also called SERVLET ADAPTER. Such a module is more particularly detailed with reference to FIG. 6.
  • a Servlet (contraction of "server applet") is a Java program which is executed by an http server and which allows you to dynamically build HTML or XML pages. This program or servlet is called by the HTML document by the ⁇ form> tag which has an "action ⁇ " attribute which points to this program.
  • the object of this SERVLET ADAPTER program written in Java language is to automate the transcription of data from HTML forms managed by the client server into corresponding XML documents forming service calls to the MCMA 7 server. More specifically, the program concerns the conversion of HTML forms input data in XML tags and vice-versa.
  • the Web server will load into a database the HTML page corresponding to the called service (in this case "current account balance consultation"), and have it displayed on the user's computer.
  • This page consists of an HTML form or document comprising in particular a certain number of fields to be filled in by the user, for example the number of the current account whose balance is requested.
  • the user therefore fills in the requested data and sends it back to the Web server 4-6 in the form of a corresponding URL address.
  • this sending is operated in POST mode, that is to say by masking the data, in particular for reasons of confidentiality.
  • This HTML document is returned with the data entered by the user directly to the adapter module and more particularly to the SERVLET ADAPTER program, for example thanks to a masked code of type ⁇ form action- 'servlet url "> where" servlet url " is the address of the program housed in the web server.
  • the program deduces from a certain number of hidden tags in the form corresponding information such as for example the service call considered or the XSL files (Extensible Stylesheet Language) needed to convert responses from MCMA 7 server to HTML pages.
  • hidden tags also contain instructions of type "servlet: do” whose values are for example "call” which is the instruction to convert the form into XML and send it to the MCMA 7 server via the client connection module, or "build” which is the instruction to convert the document to XML but without sending it to the MCMA server
  • the SERVLET ADAPTER program also processes the data entered by the user data which constitute the parameters of the service call, i.e. the attributes of the action corresponds to the '' service call considered (in this case the current account balance call).
  • the transcription of this data in XML format is carried out by the SERVLET ADAPTER program as follows: the names of the parameters of the HTML tag "input name" are automatically converted into opening and closing XML tags with the same names. The values of the HTML input parameters are converted into the values of the XML tags (values located between the associated opening and closing tags).
  • sequences of input zones of the HTML document constitute the XML file to be sent to the business server.
  • Building the web page using the "name" attribute of each tag in this way allows the call to the business server to be defined at the same time, resulting in significant development time savings.
  • the HTML document having been converted to the XML format expected by the MCMA 7 server and sent to the latter, the response is treated in a similar way thanks to the indication of the XSL page to be used to display the result on the screen of the user's computer via the appropriate HTML page.
  • This connector comprises a communication module and a conversion module.
  • the communication module is suitable for communicating with "customer connections" (PLUG IN) using the same protocol (indeed, several customer connections, each written in a different technology such as VisualBasic or Java for example, can be compatible with the same connector incoming if they are based on the same communication protocol).
  • the conversion module converts an XML message into an action type (in the sense of object-oriented programming) in MCMA 7 server technology and vice versa, this module is commonly called the "XML parser”.
  • Each outgoing conversion chain is capable of ensuring communication between an application server 5 and the MCMA server 7 according to a chosen communication protocol.
  • An outgoing conversion chain is made up of different modules implemented on the MCMA server 7 and on a separate server called the integration server 28.
  • an outgoing integration connector (or OUT connector) 24, encapsulated in the MCMA 7 server and written in the technology of the MCMA 7 server.
  • This connector comprises a communication module and a conversion module.
  • the communication module is suitable for communicating with integration server connections (or PLUG OUT) 26, using the same protocol (in fact, several integration server connections, each written in a different technology such as C or COBOL for example, can be compatible with the same incoming connector if they are based on the same communication protocol);
  • the module for converting an object (in the sense of object-oriented programming) of the action type, in MCMA 7 server technology, into an XML message and vice versa It is the same “XML parser” module as that used in the “incoming connector” if the same XML format is used (note: an MCMA 7 server can have several different XML formats: canonical, compact, etc.)
  • connection module On the integration server side 28 there is therefore a connection module, integration server (or PLUG OUT) 26, a converter module and an application server connection module.
  • the integration server connection module 26 is responsible for communication 23 with an outgoing integration connector 24 of the MCMA server 7, this server connection module is encapsulated in the integration server, is written in the server technology d integration, it is responsible for exchanging XML messages with a single type of connector coming out of the MCMA 7 server via a single type of protocol, it is only responsible for exchanging XML messages, not for their analysis the reception of the call or their creation to the sending of the response.
  • the converter module converts messages in XML format from the MCMA 7 server into messages in the format specific to the application server, including the integration server, the converter module is responsible for analyzing XML messages representing actions forming service calls sent by the MCMA 7 server to convert them into a service call message in the specific format of the application server, including the integration server, and vice versa, creating XML messages to return to the MCMA 7 server as a result of a service call (this result, or this error if applicable, was initially provided by the application server (including the load integration server), this module is not responsible for exchanging messages.
  • the application server connection module is responsible for communicating messages with the application server, including the load integration server via a communication protocol specific to this application server, it is only responsible for the exchange of messages, not from their creation to sending or from their analysis to reception.
  • each service call is presented in the form of an action which is a class in object-oriented programming language, having attributes / input fields representing the parameters of the call of the service intended to be returned to said client server and a method able to encapsulate the call to a target server and / or to provide possible processing provided by the MCMA server 7.
  • the target server (MCMA 7 server, in the event of an incoming chain, application server in the event of an outgoing chain) in response to an action, is able to execute the latter in synchronous or asynchronous mode by rolling out the method associated with this action.
  • the corresponding action is not the same if it is in the MCMA 7 server or in the integration server.
  • the associated method will therefore not do the same work depending on whether one is in the incoming conversion chain (action of the MCMA 7 server) or the outgoing conversion chain (action of the integration server).
  • the XML message corresponds to an action by the MCMA 7 server
  • the corresponding method is executed in the MCMA 7 server. It generally allows any processing to be carried out on the input attributes / fields and / or send the service call via the corresponding outgoing conversion chain to the target application server (s) concerned so that it retransmits the service to the corresponding application server.
  • the MCMA 7 server via the action method being executed, then performs any processing on the data thus returned by the application server (s) and values the output attributes of the action which is then sent back to the sending client server, via the corresponding incoming conversion chain and in the format chosen by the latter.
  • the XML message corresponds to an action of the integration server
  • the corresponding method is executed in the integration server. It generally makes it possible to convert the XML message into a message forming a call for services in the specific format of the application server including the integration server, then to send it to this application server via the specific protocol of the application server to provide the service.
  • the integration server via the action method being executed, converts the result message to the specific format of the application server for which it is responsible, message result in XML format of the MCMA 7 server and the return.
  • the integration server relies on the modules presented above during the description of the components of the outgoing conversion chain.
  • the incoming conversion chain allows a client server 4 having specific formats and language to communicate with the MCMA server 7 whose language and format are different from these specific language and format.
  • the client server 4 is a dynamic Web server written in ASP.Net, to access application servers via the Internet.
  • the client server 4 uses for format XML messages which are different from the XML format of the MCMA server 7, and let us consider that on the MCMA server side 7, written for example in Java, the incoming connector 20 uses the SOAP protocol.
  • the corresponding incoming conversion chain therefore requires the client server side development of a client adaptation module to transform the XML messages from the client server into messages in XML format from the MCMA 7 server and vice versa.
  • the client server 4 will also host a client branching module 22 written in ASP.Net and using the SOAP protocol in order to communicate with incoming connector 20 to send the XML message created by the client adaptation module and recover the response from the MCMA server 7 .
  • the MCMA 7 server can also include outgoing software conversion chains.
  • the application server 5 is a banking application server written in COBOL, it uses flat text messages for format with data delimited by special characters such as "; »(CSV format).
  • the banking application server also uses the IP protocol for its communications with client systems as follows: each text message sent or received by the banking application server is preceded by a header consisting of 6 digits aligned to the right and supplemented by zeros on the left if necessary, then a space (white, ASCII character 32). This header gives the size of the following text message (number of bytes to read, after the blank), for example: "003585 datai; data2; ... ".
  • the outgoing connector 24 uses the IIOP protocol.
  • the corresponding outgoing conversion chain therefore requires the development of an independent integration server written for example in Java to adapt the calls sent by the MCMA 7 server in XML via the IIOP protocol to calls of text messages in CSV format via the protocol IP as described above and vice versa.
  • the application server 5, like the MCMA server 7, will not undergo any modification.
  • the integration server 28 hosts the "integration server connection module" 26 written in Java and using the IIOP protocol in order to communicate with outgoing connector 24 to receive the XML messages forming a service call sent by the MCMA 7 server.
  • the heart of the integration server is the converter module, written in Java, responsible for converting XML messages from the MCMA 7 server to a text message in CSV format expected by the banking application server 5.
  • the server integration must be completed by the development of an application server connection module, written in Java and using the IP protocol (as described above) in order to communicate with the banking application server to send the CSV text message created by the converter module and recover the response from the banking application server.
  • the “converter” module of the integration server or the “client adaptation” module of the client server can, depending on the language used and the formats to be converted, be based on products from the market for software package development tools to facilitate their work.
  • converting XML to flat files and vice versa can be implemented using an XSLT "Xalan” parser from the Open Source organization "Apache”.
  • converting an XML format to another XML format, or to database tables can be implemented by a converter based on the “Liquid Data” product, sold by company "BEA”.
  • the execution of service calls is of the synchronous or asynchronous type.
  • the incoming connectors 20 and / or outgoing 24 are synchronous or asynchronous.
  • Each connector of the MCMA 7 server is associated with a protocol which may belong to the group formed by the protocols IP, HTTP, CORBA / IIOP, JRMP, DCOM, COM, COM +, SOAP or the like.
  • Each connector can be associated with client or integration server connections, dedicated to the connector protocol and written in one of the languages belonging to the group formed by Java, C ++, Visual Basic, COBOL, PHP, PERL or the like.
  • the choice of connector associated with an application server is done by setting up the MCMA 7 server.
  • This setting indicates information such as the outgoing connector used and the data necessary for it to establish a connection to the server. 'integration.
  • an outgoing IP connector will have IP connection parameters such as the IP address and port of the integration server and the time after which it considers that the integration server will no longer respond (time out).
  • IP connection parameters such as the IP address and port of the integration server and the time after which it considers that the integration server will no longer respond (time out).
  • the software conversion chains according to the invention make it possible to reduce the costs of integration and operation of the MCMA 7 server with the client servers and the application servers by: - structuring the terms of integration of any client server with the MCMA 7 server (XML representing an action forming a service call provided by the MCMA 7 server, client connection, incoming connector);
  • client connections are already provided by the MCMA 7 server development team, they are tested for the language used by the client server, the protocol and the incoming connector chosen);
  • the integration server connection provides the starting strain for the integration server.
  • the client connections 22 and the application integration server connections 26 be developed by the same IT team as that responsible for developing the connectors of the MCMA server 7. If according to the language with which it is written the client server or the server integration, the customer connection does not exist, it is this team that is best placed to carry out this new module (enrichment of the "integration kit" of the corresponding connector and therefore enrichment of the MCMA 7 server). For the same reasons, if the incoming or outgoing connector does not exist depending on the protocol chosen, the team responsible for developing the MCMA 7 server must develop the missing connector and the corresponding first connection to test it ( enrichment of the MCMA server integration kit 7).
  • the IT team in charge of developing inbound connectors, outbound connectors, client connections and server connections, will advantageously set up trace functionalities (creation of log files) when sending / receiving messages to facilitate identification of the component responsible for malfunction in the event of a breakdown or the identification of the "bottleneck" component in the event of performance problems.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer And Data Communications (AREA)

Abstract

Procédé permettant de faire communiquer à l'intérieur d'un système informatique (1) de type distribué, une pluralité de serveurs client (4) possédant chacun des moyens logiciels et matériels spécifiques avec une pluralité de serveurs d'application (5) possédant chacun des moyens logiciels et matériels spécifiques et comprenant chacun au moins une application choisie (6), les serveurs client (4) étant. directement connectés à un unique serveur MCMA lequel est à son tour directement connecté à l'ensemble des serveurs d'application (5), de sorte que tout appel de service d'un serveur client à destination d'un serveur d'application donné, est d'abord adressé par ledit serveur client au serveur MCMA à charge pour ce dernier de le router au serveur d'application concerné et de faire remonter en retour d'éventuelles informations du serveur d'application vers le serveur client, chaque appel de service entre un serveur client (4) et le serveur MCMA (7) coopère avec une chaîne de conversion des langages et des formats, caractérisé en ce que lorsque que le serveur MCMA (7) utilise le langage XML et le serveur client (4-6) le langage HTML, alors la chaîne de conversion entrante associée comprend un module d'adaptation intégré au serveur client (4-6) utilisant un programme écrit en langage Java destiné à convertir automatiquement les formulaires HTML faisant appel de service en un document XML compréhensible de serveur MCMA (7).

Description

PROCEDE DE COMMUNICATION ENTRE SERVEURS AVEC CONVERSION DE FORMAT DES DONNEES ET DISPOSITIF POUR SA MISE EN OEUVRE
La présente invention se rapporte à la communication entre serveurs à l'intérieur d'un système informatique dit distribué, tel que notamment un système informatique financier utilisé par les banques ou encore par les compagnies d'assurance.
L'évolution des technologies informatiques au cours des dernières années a entraîné des modifications radicales dans la conception des applications. Les nouveaux réseaux de télécommunication rapides et à large bande passante (RNIS, ATM, High Performance Ethernet) ont permis l'interconnexion des ordinateurs dans des réseaux de dimensions de plus en plus importantes. Cette évolution a contribuée à l'émergence des applications distribuées qui mettent en oeuvre différents serveurs de natures distinctes destinés à communiquer les uns avec les autres pour gérer et traiter des flux de transactions et d'informations. Un serveur s'entend ici comme la combinaison de matériels informatiques (hardware) et de logiciels appropriés (software).
Ainsi, un système informatique financier comporte différents serveurs dits clients (ou encore de front office selon la terminologie anglo-saxonne) interconnectés à différents serveurs dits d'application (ou de back office) .
Les serveurs d'application sont plus particulièrement destinés à gérer des bases de données et à réaliser des traitements spécifiques encore appelés services. Le terme service est ici défini de façon générale comme tout traitement informatique, ce terme recouvre aussi bien la mise à disposition d'une information particulière comme un numéro de compte, que le calcul d'un solde ou encore un virement.
Le système informatique d'une banque comporte généralement un serveur d'application bancaire (exemple : moteur financier commercialisé par la société SAB) qui traite toutes les opérations liées à la gestion de comptes de dépôts, un serveur de crédit qui gère les prêts accordés par la banque à sa clientèle, un serveur boursier de gestion des valeurs mobilières (moteur boursier Investiciel commercialisé par la société SEMA), un serveur d'assurance, etc.
Les serveurs clients sont eux destinés à permettre aux employés et aux usagers de la banque d'accéder aux différents serveurs d'application depuis des interfaces et des réseaux de communication spécifiques, encore appelés canaux, pour fournir (opérations de mise à jour, etc.) ou récupérer (opérations d'interrogation, etc.) des données à travers des requêtes appelées appels de services. En effet, chaque requête reçue par un serveur d'application génère l'exécution d'un service correspondant par ce dernier.
Comme serveurs clients utilisés par le système informatique d'une banque, on peut citer un serveur gérant les ordinateurs équipant les guichets des banques, un serveur GAB/DAB associés aux guichets/ distributeurs automatisés, un serveur vocal qui permet aux usagers d'accéder aux serveurs d'application au moyen d'un téléphone, un serveur Web pour accéder à ces serveurs via l'Internet, un serveur Minitel, un serveur WAP, les serveurs des partenaires de l'organisme financier, etc. Une telle architecture est indispensable pour permettre d'obtenir par simple appel d'un téléphone numérique interrogeant une institution financière telle qu'une banque, le solde d'un compte courant ou bien encore pour imputer d'un compte courant la somme prélevée lors d'un retrait à un distributeur de billets de banque et fournir à son titulaire l'information quant au nouveau solde après cette opération.
Depuis quelques années, la connexion entre les serveurs clients et les serveurs d'applications se trouve être réalisée par l'intermédiaire d'un serveur particulier dit serveur MCMA pour serveur multi-canal et multi-application (appelé encore middleware dans la terminologie anglo-saxonne) auxquels sont connectés tous les serveurs client et tous les serveurs d'applications.
Un tel serveur MCMA assure le routage des données entre les serveurs mais également est à même de réaliser un certain nombre de fonctionnalités supplémentaires. Le serveur MCMA fait donc office d'unique serveur d'application pour les serveurs clients et d'unique serveur client pour les serveurs d'applications.
Grâce à cette architecture, le développement d'un nouveau serveur client ne nécessite qu'un seul travail de connexion au serveur MCMA. Le serveur MCMA est alors apte à fournir à ce nouveau serveur client l'ensemble des services disponibles sur les serveurs d'applications, selon un procédé de communication choisi. Il en est bien évidemment de même, lorsqu'il s'agit d'ajouter un nouveau serveur d'application.
Le document WO-A-98/24040 décrit un tel serveur. Une telle solution permet d'accéder à chaque serveur d'application de manière indépendante des connexions reliant le serveur MCMA aux serveurs client.
Toutefois, le procédé de communication proposé dans l'art antérieur entre les serveurs clients et les serveurs d'applications via le serveur MCMA n'est pas totalement satisfaisant dans la mesure où il est de mise en oeuvre relativement complexe ou inadaptée, notamment en ce qui concerne: - la mise en commun de fonctionnalités mises en oeuvre par le serveur MCMA pour le compte des serveurs clients ; - l'import/ export de données vers ou provenant des serveurs d'applications, dans le cadre d'un projet de migration de données issues d'autres systèmes informatiques par exemple ; - les modifications régulières dans les serveurs d'application
(évolutions, remplacement, dédoublement, etc.).
Par ailleurs, le système proposé dans l'art antérieur ne traite pas de l'intégration d'un serveur client et/ ou d'un serveur d'application ayant une technologie différente de celle du serveur MCMA, notamment en ce qui concerne le langage, le format ou encore le protocole de communication qui sont généralement différents du format du serveur MCMA.
Traditionnellement, lorsque qu'une adaptation d'une l'interface cliente doit être réalisée au format, au langage et au protocole attendus par le serveur MCMA, l'équipe informatique chargée de cette adaptation développe des programmes dits intermédiaires ou « middleware » dédiés à cette adaptation. Or, l'équipe informatique chargée de l'interface cliente peut être différente de celle en charge du serveur MCMA. Il en est de même du serveur d'application dont le développement peut être spécifique.
Il en résulte des temps de développement des programmes intermédiaires relativement longs et coûteux. De plus, la maintenance du système résultant est relativement plus complexe, tout comme l'identification des composants responsables de disfonctionnement ou de réduction des performances du système.
La présente invention remédie à ces inconvénients.
Elle porte sur un procédé, et un dispositif pour sa mise en oeuvre, de communication entre une pluralité de serveurs clients et une pluralité de serveurs d'applications comprenant chacun au moins une application choisie, les serveurs clients étant connectés à un unique serveur MCMA lequel est à son tour connecté à l'ensemble des serveurs d'applications, de sorte que tout appel de service d'un serveur client à destination d'un serveur d'application donné, est d'abord adressé par ledit serveur client au serveur MCMA à charge de ce dernier de le router au serveur d'application concerné et de faire remonter en retour d'éventuelles informations du serveur d'application vers le serveur client.
Le procédé selon l'invention est caractérisé en ce que lorsque que le serveur MCMA utilise le langage XML et le serveur client le langage HTML, alors la chaîne de conversion entrante associée comprend un module d'adaptation intégré au serveur client utilisant un programme écrit en langage Java, encore appelé servlet, destiné à convertir automatiquement les formulaires HTML faisant appel de service en un document XML compréhensible de serveur MCMA et inversement.
Selon une autre caractéristique du procédé objet de l'invention, le servlet réutilise les noms des paramètres de la balise HTML "input na e" comme noms de balises XML ouvrantes et fermantes, tandis que les valeurs des paramètres d'entrée HTML sont converties en valeurs des balises XML.
Selon une autre caractéristique du procédé objet de l'invention, les formulaires HTML traités par le servlet comprennent des paramètres cachés contenant des instructions commandant le déroulement dudit programme.
Selon une autre caractéristique du procédé objet de l'invention, les formulaires HTML traités par le servlet comprennent des paramètres cachés contenant des informations telles que le type d'appel de service ou encore des classes d'usage définissant des balises XML.
Selon une autre caractéristique du procédé objet de l'invention, les formulaires HTML traités par le servlet comprennent des paramètres cachés contenant des informations telles que les fichiers XSL nécessaires à la conversion de la réponse XML du serveur MCMA en document HTML.
Selon une autre caractéristique du procédé objet de l'invention, le servlet transfère l'appel de service au serveur MCMA après l'avoir converti au format XML en passant par un module de branchement client intégré au serveur client apte à communiquer avec un connecteur entrant associé intégré au serveur MCMA. Selon une autre caractéristique du procédé objet de l'invention, les serveurs client présentent les appels de service sous la forme d'action, ces actions étant des classes en langage de programmation orientée objet qui possèdent une structure de données et une méthode apte à encapsuler l'appel à destination d'un ou plusieurs serveurs d'application cibles et/ ou à prévoir d'éventuels traitements assurés par le serveur MCMA.
Selon une autre caractéristique du procédé objet de l'invention, chaque action formant appel de service est transférée entre serveurs sous la forme d'un document textuel structuré écrit en langage de balisage extensible du type XML ou analogue.
Selon une autre caractéristique du procédé objet de l'invention, l'action formant appel comprend un identifiant correspondant à l'identifiant du service cible, des attributs d'entrée représentant les paramètres de l'appel de service et d'éventuels attributs de sortie représentant le résultat du service destiné à être retourné audit serveur client
Selon une autre caractéristique du procédé objet de l'invention, les serveurs d'application utilisent une couche logicielle d'intégration et que les serveurs client utilisent une couche logicielle d'usage déduite de ladite couche d'intégration et en ce que la structure de données de d'une action formant appel de service coopère avec ladite couche d'usage.
D'autres caractéristiques et avantages de l'invention (comme par exemple la simplification/fîabilisation des modifications régulières dans les serveurs d'applications : remplacement, dédoublement, évolutions) apparaîtront à la lumière de la description détaillée ci- après et des dessins dans lesquels :
- la figure 1 est une représentation schématique d'un système informatique mettant en oeuvre le procédé de communication entre serveurs clients et serveurs d'applications selon l'invention ;
- la figure 2 illustre le procédé de communication selon l'invention ;
- la figure 3 est un schéma précisant la structure du serveur MCMA mis en œuvre dans le système informatique de la figure 1;
- la figure 4 représente schématiquement une chaîne de conversion entrante et une chaîne de conversion sortante selon l'invention ; - la figure 5 est une liste de connecteurs et de branchements selon l'invention ; et
- la figure 6 détaille un module d'une chaîne de conversion entrante opérant la conversion HTML/XML selon l'invention.
En référence à la figure 1, le système informatique décrit à titre d'exemple est le système informatique d'une institution financière et plus précisément d'une banque. Ce système informatique référencé 1 fournit une pluralité de services financiers gérés par des serveurs d'application spécialisés et accessibles par les employés ou les usagers à travers une pluralité d'interfaces clients 2.
Par exemple, les interfaces clients 2 peuvent être des téléphones numériques fixes 2a ou mobiles 2b, des guichets automatiques GAB
(non représentés), des succursales recevant du courrier 2c ou des télécopies 2d, des bureaux de vente de succursale (non représentés), des distributeurs de billets en libre-service DAB (non représentés), des ordinateurs personnels pour banque à domicile utilisant une connexion de type Internet 2g ou minitel 2f, des télévisions interactives 2e, etc.
Ces interfaces clients 2 sont connectées par des réseaux appropriés 3, individualisé en 3-1 à 3-6, à des serveurs client 4, individualisés en 4-1 à 4-6. Les serveurs 4 sont développés de façon spécifique en fonction des possibilités techniques de chaque interface 2 et de chaque réseau 3. Chaque interface et son réseau associé sont encore appelés canal.
Le système informatique 1 comprend en outre une pluralité de serveurs d'application 5, tels que par exemple, un serveur bancaire 5a, un serveur boursier 5b, un serveur d'assurance 5c, un serveur de crédit 5d, ou autre 5e. Chacun de ces serveurs 5 met en œuvre comprenant chacun au moins une application spécifique 6, respectivement référencée 6a à 6e.
Par ailleurs, un serveur 7 est intercalé entre les serveurs clients 4 et les serveurs d'applications 5. Ce serveur 7, appelé MCMA (acronyme pour Multi Canal et Multi Application) est commun à l'ensemble des serveurs clients 4 et apte à leur fournir l'ensemble des applications disponibles 6 sur les serveurs d'applications 5 auxquels il est également connecté, selon un procédé de communication choisi.
Il est à noter que de préférence, le serveur MCMA 7 ne sert pas uniquement à router des données des serveurs clients vers les serveurs d'applications et vice-versa mais également sert à opérer différents traitements, comme par exemple l'identification/authentification de l'utilisateur final et/ ou du serveur client, la gestion de mode dégradé (par exemple gestion de bases répliquées permettant de fournir des informations malgré l'indisponibilité des serveurs d'application concernés), le contrôle d'habilitation, l'audit des appels de service ou encore leur tarification, ...
Chaque serveur client 4 adapte l'appel émis par son canal correspondant, comme par exemple le serveur client WAP à partir d'un message émis par un téléphone mobile, sous une forme prédéterminée et l'envoi au serveur MCMA 7 selon un format et protocole attendu par le serveur MCMA 7.
Le serveur MCMA 7 propose plusieurs formats et protocoles afin de s'adapter aux contraintes technologiques d'un serveur client 4 et d'un réseau 3 quelconque. Les formats proposés par le serveur MCMA 7 peuvent être fichier binaire (sérialisation d'objet Java, ou C++, Visual Basic, etc.) ou texte « à plat », fichier XML.
Les protocoles proposés par le serveur MCMA 7 peuvent être IP, HTTP, CORBA/IIOP, JRMP, DCOM, COM, COM+, etc.
Les moyens mis en oeuvre pour permettre la communication entre les serveurs clients et le serveur MCMA 7 comprennent des modules logiciels constituant une chaîne de conversion dite "entrante" qui sera détaillée ultérieurement.
Le procédé de communication entre les serveurs client 4 et les serveurs d'applications 5 du système informatique distribué 1 est articulé autour de la notion d'action. Ce procédé consiste plus particulièrement à présenter chaque appel de service sous la forme d'une action.
Pour rappel, une action est une classe en langage de programmation orientée objet (Java, C++, etc.), possédant des attributs /champ s d'entrée représentant les paramètres de l'appel de service et d'éventuels attributs /champ s de sortie représentant le résultat du service destiné à être retourné audit serveur client et une méthode apte à encapsuler l'appel à destination d'un ou plusieurs serveurs d'application cibles et/ou à prévoir d'éventuels traitements assurés par le serveur MCMA 7.
Ainsi, à chaque service correspond une action qui encapsule l'appel à destination du ou des serveurs d'application cibles via le serveur MCMA 7 ou encore des traitements mis en œuvre directement par le serveur MCMA 7.
Le serveur d'application 5 logeant le service cible 6 reçoit l'appel du service cible, émis par le serveur MCMA 7, selon les formats et protocoles spécifiques du serveur d'application 5 et renvoie la réponse (résultat de service ou erreur) au serveur MCMA 7 toujours selon ses formats et protocoles spécifiques du serveur d'application 5.
En référence à la figure 2, le procédé de communication comprend les étapes suivantes:
- étape (i), instanciation
Il s'agit de créer, par exemple par le serveur minitel 4-6, une instance de classe (selon la terminologie de la programmation orientée objet) de type action qui correspond au service « solde du compte courant N » suite à une demande d'appel (request) émanant d'une interface cliente 2g, en l'occurrence d'un minitel utilisé par un usager lequel souhaite connaître le solde de son compte courant ;
- étape (ii), le serveur minitel 4-6 valorise les attributs d'entrée de l'action en fonction des données fournies par l'usager et envoi l'action au serveur MCMA 7 selon le protocole et le format de son choix parmi ceux proposés par ce dernier (« uneAction » est une instance (un objet, une variable) de la classe (du type) « FxAction » (une FxAction est le nom technique qui désigne action générique) ;
- étape (iii), le serveur MCMA 7 reçoit l'action et l'exécute en déroulant la méthode associée. Cette méthode associée a un comportement qui varie en fonction des valeurs de tout ou partie des attributs d'entrées. C'est entre autre ici que peuvent être fournies des fonctionnalités supplémentaires tels que l'identification de l'usager, le contrôle d'habilitation, l'audit des appels de service, etc.;
- étape (iv), la couche d'intégration que l'on décrira plus en détail ci après du serveur MCMA 7 est sollicitée par l'action "solde compte courant" pour qu'elle effectue l'appel de service cible correspondant sur le serveur d'application concerné (ici le serveur bancaire 5a) selon les formats et protocoles de communication spécifiques de ce dernier. (entryPoint.invoke(uneAction) est une instruction en langage objet, en l'occurrence c'est l'instruction qui provoque le déroulement de la méthode associée à l'action quelconque « uneAction » dans le serveur MCMA 7) ; - étape (v), le serveur d'application exécute le service demandé décrit par l'appel à savoir la lecture ou le calcul du solde du compte et retourne le résultat correspondant au serveur MCMA 7 selon le format et le protocole de communication spécifiques du serveur d'application ;
- étape (vi), la couche d'intégration du serveur MCMA 7 restitue les données résultats fournis par le serveur d'application à la méthode associée à l'action. Celle-ci valorise donc les attributs résultats de l'action, en fonction des données reçues par le serveur d'application 5a. C'est entre autre ici que peuvent être fournies des fonctionnalités supplémentaires tels que l'audit des réponses de service, la tarification, le mode dégradé (ex : en cas d'erreur, lire le solde en base de données répliquées quotidiennement), etc.;
- étape (vii), Lorsque la méthode associée à l'action est terminée, le serveur MCMA 7 retourne l'action vers le minitel 2g via le serveur minitel 4-6 ;
- étape (viii), le minitel reçoit et affiche le résultat.
En se reportant à la figure 3, la structure du serveur MCMA 7 va être plus particulièrement détaillée.
De façon préférentielle, l'architecture logicielle du serveur MCMA 7 est notamment constituée de deux couches logicielles distinctes : une couche usage 10 et une couche intégration 12. Il est à noter que la couche d'intégration peut être entièrement résidente dans le serveur MCMA 7 comme décrit à la figure 3 ou bien encore résider en partie dans le serveur MCMA 7 et en partie dans un ou plusieurs serveurs d'intégration comme illustré à la figure 4.
La couche d'usage 10 est une couche intermédiaire qui complète, simplifie et facilite l'utilisation des services fournis par les serveurs d'applications 5. C'est la couche d'usage 10 qui est utilisée comme interface pour accéder à la couche d'intégration 12 depuis les serveurs client 4.
La couche d'usage 10 est constituée notamment de l'ensemble des actions disponibles depuis le serveur MCMA 7 (voir description ci- avant) et de classes de type « objet d'usage ».
Un objet d'usage peut être considéré comme une vue d'une ou plusieurs structures de données utilisées par les serveurs d'application 5. Cette vue est une représentation commune à toutes les structures de données équivalentes dans les serveurs d'applications concernées. Par exemple, l'objet d'usage « UsageCompte » pourra être utilisé pour représenter un compte de dépôt d'un serveur bancaire 5a, ou encore un compte titres du serveur bourse 5b.
Le mécanisme d'héritage apporté par le concept de classe (programmation orientée objet) permet encore de renforcer la mise en commun des informations. Par exemple, les comptes de dépôt pourront être représentés par des objets d'usage « UsageCompteDepôt » qui héritent des attributs (données membres) de l'objet d'usage « UsageCompte » et qui ne possèdent que les attributs supplémentaires spécifiques à un compte de dépôts par rapport à un compte abstrait et générique « UsageCompte ». Ce dernier pourra également être hérité par plusieurs autre type d'objet d'usage (dit « fils ») tels que « UsageCompteEpargne », « UsageCompteTitres », etc. Ainsi une action représentant le service « liste des comptes d'un client » pourra fournir la liste de tous les types de comptes hébergés par tous les serveurs d'applications gérant des comptes. Une telle action possède un attribut de sortie de type « tableau de UsageCompte » qui contiendra, par exemple en résultat pour un client, par polymorphisme (concept de la programmation orienté objet) : un compte de dépôt, un compte d'épargne et un compte titres, chacun géré par des serveurs d'applications différents.
Ainsi l'ensemble des objets d'usage facilite et simplifie la représentation des structures de données qui sont par définition variables selon le serveur d'application. Les objets d'usage permettent la mutualisation des formats d'échanges entre les serveurs clients et le serveur MCMA 7 quel que soit le serveur d'application concerné.
La couche d'usage 10 permet également de stabiliser les formats fournis aux serveurs client en cas de modification dans un serveur d'application 5, ou le remplacement de l'un d'eux par un nouveau serveur d'application. Par exemple, si l'on considère que le serveur bancaire 5a possède une structure de donnée « solde de compte » qui agrège les soldes comptables, valeur et espèce d'un compte, et ces différents soldes sont donc représentés dans la classe « UsageSolde » afin d'être disponibles aux serveurs clients. Le remplacement du serveur bancaire 5a par un nouveau serveur d'application qui ne possède pas de solde espèce, n'entraînera pas de modification de l'objet d'usage « UsageSolde » et donc ne nécessitera pas la modification des serveurs clients. L'information manquante sera soit renseignée à une valeur par défaut, soit calculée par le serveur MCMA 7.
II est à noter que si le nouveau serveur d'application bancaire possède de nouvelles informations concernant le solde (ex : solde fin de mois précédent), on pourra enrichir l'objet d'usage « UsageSolde » d'un nouvel attribut.
La couche d'usage 10, par ces apports en simplification et stabilisation des formats d'échanges avec les serveurs client, facilite ainsi la prise en charge de modifications régulières dans les serveurs d'applications (remplacement, dédoublement, évolutions).
Les informations contenues par les classes de données d'usage proviennent des serveurs d'application 5. Par exemple, la donnée solde comptable de l'objet d'usage compte provient du serveur bancaire 5a. Pour valoriser leurs attributs de sortie, les actions de la couche d'usage appellent la couche d'intégration 12 (et la couche de services supplémentaires 11 pour les fonctionnalités du serveur MCMA 7 qui ne sont pas disponibles dans les serveurs d'applications).
Ainsi, ce n'est pas la couche d'usage 10 qui est en charge de la communication avec les serveurs d'applications 5 mais la couche d'intégration 12.
La couche d'intégration 12 est compartimentée en deux sous- systèmes: un sous-système de routage 13 et un sous-système d'intégration 14 comprenant des modules logiciels formant des chaînes de conversion, dites "sortantes", avec chacun des serveurs d'application 5. Seuls ont été représentés les modules 14a et 14b correspondant respectivement aux serveurs bancaire 5a et boursier 5b
Le sou s- système de routage 13 est le point d'entrée des actions de la couche d'usage 10. Il est chargé de déterminer en fonction des données représentées par un objet d'usage (ex : type de compte, n° du compte, n° du client) le ou les serveurs d'applications concernés et donc le ou les modules d'intégrations 14 à qui déléguer la communication. Pour les modules d'intégration 14 concernés, le sou s- système de routage 13 fourni l'objet d'usage et le service à appeler dans le serveur d'application.
Les modules d'intégration 14 constituant une chaîne de conversion sortante sont donc chargés de la communication avec un serveur d'application spécifique 5 selon les formats et protocoles attendus par ce serveur d'application. Ils sont également capables de convertir des structures de données spécifiques provenant du serveur d'application en objet d'usage et inversement. Une telle chaîne de conversion sortante sera plus détaillée ultérieurement.
Le travail effectué par chaque composant du serveur MCMA 7 va être illustré dans l'exemple suivant : consultation du compte X d'un client Y sur le serveur d'application 5a.
L'action « liste des soldes de tous les comptes d'un client » va d'abord rechercher, via un service dit de « CRM » ( acronyme de Customer
Relation Management, c'est-à-dire Gestion de la Relation Client) de la couche de service supplémentaire 11, la liste des numéros de comptes détenus dans la base de données 15. Puis pour chaque numéro de compte, va demander à la couche d'intégration 12 le solde correspondant en lui fournissant un objet d'usage « UsageSolde » avec des soldes non renseignés. Le sous-système de routage 13 va, en fonction du numéro de compte et du type de compte, déterminer la chaîne de conversion sortante du sous- système d'intégration 14 concernée et lui demander de faire l'appel du service cible adéquat en lui fournissant l'objet d'usage vide. Le sous-système d'intégration 14 va appeler le service cible via les formats et protocoles attendus par le serveur d'application concerné, remplir l'objet d'usage avec les résultats fournis par le serveur d'application et retourner l'objet d'usage ainsi renseigné au sous- système de routage 13 qui le lui retournera à l'action demanderesse.
Pour transmettre les actions formant appel de service entre les différents serveurs du système informatique 1, on utilise des fichiers écrits de préférence avec un langage de structuration encore appelé langage de balisage extensible, tel que le XML (acronyme anglo-saxon pour extensible Markup Language).
Un document structuré est une collection d'ensembles d'informations associés chacun à un type et des attributs, et composés entre eux selon des relations principalement hiérarchiques. Un tel document permet notamment de distinguer les différents sous-ensembles d'informations composant le document. Par opposition, dans un document dit linéaire, les informations de contenu du document sont mélangées aux informations de présentation et de typage.
Un document structuré inclut des repères de séparation des différents ensembles d'informations du document. Dans le cas du format XML, ces repères appelées « balises » sont de la forme « <b> » (balise ouvrante) et « </b> » (balise fermante), le premier repère indiquant le début d'un ensemble d'informations nommé « b » et le second la fin de cet ensemble.
Contrairement au langage HTML (HyperText Markup Language), le langage XML n'est pas sémantiquement figé. Il permet de définir ses propres balises, ce qui le rend adaptable et donc à même de stocker tout types d'informations.
Un document structuré est associé à ce que l'on appelle un schéma de structure ou DTD (Document Type Définition) définissant sous la forme de règles la structure et le type d'information de chaque ensemble d'informations du document. Un schéma est constitué de groupes imbriqués de structures d'ensembles d'informations, ces groupes pouvant être des séquences ordonnées, des groupes d'éléments alternatifs ou des groupes d'éléments nécessaires, ordonnés ou non ordonnés.
Les documents XML reçus par les serveurs du système informatique 1 sont traités par une interface de programmation d'application correspondante (API , Application Programming Interface) écrite en langage orienté objet et servant d'analyseur XML (ou XML parser) pour analyser et décoder les balises de ces documents.
Ainsi, à chaque action (représentant un service d'usage et les données d'usage utilisées le cas échéant) est associée une description écrite en langage XML. zu
Un tel langage de balisage permet de fournir des formats de données sans se restreindre à une plate-forme technique quelle soit matérielle ou logicielle.
De plus, la représentation sous forme de texte écrit en langage XML de chaque action permet de créer simplement, via un simple éditeur de texte, un fichier XML décrivant une ou plusieurs actions d'appel de services.
Le résultat de ses actions, également écrit en XML sera également facile à interpréter depuis un simple éditeur de texte.
Il est intéressant de s'appuyer sur un langage de balisage extensible du type XML dans le cadre de fonctions d 'import/ export de données en association avec les demandes d'appel (respectivement attributs d'entrée et attributs de sortie).
La mise en oeuvre d'un tel langage de type XML se fait donc en associant une balise XML à chaque action, ces balises contenant elles même une balise pour chaque attribut d'entrée et pour chaque attribut de sortie des actions.
Très avantageusement, les attributs d'entrée des actions qui correspondent à des traitements d'écriture, création ou modification de données, sont transférés (injectées/importées) dans les serveurs d'application via le serveur MCMA 7 sous la forme d'un fichier texte écrit en langage de balisage extensible du type XML ou analogue.
Ainsi les migrations de données vers un système informatique utilisant un procédé de communication par action et par XML nécessiteront seulement la réécriture de programme d'extraction des données du système source sous forme de fichier d'extraction XML correspondant à des actions du serveur MCMA 7.
De plus, toute création de nouvelle action qui correspond à un traitement d'écriture sera une solution d'importation de données supplémentaire dans le cadre d'une prochaine migration. Par exemple la création d'une nouvelle action, suite à un nouveau besoin d'un serveur client WEB, destiné à la création d'adresse, facilitera les futures importations des adresses email d'un système informatique source ou permettra de compléter le flux de données provenant d'une société partenaire fournissant des données de personnes à prospecter.
De même, les attributs de sortie des actions qui correspondent à des traitements de lecture, recherche ou consultation de données sont transférés (extraites/exportées) des serveurs d'application correspondants via le serveur MCMA 7 sous la forme d'un fichier texte écrit en langage de balisage extensible du type XML ou analogue.
Les avantages fournis par les actions descriptibles en XML sont donc également valables dans le cadre d'export de données, lors du rachat de la banque ou de la mise en place de flux de données périodiques avec le système informatique d'une société partenaire (B2B).
Lorsque que l'action courante (demande d'appel contenant des nouvelles données à écrire dans le service cible demandé) correspond à un service d'écriture dans le système (création, modification, etc.), l'opération est alors dite « import multi-moteur », car les données dans le fichier XML fournies en entrée sont injectées dans le système via le serveur intermédiaire MCMA 7.
Inversement, lorsque que l'action utilisée correspond à un service de lecture dans le système (recherche, consultation, etc.), l'opération est alors dite « export multi-moteur », car le fichier XML résultat contient une extraction des données du système via le serveur intermédiaire MCMA 7.
Un tel import/export de données en XML a l'avantage de simplifier le traitement des actions dans un environnement informatique à plusieurs serveurs client et plusieurs serveurs de services, via un serveur MCMA 7.
Les communications entre les serveurs clients 4 et le serveur MCMA 7 d'une part, et entre le serveur MCMA 7 et les serveurs d'application 5 d'autre part, utilisent des chaînes de conversion logicielle, appelées respectivement entrantes et sortantes par référence au serveur MCMA 7. Le seul invariant de ces chaînes de conversion est l'utilisation de messages XML représentant des actions pour communiquer avec le serveur MCMA 7.
Chaque chaîne de conversion entrante est apte à assurer la communication entre un serveur client donné 4 et le serveur MCMA 7 selon un protocole de communication choisi.
Une chaîne de conversion entrante se compose de différents modules implémentés sur le serveur client 4 et sur le serveur MCMA 7. Côté serveur client 4 on a un module adapteur client et un module de branchement client
Le module adapteur client adapte les messages du format spécifique au serveur client au format XML du serveur MCMA 7. Le module adapteur client est chargé, suite a une demande (message au format spécifique du serveur client) initiée par le module fonctionnel du serveur client (par « module fonctionnel », on entend le module fournissant le cœur des fonctionnalités propres à ce serveur client, par exemple si le serveur client est un serveur WEB, ce module fournis les fonctionnalités propres à un serveur WEB et gère des données propres à un serveur WEB), de la création de messages XML correspondants pour envoi au serveur MCMA 7 d'une action formant appel de service, et inversement, de l'analyse des messages XML résultat retourné par le serveur MCMA 7 pour les reconvertir en message dans un format reconnu par le serveur client ou en erreur le cas échéant. Ce module n'est pas chargé de l'échange des messages XML.
Le module de branchement client (ou PLUG IN) 22 est chargé de la communication 21 avec un connecteur entrant (ou connecteur IN) 20 du serveur MCMA 7. Ce module est écris dans la technologie du serveur client. Il est chargé de l'échange de messages XML avec un seul type de connecteur entrant du serveur MCMA 7 via un seul type de protocole. Il n'est chargé que de l'échange des messages XML, pas de leur création à l'envoi ou de leur analyse à la réception.
Selon l'invention, dans le cas où le module adapteur fonctionne sur un serveur client 4, tel que le serveur Web, s'appuyant sur des formulaires HTML, le module adaptateur utilise de préférence un Servlet Java encore appelé SERVLET ADAPTER. Un tel module est plus particulièrement détaillé en regard de la figure 6.
La norme CGI (Common Gateway Interface) est la norme qui définit les pages WEB dynamique (i.e. qui appellent un serveur qui fait des traitements comme une lecture dans une base de données ou un écriture, etc.) On utilise des formulaires HTML (balise HTML <form action≈"...adresse du serveur....">) possédant des zones de saisie (balise <input>) et des boutons (balise <input type="button" ou "submit">). Un Servlet (contraction de "server applet") est un programme Java qui est exécuté par un serveur http et qui permet de construire dynamiquement des pages HTML ou XML. Ce programme ou servlet est appelé par le document HTML par la balise <form> qui a un attribut "action≈" qui pointe vers ce programme.
L'objet de ce programme SERVLET ADAPTER écrit en langage Java est d'automatiser la transcription des données des formulaires HTML gérés par le serveur client en documents XML correspondants formant appels de service au serveur MCMA 7. Plus particulièrement, le programme concerne la conversion des données d'entrée des formulaires HTML en balises XML et vice-versa.
Considérons par exemple un utilisateur souhaitant connaître le solde de son compte par Internet. L'utilisateur utilise alors son ordinateur personnel 2f, un navigateur (browser) résident de type Netscape Communicator ™ et un opérateur de télécommunication approprié (service provider) pour accéder à Internet et plus particulièrement au site Internet de son établissement financier. Ce site est hébergé sur un serveur Web 4-6. La connexion au serveur 4-6 est opérée de façon classique via l'adresse URL de ce site. Ayant été connecté au site de sa banque, l'utilisateur va ensuite se déplacer depuis la page d'accueil et demander un service particulier comme le solde de son compte courant.
En réponse à cette demande, le serveur Web va charger dans une base de donnée la page HTML correspondante au service appelé (en l'occurrence "consultation solde compte courant"), et la faire afficher sur l'ordinateur de l'utilisateur. Cette page est constitué par un formulaire ou document HTML comportant en particulier un certain nombre de champs devant être renseignés par l'utilisateur comme par exemple le numéro du compte courant dont le solde est demandé. L'utilisateur remplit donc les données demandées et les renvoie au serveur Web 4-6 sous la forme d'une adresse URL correspondante. De préférence, cet envoi est opéré en mode POST c'est-à-dire en masquant les données et ce, notamment pour des raisons de confidentialité.
Ce document HTML est retourné avec les données saisies par l'utilisateur directement au module adapteur et plus particulièrement au programme SERVLET ADAPTER et ce, par exemple grâce à un code masqué de type <form action- 'servlet url"> où "servlet url" est l'adresse du programme logé dans le serveur Web.
A charge pour le module adapteur de bâtir un appel de service correspondant au format XML à la réception de ce document.
Tout d'abord, le programme déduit d'un certain nombre de balises cachées dans le formulaire des informations correspondantes comme par exemple l'appel de service considéré ou encore les fichiers XSL (extensible Stylesheet Language) nécessaires pour convertir les réponse du serveur MCMA 7 en pages HTML. Ces balises cachées renferment également des instructions de type "servlet: do" dont les valeurs sont par exemple "call" qui est l'instruction de convertir le formulaire en XML et de l'envoyer au serveur MCMA 7 via le module de branchement client, ou encore "build" qui est l'instruction de convertir le document en XML mais sans l'envoyer au serveur MCMA
7, le transfert intervenant avec la transcription d'un document HTML ultérieur comportant l'instruction "call" auquel le premier document va être concaténé. L'instruction "call" est par exemple écrite sous la forme :
<input type="hidden" name="servlet:do" value="call">
Les balises cachées ayant été traitées, le programme SERVLET ADAPTER opère également le traitement des données saisies par l'utilisateur données qui constituent les paramètres de l'appel de service, c'est-à-dire les attributs de l'action correspond à l'appel de service considéré (en l'occurrence l'appel solde compte courant).
La transcription de ces données au format XML est opérée par le programme SERVLET ADAPTER de la façon suivante: les noms des paramètres de la balise HTML "input name" sont automatiquement convertis en balises XML ouvrantes et fermantes de mêmes noms. Les valeurs des paramètres d'entrée HTML sont converties en valeurs des balises XML (valeurs situées entre les balises ouvrantes et fermantes associées).
Considérons l'exemple suivant:
Le code initial HTML <input name="numeroCompte" type="text"> </input> est converti en code XML <numeroCompte> 1234234516942103 l</numeroCompte> après que l'utilisateur est saisi 12342345169421031 comme numéro du compte dont le solde est demandé.
Ainsi les enchaînements de zone de saisies du document HTML constitue le fichier XML à envoyer au serveur métier. Construire la page Web en utilisant de cette façon l'attribut "name" de chaque balise permet de définir en même temps l'appel au serveur métier d'où un gain de temps de développement conséquent.
Bien évidemment un certain nombre de balises XML peuvent être cachées comme par exemple les balises définissant le début de classes d'usage. On a ainsi:
<input type="hidden" name- 'UsageEntiteTitulaire name=titulaire">...<input type="hidden" name="/UsageEntiteTitulaire"> qui se trouve transcrit en : < UsageEntiteTitulaire> ...</ UsageEntiteTitulaire>
Le document HTML ayant été converti au format XML attendu par le serveur MCMA 7 et envoyé à ce dernier, la réponse est traitée de façon similaire grâce à l'indication de la page XSL devant être utilisée pour afficher le résultat sur l'écran de l'ordinateur 2f de l'utilisateur via la page HTML appropriée.
Côté serveur MCMA 7 on a donc un connecteur entrant 20, encapsulé dans le serveur MCMA 7 et écris dans la technologie du serveur MCMA 7. Ce connecteur comprend un module de communication et un module de conversion. Le module de communication est adapté pour communiquer avec des « branchements clients » (PLUG IN) utilisant le même protocole (en effet, plusieurs branchements clients, écris chacun dans une technologie différente comme VisualBasic ou Java par exemple, peuvent être compatibles avec un même connecteur entrant s'ils s'appuient sur le même protocole de communication).
Le module de conversion convertit un message XML en objet (au sens de la programmation orienté objet) de type action, dans la technologie du serveur MCMA 7 et inversement, ce module est communément appelé le « parseur XML ».
Chaque chaîne de conversion sortante est apte à assurer la communication entre un serveur d'application 5 et le serveur MCMA 7 selon un protocole de communication choisi.
Une chaîne de conversion sortante se compose de différents modules implémentés sur le serveur MCMA 7 et sur un serveur distinct dit appelé serveur d'intégration 28.
Côté serveur MCMA 7, on a un connecteur sortant d'intégration (ou connecteur OUT) 24, encapsulé dans le serveur MCMA 7 et écris dans la technologie du serveur MCMA 7. Ce connecteur comprend un module de communication et un module de conversion.
Le module de communication est adapté pour communiquer avec des branchements serveur d'intégration (ou PLUG OUT) 26 ,utilisant le même protocole (en effet, plusieurs branchements serveur d'intégration, écris chacun dans une technologie différente comme C ou COBOL par exemple, peuvent être compatibles avec un même connecteur entrant s'ils s'appuient sur le même protocole de communication) ;
Le module de conversion d'un objet (au sens de la programmation orienté objet) de type action, dans la technologie du serveur MCMA 7, en message XML et inversement. C'est le même module « parseur XML » que celui utilisé dans le « connecteur entrant » si le même format XML est utilisé (note : un serveur MCMA 7 peut disposer de plusieurs formats XML différents : canonique, compacte, etc.)
Côté serveur d'intégration 28 on a donc un module de branchement, serveur d'intégration (ou PLUG OUT) 26, un module convertisseur et un module de branchement serveur d'application.
Le module de branchement serveur d'intégration 26 est chargé de la communication 23 avec un connecteur sortant d'intégration 24 du serveur MCMA 7, ce module de branchement serveur est encapsulé dans le serveur d'intégration, est écris dans la technologie du serveur d'intégration, il est chargé de l'échange de messages XML avec un seul type de connecteur sortant du serveur MCMA 7 via un seul type de protocole, il n'est chargé que de l'échange des messages XML, pas de leur analyse à la réception de l'appel ou de leur création à l'envoi de la réponse.
Le module convertisseur convertit les messages au format XML du serveur MCMA 7 en messages dans le format spécifique au serveur d'application dont le serveur d'intégration à la charge, le module convertisseur est chargé de l'analyse des messages XML représentant des actions formant appels de service émis par le serveur MCMA 7 pour les convertir en message formant appel de services dans le format spécifique du serveur d'application dont le serveur d'intégration à la charge, et inversement, de la création de messages XML à retourner au serveur MCMA 7 comme résultat d'appel de service (ce résultat, ou cette erreur le cas échéant, a été fourni initialement par le serveur d'application dont le serveur d'intégration à la charge), ce module n'est pas chargé de l'échange des messages.
Le module de branchement serveur d'application est chargé de la communication des messages avec le serveur d'application dont le serveur d'intégration à la charge via un protocole de communication spécifique à ce serveur d'application, il n'est chargé que de l'échange des messages, pas de leur création à l'envoi ou de leur analyse à la réception.
Selon le protocole de communication choisi pour la chaîne entrante ou sortante, chaque appel de service est présenté sous la forme d'une action qui est une classe en langage de programmation orientée objet, possédant des attributs/ champs d'entrée représentant les paramètres de l'appel du service destiné à être retourné audit serveur client et une méthode apte à encapsuler l'appel à destination d'un serveur cible et/ou à prévoir d'éventuels traitements assurés par le serveur MCMA 7.
Le serveur cible (serveur MCMA 7, en cas de chaîne entrante, serveur d'application en cas de chaîne sortante) en réponse à une action, est apte à exécuter cette dernière en mode synchrone ou asynchrone en déroulant la méthode associée à cette action. Pour un même message XML l'action correspondante n'est pas la même si elle se trouve dans le serveur MCMA 7 ou dans le serveur d'intégration. La méthode associée ne fera donc pas le même travail selon que l'on se trouve dans la chaîne de conversion entrante (action du serveur MCMA 7) ou la chaîne de conversion sortante (action du serveur d'intégration).
Ainsi pour la chaîne de conversion entrante, le message XML correspond à une action du serveur MCMA 7, la méthode correspondante est exécutée dans le serveur MCMA 7. Elle permet généralement d'opérer d'éventuels traitements sur les attributs/ champs d'entrée et/ou d'envoyer au(x) serveur(s) d'application cible(s) concerné(s) l'appel de service via la chaîne de conversion sortante correspondante pour qu'elle retransmette le service au serveur d'application correspondant. Lorsqu'il reçoit le résultat de l'appel service, le serveur MCMA 7, via la méthode de l'action en cours d'exécution, opère alors d'éventuels traitements sur les données ainsi retournées par le ou les serveurs d'application et valorise les attributs de sortie de l'action qui est ensuite remontée au serveur client émetteur, via la chaîne de conversion entrante correspondante et au format choisi par ce dernier.
Dans le cas d'une chaîne de conversion sortante, le message XML correspond à une action du serveur d'intégration, la méthode correspondante est exécutée dans le serveur d'intégration. Elle permet généralement de convertir le message XML en en message formant appel de services dans le format spécifique du serveur d'application dont le serveur d'intégration à la charge, puis de l'envoyer à ce serveur d'application via le protocole spécifique du serveur d'application pour qu'il fournisse le service. Lorsqu'il reçoit le résultat de l'appel service, le serveur d'intégration, via la méthode de l'action en cours d'exécution, reconverti le message résultat au format spécifique du serveur d'application dont il a la charge, en message résultat au format XML du serveur MCMA 7 et le lui retourne. Pour réaliser son travail, le serveur d'intégration s'appuie sur les modules présentés ci-dessus lors de la description des composants de la chaîne de conversion sortante.
En pratique, la chaîne de conversion entrante permet à un serveur client 4 ayant des formats et langage spécifiques de communiquer avec le serveur MCMA 7 dont le langage et le format sont différents de ces langage et format spécifiques.
Par exemple, considérons que le serveur client 4 est un serveur Web dynamique écris en ASP.Net, pour accéder aux serveurs d'application via l'Internet. Le serveur client 4 utilise pour format des messages XML qui sont différent du format XML du serveur MCMA 7, et considérons que côté serveur MCMA 7, écrit par exemple en Java, le connecteur entrant 20 utilise le protocole SOAP.
La chaîne de conversion entrante correspondante nécessite donc le développement coté serveur client d'un module d'adaptation client pour transformer les messages XML du serveur client en messages au format XML du serveur MCMA 7 et inversement. Le serveur client 4 hébergera également un module de branchement client 22 écris en ASP.Net et utilisant le protocole SOAP afin de communiquer avec connecteur entrant 20 pour envoyer le message XML créé par le module d'adaptation client et récupérer la réponse du serveur MCMA 7.
Le serveur MCMA 7 peut également comprendre des chaînes de conversion logicielle sortantes. Par exemple, considérons que le serveur d'application 5 est un serveur d'application bancaire écris en COBOL, il utilise pour format des messages textes à plat avec des données délimitées par des caractères spéciaux comme le « ; » (format CSV). Le serveur d'application bancaire utilise également pour ses communications avec des systèmes clients, le protocole IP de la façon suivante : chaque message texte envoyé ou reçus par le serveur d'application bancaire est précédé d'une entête composée de 6 chiffres alignés à droite et complétés par des chiffres zéros à gauche si nécessaire puis d'un espace (blanc, caractère ASCII 32). Cette entête donne la taille du message texte qui suit (nombre d'octets à lire, après le blanc), par exemple : « 003585 datai ;data2; ... ». Considérons par ailleurs que côté serveur MCMA 7 (écris par exemple en C++), le connecteur sortant 24 utilise le protocole IIOP.
La chaîne de conversion sortante correspondante nécessite donc le développement d'un serveur d'intégration indépendant écrit par exemple en Java pour adapter les appels émis par le serveur MCMA 7 en XML via le protocole IIOP en appels de messages textes au format CSV via le protocole IP de la façon décrite précédemment et inversement. Le serveur d'application 5, tout comme le serveur MCMA 7, ne subira aucune modification. Pour effectuer son travail, le serveur d'intégration 28 héberge le « module de branchement serveur d'intégration » 26 écris en Java et utilisant le protocole IIOP afin de communiquer avec connecteur sortant 24 pour recevoir les messages XML formant appel de service émis par le serveur MCMA 7. Le cœur du serveur d'intégration est le module convertisseur, écris en Java, chargé de convertir les messages XML du serveur MCMA 7 en message texte au format CSV attendu par le serveur d'application bancaire 5. Enfin, le serveur d'intégration doit être complété par le développement d'un module de branchement serveur d'application, écris en Java et utilisant le protocole IP (de la façon décrite précédemment) afin de communiquer avec le serveur d'application bancaire pour envoyer le message texte CSV créé par le module convertisseur et récupérer la réponse du serveur d'application bancaire.
Le module « convertisseur » du serveur d'intégration ou le module « d'adaptation client » du serveur client peuvent en fonction du langage utilisé et des formats à convertir s'appuyer sur des produits du marché des outils de développement de progiciel informatique pour faciliter leur travail.
Par exemple, la conversion XML vers fichiers à plat et vice versa peut être mise en place en s'appuyant sur un parseur XSLT « Xalan » de l'organisme Open Source « Apache ». Autre cas de figure : la conversion d'un format XML vers un autre format XML, ou vers des tables de base de données, peut être mise en place par un convertisseur qui s'appuie sur le produit « Liquid Data », vendu par société « BEA ».
D'une manière générale, l'exécution des appels de service est du type synchrone ou asynchrone. Les connecteurs entrants 20 et/ou sortants 24 sont synchrones ou asynchrones.
En référence à la figure 5, une liste répertorie les différents format et langage susceptibles d'être convertis par les chaînes de conversion selon l'invention. Chaque connecteur du serveur MCMA 7, qu'il soit entrant ou sortant, est associé à un protocole qui peut appartenir au groupe formé par les protocoles IP, HTTP, CORBA/IIOP, JRMP, DCOM, COM, COM+, SOAP ou analogues.
A chaque connecteur peuvent être associé des branchements client ou serveur d'intégration, dédié au protocole du connecteur et écris dans l'un des langages appartenant au groupe formé par Java, C++, Visual Basic, COBOL, PHP, PERL ou analogues.
De façon préférentielle, le choix du connecteur associé à un serveur d'application ce fait par paramétrage du serveur MCMA 7. Ce paramétrage indique les informations tels que le connecteur sortant utilisé et les données nécessaires pour que celui-ci établisse une connexion au serveur d'intégration. Par exemple, un connecteur sortant IP disposera de paramètres de connexions IP tels que l'adresse IP et le port du serveur d'intégration et le délai à partir duquel il considère que le serveur d'intégration ne répondra plus (time out). Exemple de définition de ces paramètres dans un fichier au format
INI de Microsoft Windows (cas ou le serveur MCMA 7 serais écris par exemple en Visual Basic) :
[TCPIPJDUT] Host26=192.5.60.183 Port26=6868 TimeOut26=5
Les chaînes de conversion logicielles selon l'invention permettent de réduire les coûts d'intégration et d'exploitation du serveur MCMA 7 avec les serveurs clients et les serveurs d'applications en : - structurant les modalités d'intégration d'un serveur client quelconque avec le serveur MCMA 7 (XML représentant une action formant appel de service fournis par le serveur MCMA 7, branchement client, connecteur entrant) ;
- structurant les modalités d'intégration du serveur MCMA 7 avec un serveur d'application quelconque (XML représentant une action formant appel de service attendu par le serveur MCMA 7, connecteur sortant, branchement serveur d'intégration, serveur d'intégration) ;
- mutualisant les couches de communications coté serveur MCMA 7 (réutilisation des connecteurs entrant pour tous les serveurs clients, réutilisation des connecteurs sortant pour tous les serveurs d'applications) ;
- préparant les travaux d'adaptation des serveurs clients (les branchements clients sont déjà fournis par l'équipe de développement du serveur MCMA 7, ils sont testés pour le langage utilisé par le serveur client le protocole et le connecteur entrant choisi) ;
préparant le développement du serveur d'intégration (le branchement serveur d'intégration fournis la souche de départ du serveur d'intégration.
En pratique, il est préférable que les branchements client 22 et les branchements serveur d'intégration d'application 26 soit développés par la même équipe informatique que celle chargée du développement des connecteurs du serveur MCMA 7. Si en fonction du langage avec lequel est écris le serveur client ou le serveur d'intégration, le branchement client n'existe pas, c'est cette équipe qui est la mieux placée pour réalisée ce nouveau module (enrichissement du « kit d'intégration » du connecteur correspondant et donc enrichissement du serveur MCMA 7). Pour les mêmes raisons, si en fonction du protocole choisi le connecteur entrant ou sortant n'existe pas, c'est l'équipe chargée du développement du serveur MCMA 7 qui doit développer le connecteur manquant ainsi que le premier branchement correspondant pour le tester (enrichissement du kit d'intégration du serveur MCMA 7).
L' équipe informatique chargée du développement des connecteurs entrants, des connecteurs sortant, des branchements clients et des branchements serveur, mettra avantageusement en place des fonctionnalités de trace (création de fichier de log) lors des émissions/ réception de messages pour faciliter l'identification du composant responsable de dysfonctionnement en cas de panne ou l'identification du composant « goulet d'étranglement » en cas de problèmes de performances.
Ainsi les développements spécifiques (réalisés par une équipe de projet d'intégration) nécessaires à l'intégration d'un serveur client ou d'un serveur d'application avec le serveur MCMA 7 sont réduits au minimum :
- pour l'intégration d'un nouveau serveur client : développement du module d'adaptation client et développement du code « glue » entre ces deux modules et le troisième module fonctionnel ;
pour l'intégration d'un nouveau serveur d'application : développement du module convertisseur, développement du module de branchement serveur d'application et développement du code « glue » entre ces trois modules.
Ces développements spécifiques sont également fiabilisés par la réutilisation de connecteurs et de branchements existant déjà éprouvés.
Bien évidemment, les modes de réalisation illustrés n'ont été donnés qu'à titre d'exemples et ne sont absolument pas limitatifs de l'ensemble des solutions pouvant être mises en œuvre grâce à la présente invention.

Claims

REVENDICATIONS
[1] Procédé permettant de faire communiquer à l'intérieur d'un système informatique (1) de type distribué, une pluralité de serveurs client (4) possédant chacun des moyens logiciels et matériels spécifiques avec une pluralité de serveurs d'application (5) possédant chacun des moyens logiciels et matériels spécifiques et comprenant chacun au moins une application choisie (6), les serveurs client (4) étant directement connectés à un unique serveur MCMA lequel est à son tour directement connecté à l'ensemble des serveurs d'application (5), de sorte que tout appel de service d'un serveur client à destination d'un serveur d'application donné, est d'abord adressé par ledit serveur client au serveur MCMA à charge pour ce dernier de le router au serveur d'application concerné et de faire remonter en retour d'éventuelles informations du serveur d'application vers le serveur client, chaque appel de service entre un serveur client (4) et le serveur MCMA (7) coopère avec une chaîne de conversion des langages et des formats, caractérisé en ce que lorsque que le serveur MCMA (7) utilise le langage XML et le serveur client (4- 6) le langage HTML, alors la chaîne de conversion entrante associée comprend un module d'adaptation intégré au serveur client (4-6) utilisant un programme écrit en langage Java destiné à convertir automatiquement les formulaires HTML faisant appel de service en un document XML compréhensible de serveur MCMA (7) et inversement.
[2] Procédé selon la revendication 1, caractérisé en ce que ledit programme réutilise les noms des paramètres de la balise HTML "input name" comme noms de balises XML ouvrantes et fermantes, tandis que les valeurs des paramètres d'entrée HTML sont converties en valeurs des balises XML.
[3] Procédé selon la revendication 1, caractérisé en ce que lesdits formulaires HTML traités par ledit programme comprennent des paramètres cachés contenant des instructions commandant le déroulement dudit programme.
[4] Procédé selon la revendication 1, caractérisé en ce que lesdits formulaires HTML traités par ledit programme comprennent des paramètres cachés contenant des informations telles que le type d'appel de service ou encore des classes d'usage définissant des balises XML.
[5] Procédé selon la revendication 1, caractérisé en ce que lesdits formulaires HTML traités par ledit programme comprennent des paramètres cachés contenant des informations telles que les fichiers XSL nécessaires à la conversion de la réponse XML du serveur MCMA (7) en document HTML.
[6] Procédé selon la revendication 1, caractérisé en ce que ledit programme transfère l'appel de service au serveur MCMA (7) après l'avoir converti au format XML en passant par un module de branchement client (22) intégré au serveur client (4-6) apte à communiquer avec un connecteur entrant (20) associé intégré au serveur MCMA (7).
[7] Procédé selon la revendication 1, caractérisé en ce que lesdits serveurs client (4) présentent les appels de service sous la forme d'action, ces actions étant des classes en langage de programmation orientée objet qui possèdent une structure de données et une méthode apte à encapsuler l'appel à destination d'un ou plusieurs serveurs d'application cibles (5) et/ou à prévoir d'éventuels traitements assurés par le serveur MCMA (7).
[8] Procédé selon la revendication 1, caractérisé en ce que chaque action formant appel de service est transférée entre serveurs sous la forme d'un document textuel structuré écrit en langage de balisage extensible du type XML ou analogue.
[9] Procédé selon la revendication 1, caractérisé en ce que l'action formant appel comprend un identifiant correspondant à l'identifiant du service cible, des attributs d'entrée représentant les paramètres de l'appel de service et d'éventuels attributs de sortie représentant le résultat du service destiné à être retourné audit serveur client
[10] Procédé selon la revendication 1, caractérisé en ce que lesdits serveurs d'application utilisent une couche logicielle d'intégration et que les serveurs client utilisent une couche logicielle d'usage déduite de ladite couche d'intégration et en ce que la structure de données de d'une action formant appel de service coopère avec ladite couche d'usage.
PCT/EP2003/051013 2002-12-23 2003-12-15 Procede de communication entre serveurs avec conversion de format des donnees et dispositif pour sa mise en oeuvre WO2004057825A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2003303162A AU2003303162A1 (en) 2002-12-23 2003-12-15 Method for communication between servers with data format conversion and device therefor

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0216691 2002-12-23
FR0216691 2002-12-23

Publications (2)

Publication Number Publication Date
WO2004057825A2 true WO2004057825A2 (fr) 2004-07-08
WO2004057825A3 WO2004057825A3 (fr) 2004-09-16

Family

ID=32669141

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2003/051013 WO2004057825A2 (fr) 2002-12-23 2003-12-15 Procede de communication entre serveurs avec conversion de format des donnees et dispositif pour sa mise en oeuvre

Country Status (2)

Country Link
AU (1) AU2003303162A1 (fr)
WO (1) WO2004057825A2 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009044226A1 (fr) * 2007-10-03 2009-04-09 Gmx Sas Système et procédé pour une gestion sécurisée de transactions

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106878431B (zh) * 2017-02-24 2020-06-02 北京同有飞骥科技股份有限公司 一种转化分布式系统中节点通讯消息格式的方法和装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020032783A1 (en) * 1999-12-30 2002-03-14 Tuatini Jeffrey T. Shared service funtionality invocation
US20020156812A1 (en) * 2000-09-08 2002-10-24 Krasnoiarov Boris Andreyevich Method and system for assembling concurrently-generated content
US20020184116A1 (en) * 2001-04-04 2002-12-05 Iuniverse.Com Data structure for holding product information
WO2002101510A2 (fr) * 2001-06-13 2002-12-19 Caminus Corporation Architecture de systeme et procede pour le commerce de l'industrie de l'energie et la gestion de transactions

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020032783A1 (en) * 1999-12-30 2002-03-14 Tuatini Jeffrey T. Shared service funtionality invocation
US20020156812A1 (en) * 2000-09-08 2002-10-24 Krasnoiarov Boris Andreyevich Method and system for assembling concurrently-generated content
US20020184116A1 (en) * 2001-04-04 2002-12-05 Iuniverse.Com Data structure for holding product information
WO2002101510A2 (fr) * 2001-06-13 2002-12-19 Caminus Corporation Architecture de systeme et procede pour le commerce de l'industrie de l'energie et la gestion de transactions

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009044226A1 (fr) * 2007-10-03 2009-04-09 Gmx Sas Système et procédé pour une gestion sécurisée de transactions
US8938793B2 (en) 2007-10-03 2015-01-20 Gmx Sas System and method for secure management of transactions

Also Published As

Publication number Publication date
AU2003303162A1 (en) 2004-07-14
WO2004057825A3 (fr) 2004-09-16

Similar Documents

Publication Publication Date Title
TW552537B (en) System and method for integrating public and private data
KR100368353B1 (ko) 키오스크 및 그 구성 방법과, 서버 및 그 작동 방법
US20140082004A1 (en) System for online lending services via an application service provider network
WO2000056030A1 (fr) Systeme d&#39;acces a un objet a l&#39;aide d&#39;un navigateur de type &#39;web&#39; cooperant avec une carte a puce
WO2007085589A2 (fr) Procede de creation de service, produit de programme d&#39;ordinateur et systeme informatique de mise en œuvre de ce procede
AU2001271596A1 (en) System and method for integrating public and private data
EP1193950A2 (fr) Procédé d&#39;optimisation, par un élément d&#39;architecture de réseau, de la consulation de données.
WO1999003243A1 (fr) Systeme et procede pour gerer des transactions entre des fournisseurs de services et des clients sur un reseau de communication
Botto Dictionary of e-business: a definitive guide to technology and business terms
EP1559258A2 (fr) Architecture informatique en reseau multi-etages
WO2004056071A1 (fr) Procede de communication entre serveurs avec conversion de format des donnees et dispositif pour sa mise en oeuvre
WO2004057825A2 (fr) Procede de communication entre serveurs avec conversion de format des donnees et dispositif pour sa mise en oeuvre
EP1474933A1 (fr) Services vocaux telephoniques interactifs
WO2004039039A1 (fr) Procede de communication entre serveurs et dispositif pour sa mise en oeuvre
WO2007085757A2 (fr) Procede de creation de service, produit de programme d&#39;ordinateur et systeme informatique de mise en œuvre de ce procede
Gillespie Service Providers: ASPs, ISPs, MSPs, and WSPs
Hansen et al. CISL 2002-14 May 2002
FR2844414A1 (fr) Procede de proposition d&#39;un service et procede d&#39;analyse d&#39;un document de description d&#39;un tel service.
Kumaran et al. Conversational browser
EP1370045A1 (fr) Système d&#39;accès à des données disponibles sur réseau actif
MXPA99008367A (en) Kiosk and server connected to computer network
EP1312196A2 (fr) Serveur d&#39;intermediation pour acces aux differents services disponibles a travers le reseau internet
Hanson et al. Dynamic User Interfaces for Semi-Structured Conversations.
López-Cobo et al. BUSINESS USE CASE: ONTOLOGY MANAGEMENT IN EBANKING APPLICATIONS
FR2835636A1 (fr) Systeme permettant d&#39;effectuer des echanges d&#39;information et des transactions

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

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: A2

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
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP