WO2009013440A1 - Procede d'echange de messages entre serveur de donnees de session et des services clients - Google Patents

Procede d'echange de messages entre serveur de donnees de session et des services clients Download PDF

Info

Publication number
WO2009013440A1
WO2009013440A1 PCT/FR2008/051355 FR2008051355W WO2009013440A1 WO 2009013440 A1 WO2009013440 A1 WO 2009013440A1 FR 2008051355 W FR2008051355 W FR 2008051355W WO 2009013440 A1 WO2009013440 A1 WO 2009013440A1
Authority
WO
WIPO (PCT)
Prior art keywords
message
session
specific
service
session data
Prior art date
Application number
PCT/FR2008/051355
Other languages
English (en)
Inventor
Philippe Dussaume
Maxime Bollengier
Original Assignee
France Telecom
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 France Telecom filed Critical France Telecom
Publication of WO2009013440A1 publication Critical patent/WO2009013440A1/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/14—Session management
    • 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/14—Session management
    • H04L67/146—Markers for unambiguous identification of a particular session, e.g. session cookie or URL-encoding
    • 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/28—Timers or timing mechanisms used in protocols

Definitions

  • Part 5 includes interconnections between at least two communication devices, a session including constitution information describing the session and session data.
  • Session of use differs from a communication session in that it incorporates a notion
  • a communication session is linked to the establishment of a communication between a user and a device to which he is connected.
  • a communication session is closed when the user disconnects from the device.
  • a usage session contains persistent data that remains after the communication session has expired. So a session
  • the user can contain several communication sessions, several user identifiers, several service data.
  • the use sessions are for example implemented within the framework of extensions of the telephony / computer coupling in communication networks.
  • the invention relates to the structuring of exchanges with a
  • the present invention relates more particularly to the field of data transmissions in telecommunication systems, in particular application data, and particularly relates to the distinction of data within the system.
  • a telecommunication system implementing a session data exchange method includes a main communication network, such as a switched telephone network, capable of connecting a terminal made available to a user. a user with at least a first means of communication implemented by a first client, said upstream client,
  • This first means of communication may for example be a home voice server capable of receiving from the user a request, for example verbal, and to guide this request, and therefore the current communication, to a second means of communication implemented by another client located within a second communication network, said downstream client, which has been identified by the upstream client as providing a service able to satisfy the request made by the user.
  • customer should be understood here and in the remainder of the narrative to mean an entity that directly or indirectly solicits the resources of another entity to perform a task, a client that can be embodied by an autonomous server, a group of servers, a platform of services or by various elements distributed within various means of communication included in the system.
  • a transmission of data between the communication means of a communication system, such as those implemented by the applicant, generally induces an identification of these data to ensure that they are transmitted in accordance with the execution of applications. linked to actions initiated by a user or by a system element.
  • the identification of these data is implemented by the implementation of communication sessions, which are used throughout the interactions between a user of a service and the communication means used in the execution of this service.
  • the session mechanism makes it possible, particularly in the implementation of "n-third" information systems, to store information in order to allow continuity of service. Such a session is therefore likely to contain a large amount of data. More generally, a session has constitution information and data specific to it. This session data is routed between the different service platforms.
  • a service platform is an entity of the communication network in charge of providing application services to a customer who requests it. So, a service platform can implement several application services that will each render one or more services.
  • the usage session data (application data and descriptions) are for example routed from one service platform to another via the session data server using a so-called “token” mechanism (also called network correlator). ).
  • the application token and the network correlator (for service applications, conveyed in the network signaling) are thus correlating information making it possible to maintain a link between the calls and the service applications.
  • the solution proposed by the invention does not have these disadvantages of the prior art. It concerns a method of data transmission.
  • such a method comprises: a step of receiving a message sent by an issuing entity, said message comprising: a typology identifier, designating a predefined type; correlative information, having a limited duration of existence; a step of selective use of at least one device specific to said type and adapted to be used to process said at least one message during said duration of existence of said correlating information.
  • the invention makes it possible to reserve a specific and accelerated treatment for this type of message which does not disturb not the application processing of the service provider.
  • This specific processing can be achieved through an activation of a device specific to a type to which the message complies and able to support the message.
  • the duration of existence of the correlating information makes it possible to process the message in the given time. Such information thus makes it possible at the same time to balance the burden of the entity that processes the message while structuring the exchanges.
  • a specific device may be allocated, in some embodiments, maximum loads not to exceed for its processing and adapt the support of the messages according to this constraint.
  • said method comprises, after said step of using a second step of sending a response to said message to said transmitting entity, through said specific device.
  • the method according to the invention makes it possible to reply to the message sent in a detailed manner, as long as the network correlator (or the token) is still alive, that is to say, as long as the time allocated to answer the first message is not exceeded.
  • the invention thus makes it possible to greatly reduce the waiting times and the processing loads associated with the transmitted messages while rationalizing the management thereof.
  • said message typology comprises types of messages belonging to the group comprising at least: service messages; - notifications; some orders ; queries.
  • the invention makes it possible to sort the messages according to their type and to separate the treatments from them. For example, when receiving a message of "service message” type, the entity receiving this message by the dedicated device can take steps for the "fast" processing of this message. For example, if the entity receiving this service message is a service provider, that service provider is not required to implement an application service to respond to this message. In other words, thanks to the invention, it is not necessary for a service platform to implement heavy application modules and consumers of resources to respond to simple service messages. Thus, the answer can be realized in very short times, which do not require the use of several tokens. Consequently, the invention makes it possible to perform faster processing of message types falling within the competence of specific devices that implement less greedy means in terms of memory and the use of computing power. Indeed, the use of specific fast devices to respond to simple messages makes it possible to reduce the number of instances of the application modules at a given instant and thus to allocate to each instance a larger amount of memory and a CPU time. " longer.
  • said method comprises, prior to said receiving step, a step of obtaining correlating information suitable for use within said message.
  • the invention makes it possible to sequence the processing of the messages according to an order of obtaining network correlators.
  • the scheduling of the messages is thus carried out by means of the network correlants which act as means of regulation of the processes within the communication network and provide coherence of treatment and instantiation of specific modules within the different entities of the network. so that it is possible to dynamically distribute processing loads across the network.
  • the invention offers the possibility of varying the life of the application token depending on the customer or the type of customer or the closed group of customers concerned.
  • customers could on a global basis, partial or individual, be granted thus a greater or lesser degree of freedom and / or priority in the use of tokens.
  • said specific device is in the form of at least one specific client software module for each type of message belonging to said typology.
  • the invention allows for increased performance. Indeed, the reception and the processing of the messages depend on the software module used. Thus, for example, if the message is only intended to obtain a notification of the presence or absence of a service provider to which it is addressed, the invention makes it possible to reserve specific and accelerated processing for this type of message. This specific processing is carried out by means of an activation of a software module specific to the type to which the message conforms.
  • a method of data transmission characterized in that said at least one software module comprises a data exchange capability with at least one application module capable of rendering an application service required by said message.
  • the method according to the invention enables specific software modules to communicate information they have retrieved through the messages and to deliver them to the application processes (application software modules which request them.
  • Specific software when associated with a specific interface, has the advantage in the context of a embodiment of the invention, to allow external management of inputs / outputs and communications over the network to preserve the application (the software that makes the service) management of such procedures.
  • the overall coherence of the system is strengthened while allowing a drastic reduction in development costs.
  • said specific device is in the specific interface form for each type of message belonging to said typology.
  • An interface can be defined as a zone, which makes it possible to join two elements.
  • an interface designates what each component needs to know about the other to interact with it.
  • the use of a specific interface for exchanging messages according to the typology thus makes it possible to structure the exchanges.
  • said specific device is in the form of a client software module combined with a specific interface.
  • said specific interface is a specific IP address for each type of message belonging to said typology.
  • the invention makes it possible to solve at the same time the problems related to the processing loads and the memory charges, by expressly allocating a type of message to a specific IP address.
  • the invention makes it possible to associate, for example with a given component, an IP address and to broadcast this information. All that another component may need to know about it is its IP address.
  • said specific interface is in the form of a specific port of an IP address.
  • the invention makes it possible to solve at the same time the problems related to the processing loads and the memory charges, by expressly allocating a port specific from the same IP address to a message type.
  • This embodiment also has the advantage of not requiring multiple addresses for the same entity of the network.
  • an address, and in particular IP addresses comprises two parts: an identifier of the entity (computer) connected to the network and a port, making it possible to distinguish the sources of the data.
  • the invention also relates to a device for transmitting data.
  • a device for transmitting data comprises: means for receiving a message sent by an issuing entity, said message comprising: a typology identifier, designating a predefined type; correlative information, having a limited duration of existence; means for selectively using at least one device specific to said type and able to be used to process said at least one message during said duration of existence of said correlating information.
  • a device may be in the form of a session data management entity.
  • such a device can be in the form of a service platform.
  • the invention also relates to a computer program product downloadable from a communication network and / or stored on a computer-readable medium and / or executable by a microprocessor, and comprising program code instructions for the computer. execution of the data transmission method as described above.
  • FIG. 1 is a block diagram describing the principle of the data transmission method according to the invention
  • FIG. 2 is a block diagram showing the session transfer principle according to the prior art
  • FIG. 3 presents a sequence diagram showing the principle of session transfer using a session data server
  • FIG. 4 describes a simplified architecture of a session data management server according to the invention
  • Fig. 5 is a sequence diagram showing the principle of session transfer using a session data server and a specific device according to one embodiment of the invention.
  • the invention proposes a method for managing the messages exchanged between entities of a communication network comprising session data management platforms and application platforms. It is recalled for any useful purpose that such a network implemented by the Applicant may in particular be intended to interface with a conventional switched telephone network, allowing for example a user to access voice services. It is also recalled that this type of network can be used to render both voice services in connection with a switched telephone network and that the same application platforms can, in particular thanks to the method of the invention, be used to provide services for type "video" or web services, without the need to develop specific service platforms.
  • the method according to the invention also makes it possible to envisage the optimized use of several media channels in parallel (voice / web, voice / video, video / web, video / voice / web) to render the same service to the user.
  • the invention therefore proposes a method of specific management of the messages exchanged between the application entities of the network.
  • a network includes a user session data management entity related to one or more services to be rendered to a client who requests it and that this entity of Session data management includes means for staged transmission of application data of a session.
  • Such a session data management entity makes it possible to manage the usage sessions as part of the implementation of services rendered to a client by a service provider entity (such as a server), when for example a client intervenes from a first communication network of the type Switched Telephone Network (RTC) and that the services are implemented within a second communication network, for example of the Internet type.
  • a service provider entity such as a server
  • RTC Switched Telephone Network
  • a usage session can be defined as a chain of successive activations of different communication means, such as for example a terminal made available to a user or servers implemented by clients of a system. Communication.
  • the proposed solution is based on the implementation, within a session data management entity and the client entities, of the ability to receive and deliver relevant information in the form of messages classified according to at least four categories: service messages; order notifications; - requests.
  • Another advantage provided by the invention is that it allows the message exchange protocol and the content of the messages themselves to be completely uncoupled, and thus to separate the processing operations and to increase the overall performance of the system, thanks to the use of a specific treatment device.
  • the invention therefore makes it possible to reduce the processing times and to better distribute the processing load according to a typology of messages exchanged by the different application entities involved in the communication network.
  • the invention implements network correlators as designed by the inventors while staging (scheduling) the support of the messages exchanged between the entities.
  • An entity 100 receives (1000) a message 101 sent by a first entity
  • the entity 100 selectively activates (1001) a specific device 104 specific to the typology that is capable of being implemented for the message 101 during a lifetime of the network correlator 103.
  • This lifetime of the network correlant does not necessarily correspond to the lifetime of the message, which may be longer or shorter.
  • the lifetime of the correlating information (token) is rather limited to that of call establishments or network exchanges. Thus, there is talk of a "limited" lifetime since this limitation can be operated by the clients or the session data management entities.
  • the entity 100 then provides (1002) a response 105 to the message 101 to the first entity 102.
  • the response also includes the network correlator 103, which allows for example to check the validity of this response 105.
  • this session data server makes it possible, by the use of a token, to transfer application data between these same service platforms.
  • Rerouting is a service offered to network-connected service platforms wishing to transfer a call (voice, video, text) to another service platform or terminal. Unlike the abutment (technique for connecting two external correspondents of a system, well known to those skilled in the art), such a transfer of the call avoids maintaining the first service engaged communication.
  • this intelligent network type service is supported by a Service Control Point controlling a switch.
  • a New Generation Network it is supported by an application server controlling a call server.
  • the service platforms communicate with a rerouting application server using an application protocol called "rerouting", conveyed in the signaling of messages exchanged (within a channel of signaling).
  • rerouting is for example implemented within the ISDN protocol ("Digital Network Integration Service").
  • a conventional architecture of an information system such as those implemented by the applicant and in which a session data server is not used and a message structuring is not implemented.
  • downstream 201 and upstream service platforms 202 exchange data through a central platform 203 of an intelligent network.
  • the messages exchanged can be represented by three layers 2001, 2002 and 2003, corresponding to layers of the OSI model:
  • the media layer 2001 The media layer 2001;
  • the signaling layer 2002 is the signaling layer
  • the 2003 rerouting layer that is the application domain.
  • the reroutor can provide data, called “context”, which will be transmitted to the service to which is carried out the rerouting (the rerouted) via a particular command (as the command "possibilities", for a server connected in ISDN).
  • Context data
  • This transfer of information may in particular be intended to communicate to the rerouted service the circumstances of rerouting.
  • the channel dedicated to network signaling offers a capacity that may seem too limited for some service platform needs.
  • the maximum volume of the context data exchanged during a rerouting is 23 bytes.
  • a system in which a data transmission method according to the invention is implemented, comprises a session data server which transfers the data by relying on the use of tokens.
  • the session data server thus allows the exchange of data after obtaining a token.
  • Such a system also includes in parallel a platform of the Intelligent Network type supporting the function of telephone rerouting.
  • a dedicated computer network interconnects the session data server (SDS) and the service platforms (PFS) to enable the exchange of data relating to user sessions of the users of the services.
  • SDS session data server
  • PFS service platforms
  • FIG. 3 shows a sequence diagram of an exchange of messages taking place in an advanced architecture of an information system such as those implemented by the applicant and in which a data server of session is used without however structuring the messages is implemented.
  • a user 300 contacts (3000) with an upstream services platform 301, which obtains the profile of the user 300, generates usage session information (3001) and decides to use a service platform 302 for continue to provide the service requested by the user 300.
  • the upstream services platform 301 requires (3002) a network correlator from a session data server 303. The latter generates the network correlator (3003) then sends it (30030) to the upstream service platform 301.
  • the latter associates (3004) the data of the usage session it has just created with the network correlant and then sends (3005) these associated data to the data server session 303, which is responsible for storing and maintaining this data (3006).
  • the service platform 301 obtains from the network the rerouting (3007) of the call from the client 300 to the downstream service platform 302, with transmission of the network correlator.
  • the downstream service platform 302 Upon receipt of the call following rerouting, after retrieving the signaling network correlator, the downstream service platform 302 requests (3008) the session usage data from the session data server 303 indicating the network correlant to which these data is associated. The session data server then finds (3009) these data and transmits them (3010) to the service platform 302 so that it continues the interaction with the user 300. It appears, at the end of this description, service platform resources could be better utilized. In fact, these platforms must not only manage both the service to be rendered to the user but also the interactions with the network, which has the effect of adversely affecting the overall performance of the platforms. The invention makes it possible to overcome this disadvantage as shown in FIG. 5 by structuring the message exchanges between the entities of the network.
  • a user 500 contacts (5000) with an upstream services platform 501, which obtains the profile of the user 500, generates usage session information (5001) and decides to call a service platform 502 to continue providing the service requested by the user 500.
  • the upstream services platform 501 requires (5002), using a specific device 510, a network correlator from a session data server. 503. The latter identifies this request (50031) using a message typology, generates the network correlant (5003) and then sends it (50050) to the upstream service platform 501.
  • the latter identifies the typology of the response (50041) and associates, with the aid of a specific device (5004), the data of the usage session that it has just created with the network correlant and then sends (5005) these data associated with the data server of session 503, which is responsible for storing and maintaining these data (5006).
  • the service platform 501 implements a specific routing device (5071) and requests the rerouting (5007) of the call from the client 500 to the downstream service platform 502 by transmitting the network correlator. This rerouting (5007) is carried out via the session data server 503.
  • the downstream service platform 502 Upon reception of the call following the rerouting, the downstream service platform 502 identifies the type of message (50081) and request (5008), by via a specific device (50082) the session data of use to the session data server 503 indicating the network correlator to which these data are associated. The session data server then (5009) retrieves this data and transmits it (5010) to the service platform 502 so that it continues the interaction with the user 500.
  • the proposed solution consists in the implementation, both on the client platforms of a Session Data Server. only on this one, if necessary, software modules in charge of writing and reading messages. Such messages have a syntax that can reproduce the tree logic of structuring session data. However, this structuring is in the business domain of this inter-service messaging. Thus, within the client platforms and the session data server, a differentiation of the treatments is allowed.
  • the support of this application messaging may be based on the use of XML / HTTP / IP or SOAP, but one could also prefer a product on the shelf, or SQL queries, and CFT could be preferred over HTTP.
  • the support network for these links can be a dedicated "intranet / extranet" accessible to operator or partner company service platforms, or even to user terminals.
  • the application protocol used for example HTTP, is a bidirectional system for exchanging messages between clients and SDS.
  • HTTP application requests are sent from clients to the SDS, and responses
  • the content of the messages can be in the format
  • the messages exchanged between clients and session data server are classified into several categories: service messages; notifications; orders ; - requests;
  • Service messages are used for the management of the application network and are handled at the level of the "low level” interfaces of the clients and SDS, while the notifications and commands and queries concern the management of the data of the services, and call upon the application of the customers and the SDS.
  • a service message is, for example, the "Hello" message, which is used by the SDS or the client to test the presence of the other.
  • An SDS message may be addressed to one or more clients and / or one or more Closed Client Groups. The message is sent only to them.
  • a session data server includes mechanisms for managing clients and closed client groups, and a mechanism for managing session rights or session data of clients and closed client groups, and rights closed customers and subgroups of customers within closed customer groups.
  • the rights associated with a session may be for example: read / write / modify the content of the session, and / or access rights thereto, and / or operations authorized on the session.
  • the session data server also includes management policy support mechanisms that are implicitly defined (by default) and / or explicitly (by the session initiator) based on session rights or other rules. These rights and rules can be described as masks (string of bits) or scripts (structured in an appropriate language).
  • the access rights to the session (or all or part of the referenced data and information) as well as the management of the access rights to the session are definable by the initiating client of the session. These rights can be defined by default by the session data server, which are then implemented if they are not defined by the initiator.
  • the initiator can also define the rights of access and / or execution and / or modification of these rights attached to the data structuring blocks.
  • the rights thus defined are assigned to sets of customers and / or closed groups of customers. At the network level, sending a message to a closed client group is actually a series of point-to-point transmissions in parallel (to each client), but at the application level it is broadcasting a message to a client group.
  • a command is for example the token release command, which is used for SDS to give to one or more recipient clients (possibly all) the order to release such or such tokens, or all their chips. This is also a diffusion at the application level.
  • the other messages are for example the requests exchanged from the client to the session data server, whose responses are only addressed to the client sending the request.
  • a message list is presented in the appendix, which is an integral part of the description.
  • each category of exchanged message is assigned a specific interface for structuring the exchanges.
  • Such an interface can therefore be dedicated to the exchange of certain categories of messages while other interfaces can be dedicated to the exchange of other categories of messages.
  • This interface serves as a specific device for processing the message. It can be, for example, in the form of an IP address (from the English "Internet Protocol" for "Protocol
  • a client software module can be used as a specific device for processing the exchanged messages.
  • a client software module allows according to the invention: to provide, on behalf of a client of the session data management entity, the support of low layers of the exchange protocols with the session data management entity (notifications, commands); - to manage on behalf of a client of the session data management entity, and in a transparent way for this client, the management and the processing of information specific to these lower layers and not interfering directly with the service application processing; providing, on behalf of a client of the session data management entity, and transparently for it, the routing of messages possibly emanating from a plurality of session data management entities; to be, for exchanges with the eventual session data management entity or entities, bearer of the identity of the client (s) in whose service he works, whether or not these customers are distinguished from the point of view of the entity session data management; mutualize where appropriate, when working for multiple clients, the shareable resources between them, such as correlating session information, or session identifiers.
  • the proposed solution consists in the implementation, on the client platforms of
  • Session Data SDS
  • MLC Client Software Module
  • An appendix which is an integral part of the content of the description, is a set of features of the client software modules.
  • Such a module includes a processing module that performs the operations of: receiving and sending messages to a session data server; upon receiving application commands and sending data from a service application.
  • the processing module has access to operating parameters, volatile information management (batteries and timers) and configuration parameters, including identifiers and addresses.
  • the client software module also has an administration and supervision module which, through a man / machine interface, makes it possible to verify its operation.
  • Such a module includes a processing module that performs the operations of: receiving and sending messages to a session data server; upon receipt of application commands and sending data from multiple service applications.
  • the processing module has access to general operating parameters as well as operating parameters specific to each application service, general volatile information management (batteries and timers) as well as 'to volatile information specific to each application service and configuration parameters, including identifiers and addresses.
  • the client software module also has an administration and supervision module which, through a man / machine interface, makes it possible to verify its operation.
  • the client software module makes it possible to define an access interface to the simplified session data server, for the services, responsible in particular for taking into account notifications (such as for example a session data server shutdown ...), service messages (type "hello").
  • the client software module may be located on a physical server separate from the service platform to which it is connected. In another embodiment of the invention, the client software module can be integrated within the same physical server as that of the service platform to which it is linked.
  • the client software module can take into account the management of data exchanged recurrently with the session data server.
  • the temporary session tokens or correlants exist in limited numbers on the networks, and the session data server is responsible for distributing them among the active clients according to many criteria, with a limited lifetime for each token, for its reusability. In order to keep the real time, it is without delay that the services need network tokens. It is therefore conceivable to entrust the client software module for example the management of the token stack allocated temporarily to a client by a session data server.
  • the client software module When multiple session data servers are accessible, whether for security reasons, load sharing or because they are operated by separate operators, the client software module provides the routing messages to and from the correct session data server.
  • the task of the service developer is simplified, and development costs reduced.
  • Multi-Client Software Module Several clients may, if necessary, use the same client software module or several instances of the same client software module (Multi-Client Software Module) to interface with one or more session data servers, for reasons of simplification. hardware or software, the multi-client software module then ensures the routing of messages to and from the right client. The task of the service developer is simplified, and development costs reduced. In addition, the possibility of outsourcing the multi-client software module
  • One or more instances on a host machine separate from the service platform (s) allows for greater flexibility of service platform architectures, especially in the context of securing and load balancing overall.
  • service platform s
  • clients use the same multi-client software module, or several instances of the same client software module (static or dynamic loading) to interface with one or more session data server, it is possible locally to implement These clients share certain resources distributed by the session data servers between their respective clients, such as network tokens.
  • a scarce resource therefore becomes more readily available for each individual session data server client, and the service platform operator is better able to dynamically allocate that resource to those clients that it deems to be a priority. at a given moment.
  • the efficiency of the system is increased.
  • Such a classification makes it possible, in a particular embodiment, to define an architecture of a service platform that comprises, for example, a set of four client software modules (corresponding to the four types of messages of the typology), each using a specific interface consisting of an IP address and a specific port of this address. These four interfaces are used by the session data server to address the service platform according to the degree of exchange required between the session data server and the application service or services available on the platform.
  • a simplified architecture of a session data server according to the invention is presented. It comprises a memory 41, and a processing unit 40 equipped with a microprocessor, which is controlled by a computer program (or application) 42.
  • the processing unit 40 receives as input, via an interface module. network entry 43, responses and notifications 44.
  • This information is processed by the microprocessor, according to the instructions of the program 42, to: issue service messages 46a; issue 46b requests;
  • Typical functions of the application programming interface of a session data server include:
  • Queries (client to session data server): session creation, - logout, session ID retrieval, data addition, data description retrieval, data retrieval, - data modification, data deletion , recovery of rights, modification of rights, recovery of tokens, - token validity test, association of a token with a session, release of tokens, release of all tokens.
  • the typical API functions of a Client Software Module or a Multi-Client Software Module acting as a Client of a Session Data Server on behalf of one or more service applications can the following: - Queries (client to client software module): session creation, logout, session ID retrieval, data addition, - data description retrieval, data retrieval, data modification, deletion , rights recovery, - rights modification, token recovery, association of a token with a session, release of tokens, release of all tokens.
  • Service messages - session data server shutdown (client-to-client software module), session data server restart (client-to-client software module), client shutdown or restart (client to client software module).
  • - Notifications client-to-client software module: logoff, token expiration, expiration of all tokens.
  • the simplification of the exchanges between service applications and session data server provided by the Client Software Module or the multi-client software module can thus reside mainly in handling the management of the service messages as well as requests relating to the management of the service messages. stacks of tokens, on behalf of the service application:
  • Queries (Client to Client Software Module): Chip validity test.
  • the client software module and the multi-client software module manage, for example, the following information and data: Configuration data: identifiers of the client (s) managed by the software module client or the multi-client software module, - addresses of the service application or services served, addresses or session data server usable. Operation parameters: token timers duration, session timers duration, - session data server activity timers, duration of client activity timers minimum size of the token stack assignable to one or more application service served or globally to all service applications. maximum size of the token stack assignable to any particular service application served or globally to all service applications.
  • the maximum number of tokens that can be allocated to each client by the session data server The maximum number of tokens that can be allocated to each client by the session data server. Volatile information: value of the timers of the tokens assignable to the service applications served, value of the timers of the current sessions of the service application services served, content of each managed token stack, state (activity) of each service application served, - status (activity) of each session data server used or usable. sessions in which each application served. tokens in use by each application (AS) served. state (activity) of each session data server used or usable.
  • the client software module and the multi-client software module proceed, for example, to the following processes, on reception of signals or change of state: ping message received from the session data server:
  • Session message timeout received from the session data server :
  • Token expiration message received from the session data server Removes affected tokens from stacks If tokens are already allocated to ASs, informs them. Message expires all tokens received from the session data server: - Removes all tokens from the stacks
  • Token Token Release Request received from an AS - Rejects the tokens into the chip stack assigned to this AS.
  • Informs the relevant session data servers by specifying the client identifiers and stores the information.
  • the client software modules and the multi-client software module can transfer messages from the ASs to the session data servers and session data servers to the ASs, by updating the status indicators and timers.

Landscapes

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

Abstract

L'invention concerne un procédé de transmission de données. Selon l'invention, un tel procédé comprend : une étape de réception d'un message (101) émis par une entité émettrice (102), ledit message comprenant : un identifiant de typologie, désignant un type prédéfini; - une information corrélante (103), ayant une durée d'existence limitée; une étape d'utilisation- sélective d'au moins un dispositif spécifique (104) audit type et apte à être utilisée pour traiter ledit au moins un message pendant ladite durée d'existence de ladite information corrélante.

Description

PROCEDE D ' ECHANGE DE MESSAGES ENTRE UN SERVEUR DE DONNEES DE SESSION ET DES SERVICES CLIENTS
La présente invention se rapporte au domaine de la gestion de communication et plus particulièrement de session dans un serveur de session
5 partie prenante des interconnexions entre au moins deux dispositifs de communication, une session comprenant d'une part des informations de constitution décrivant la session et des données de session.
Par session, on entend, « Session d'usage ». Une session d'usage se différencie d'une session de communication par le fait qu'elle intègre une notion
10 de service. Pour sa part une session de communication est liée à l'établissement d'une communication entre un utilisateur et un dispositif auquel il est connecté. Ainsi, une session de communication est fermée quand l'utilisateur se déconnecte du dispositif. Au contraire, une session d'usage contient des données persistantes, qui subsistent après que la session de communication ait expiré. Ainsi une session
15 d'usage peut contenir plusieurs sessions de communication, plusieurs identifiants d'utilisateurs, plusieurs données de services.
Les sessions d'usage sont par exemple mises en œuvre dans le cadre d'extensions du couplage téléphonie/informatique dans des réseaux de communication. L'invention concerne la structuration des échanges avec un
20 serveur de session.
La présente invention se rapporte plus particulièrement au domaine des transmissions de données dans des systèmes de télécommunication, en particulier des données applicatives, et porte notamment sur la distinction de données au sein du système.
25 Dans l'état actuel de la technique, un système de télécommunication mettant en œuvre un procédé d'échange de données de session inclut un réseau de communication principal, tel un réseau téléphonique commuté, apte à mettre en relation un terminal mis à disposition d'un utilisateur avec au moins un premier moyen de communication mis en oeuvre par un premier client, dit client amont,
30 identifié par exemple comme premier destinataire d'une communication qu'aura initiée l'utilisateur, par exemple en composant un code prédéterminé sur un clavier alphanumérique dont est muni son terminal. Ce premier moyen de communication pourra par exemple être un serveur vocal d'accueil apte à recevoir de la part de l'utilisateur une requête, par exemple verbale, et à orienter cette requête, et donc la communication en cours, vers un deuxième moyen de communication mis en oeuvre par un autre client situé au sein d'un second réseau de communication, dit client aval, lequel aura été identifié par le client amont comme fournissant un service apte à satisfaire la requête formulée par l'utilisateur. Le terme "client" doit être compris ici et dans la suite de l'exposé comme désignant une entité qui sollicite directement ou indirectement les ressources d'une autre entité pour exécuter une tâche, un client pouvant être matérialisé par un serveur autonome, par un groupe de serveurs, une plateforme de services ou par divers éléments répartis au sein de divers moyens de communication inclus dans le système. Une transmission de données entre les moyens de communication d'un système de communication, tels ceux mis en œuvre par la demanderesse, induit généralement une identification de ces données afin de s'assurer qu'elles sont transmises conformément à l'exécution d'applications liées à des actions initiées par un utilisateur ou par un élément du système. L'identification de ces données est mise en œuvre par l'implémentation de sessions de communication, lesquelles sont utilisées tout au long des interactions entre un utilisateur d'un service et les moyens de communication utilisés dans l'exécution de ce service. Le mécanisme de session, bien connu de l'homme du métier, permet, notamment dans la mise en œuvre de systèmes d'information « n-tiers », de conserver des informations afin de permettre une continuité de service. Une telle session est donc susceptible de contenir un important volume de données. Plus généralement, une session possède des informations de constitution et des données qui lui sont propres. Ces données de session sont routées entre les différentes plateformes de services. Une plateforme de service est une entité du réseau de communication en charge de la fourniture de services applicatifs à un client qui en fait la demande. Ainsi, une plateforme de services peut mettre en œuvre plusieurs services applicatifs qui vont chacun rendre un ou plusieurs services.
Des techniques communément employées de l'art antérieur appliquées à ces données de session d'usage permettent de réaliser un échange applicatif de données en deux étapes. En effet, les données applicatives des sessions d'usage contiennent de nombreux paramètres et de nombreuses informations de sorte que l'échange des données d'une session d'usage entre un serveur de données de session (qui gère ces données de manière centralisée) et des plateformes de services (qui ont successivement besoin de ces données) est difficilement réalisable d'un seul tenant.
Ainsi, il a été développé un mécanisme permettant d'échanger des données par le biais d'une première phase d'interrogation, par la plateforme de service, d'un serveur de données de session qui permet à la plate forme de demander la structure de la session d'usage puis au moins une deuxième phase de transmission des données de la session en fonction des besoins de la plateforme de service. Ainsi, les échanges entre les plateformes de services et le serveur de données de session sont réduits en fonction des besoins des plateformes.
Les travaux des inventeurs ont cependant permis de découvrir que ces transferts applicatifs en deux phases ne résolvent pas tous les problèmes liés à des échanges de données trop volumineuses.
En effet, les données de session d'usage (données applicatives et descriptions) sont par exemple routées d'une plateforme de services à une autre via le serveur de données de session en utilisant un mécanisme dit de « jeton » (également appelé corrélant réseau). Le jeton applicatif et le corrélant réseau (pour les applicatifs de services, véhiculés dans la signalisation réseau) sont donc des informations corrélantes permettant de maintenir un lien entre les appels et les applicatifs de services.
Un mécanisme semblable est déjà mis en œuvre au sein de protocoles réseaux (« anneau à jeton » de l'anglais « token ring ») et fonctionne sur les couches Physique et Liaison du modèle OSI. Ce mécanisme a ingénieusement fait l'objet d'une transposition au niveau applicatif par les inventeurs et a permis d'obtenir un mécanisme de routage des données par le biais d'un corrélant réseau applicatif. Or un tel corrélant réseau ne permet de transporter qu'une quantité limitée de données avant de devenir caduque (en effet, un tel corrélant réseau à une durée de vie limitée, au delà de laquelle il ne peut plus être utilisé).
De plus, en l'état actuel, la structuration des échanges en deux phases (structure puis données) combinée à un échange sous la forme de jeton entraîne une complexité importante, tant au niveau des plateformes de service que du serveur de données de sessions.
En effet, du point de vue des plateformes de services, la gestion des données de session pèse inutilement sur les performances globales de la plateforme et entraîne des retards de mise en œuvre des services en tant que tels. Effectivement les missions dédiées aux plateformes de services sont bien d'exécuter des services en tant que tels et non de gérer la pertinence de données en provenance d'un serveur central et d'en déduire le traitement à effectuer.
La solution proposée par l'invention ne présente pas ces inconvénients de l'art antérieur. Elle concerne en effet un procédé de transmission de données.
Selon l'invention un tel procédé comprend : - une étape de réception d'un message émis par une entité émettrice, ledit message comprenant : un identifiant de typologie, désignant un type prédéfini ; une information corrélante, ayant une durée d'existence limitée ; une étape d'utilisation sélective d'au moins un dispositif spécifique audit type et apte à être utilisée pour traiter ledit au moins un message pendant ladite durée d'existence de ladite information corrélante. Ainsi, dans le cadre d'un réseau de communication qui comprend un serveur de données de session et des plateformes de services, l'invention permet de résoudre les problèmes de performance qui engendrent une insatisfaction des utilisateurs. En effet, la réception d'un message n'est plus réalisée par le dispositif de communication de manière uniforme, à savoir indifférenciée. Au contraire, cette réception dépend de circonstances liées au contenu du message lui-même. Ainsi, par exemple, si le message vise uniquement à obtenir une notification de présence ou d'absence d'un fournisseur de service auquel il est adressé, l'invention permet de réserver un traitement spécifique et accéléré à ce type de message qui ne perturbe pas les traitements applicatifs du fournisseur de service. Ce traitement spécifique peut être réalisé par l'intermédiaire d'une activation d'un dispositif propre à un type auquel le message se conforme et apte à prendre en charge le message. De plus, la durée d'existence de l'information corrélante permet de traiter le message dans le temps imparti. Une telle information permet donc tout à la fois d'équilibrer la charge de l'entité qui traite le message tout en structurant les échanges. Par exemple, un dispositif spécifique peut se voir allouer, dans certains modes de réalisation des charges maximum à ne pas dépasser pour ses traitements et adapter la prise en charge des messages en fonction de cette contrainte. La durée de vie de l'information corrélante (jeton) n'est pas liée à celle du message échangé mais plutôt à celle des établissements d'appels ou des échanges réseaux. Ainsi, on parle d'une durée de vie "limitée" dans la mesure ou cette limitation peut être opérée par les clients ou l'entité de gestion de données de session. Selon un mode de réalisation particulier de l'invention, le dit procédé comprend, postérieurement à ladite étape d'utilisation une deuxième étape d'émission d'une réponse audit message à destination de ladite entité émettrice, par le biais dudit dispositif spécifique.
Ainsi, le procédé selon l'invention permet de répondre au message émis de façon circonstanciée, tant que le corrélant réseau (ou le jeton) est encore en vie, c'est-à-dire, tant que le temps alloué pour répondre au premier message n'est pas dépassé. L'invention permet donc de réduire fortement les temps d'attente et les charges de traitement associées aux messages transmis tout en rationalisant la gestion de ceux-ci. Selon une caractéristique particulière de l'invention, ladite typologie de message comprend des types de messages appartenant au groupe comprenant au moins : des messages de service ; - des notifications ; des commandes ; des requêtes.
Ainsi, l'invention permet de trier les messages en fonction de leur type et de séparer les traitements de ceux-ci. Par exemple, lors de la réception d'un message de type « message de service », l'entité qui reçoit ce message par le dispositif dédié peut prendre des mesures pour le traitement «rapide » de ce message. Par exemple, si l'entité qui reçoit ce message de service est un fournisseur de services, ce fournisseur de services n'est pas obligé de mettre en œuvre un service applicatif pour répondre à ce message. En d'autres termes, grâce à l'invention, il n'est pas nécessaire, pour une plateforme de service de mettre en œuvre des modules applicatifs lourds et consommateurs de ressources pour répondre à des messages de services simples. Ainsi, la réponse peut être réalisée dans des temps très courts, qui ne nécessitent pas l'utilisation de plusieurs jetons. En conséquence, l'invention permet de réaliser des traitements plus rapides des types de message relevant de la compétence de dispositifs spécifiques qui mettent en œuvre des moyens moins gourmands en terme de mémoire et d'utilisation de puissance de calcul. En effet, l'utilisation de dispositifs spécifiques rapides pour répondre à des messages simples permet de diminuer le nombre d'instances des modules applicatifs à un instant donné et donc d'allouer à chaque instance une quantité de mémoire plus importante et un temps « CPU » plus long.
Selon un mode de réalisation particulier de l'invention, ledit procédé comprend, préalablement à ladite étape de réception, une étape d'obtention d'une information corrélante apte à être utilisée au sein dudit message. Ainsi, l'invention permet de séquencer le traitement des messages suivant un ordre d'obtention de corrélants réseaux. L'ordonnancement des messages est donc réalisé par le biais des corrélants réseaux qui font office de moyens de régulation des traitements au sein même du réseau de communication et procurent une cohérence de traitement et d'instanciation de modules spécifiques au sein des différentes entités du réseau de sorte qu'il est possible de répartir dynamiquement les charges de traitement dans l'ensemble du réseau.
De plus, l'invention offre la possibilité de faire varier la durée de vie du jeton applicatif en fonction du client ou du type de client ou du groupe fermé de clients concerné. Ainsi, en cas de forte charge du système, les clients pourraient sur une base globale, partielle ou individuelle, se voir accorder ainsi un plus ou moins grand degré de liberté et/ou de priorité dans l'utilisation des jetons.
Selon une caractéristique particulière de l'invention, ledit dispositif spécifique se présente sous la forme d'au moins un module logiciel client spécifique pour chaque type de message appartenant à ladite typologie.
Ainsi, l'invention permet accroît les performances. En effet, la réception et le traitement des messages dépendent du module logiciel utilisé. Ainsi, par exemple, si le message vise uniquement à obtenir une notification de présence ou d'absence d'un fournisseur de service auquel il est adressé, l'invention permet de réserver un traitement spécifique et accéléré à ce type de message. Ce traitement spécifique est réalisé par l'intermédiaire d'une activation d'un module logiciel propre au type auquel le message se conforme.
Procédé de transmission de données, caractérisé en ce que ledit au moins un module logiciel comprend une capacité d'échange de données avec au moins un module applicatif apte à rendre un service applicatif requit par ledit message.
Ainsi, le procédé selon l'invention permet à des modules logiciels spécifiques de communiquer des informations qu'ils ont récupéré par le biais des messages et de les délivrer au processus applicatifs (modules logiciels applicatifs qui en font la demande. Ainsi, des tels modules logiciels spécifiques, lorsqu'ils sont associés à une interface spécifique, présentent l'avantage dans le cadre d'un mode de réalisation de l'invention, d'autoriser une gestion externe des entrées/sorties et des communications sur le réseau afin de préserver l'applicatif (le logiciel qui rend le service) de la gestion de telles procédures. Ainsi, la cohérence globale du système s'en trouve renforcée tout en permettant une réduction drastique des coûts de développement.
Selon un mode de réalisation particulier de l'invention, ledit dispositif spécifique se présente sous la forme interface spécifique pour chaque type de message appartenant à ladite typologie.
Une interface peut être définie comme une zone, qui permet de faire la jonction entre deux éléments. En particulier, dans le domaine de l'invention qui comprend des assemblages de composants par exemple, une interface désigne ce que chaque composant a besoin de connaître de l'autre pour interagir avec lui. L'utilisation d'une interface spécifique permettant d'échanger des messages en fonction de la typologie permet donc de structurer les échanges. Selon une caractéristique particulière de l'invention, ledit dispositif spécifique se présente sous la forme d'un module logiciel client combiné à une interface spécifique.
Selon une caractéristique particulière de l'invention, ladite interface spécifique est une adresse IP spécifique pour chaque type de message appartenant à ladite typologie.
Ainsi, l'invention permet de résoudre tout à la fois les problèmes liés aux charges de traitement et aux charges mémoires, en allouant expressément un type de message à une adresse IP spécifique. Ainsi l'invention permet d'associer, par exemple à un composant donné, une adresse IP et de diffuser cette information. Tout ce qu'un autre composant peut avoir besoin de connaître de celui-ci est son adresse IP.
Selon un mode de réalisation particulier de l'invention, ladite interface spécifique se présente sous la forme d'un port spécifique d'une adresse IP.
Ainsi, l'invention permet de résoudre tout à la fois les problèmes liés aux charges de traitement et aux charges mémoires, en allouant expressément un port spécifique d'une même adresse IP à un type de message. Ce mode de réalisation présente également l'avantage de ne pas nécessiter de multiples adresses pour une même entité du réseau. Par exemple, Une adresse, et notamment les adresses IP, comprennent deux parties :un identifiant de l'entité (ordinateur) connecté au réseau et un port, permettant de distinguer les sources des données.
Par exemple pour une adresse IP : 192.168.1.10 il y a plusieurs ports associables en fonction de l'applicatif. L'invention permet un emploi nouveau de ce mécanisme de port dans la structuration de l'échange de messages.
L'invention concerne également un dispositif de transmission de données, Selon l'invention, un tel dispositif comprend : des moyens de réception d'un message émis par une entité émettrice, ledit message comprenant : un identifiant de typologie, désignant un type prédéfini ; une information corrélante, ayant une durée d'existence limitée ; - des moyens d'utilisation sélective d'au moins un dispositif spécifique audit type et apte à être utilisée pour traiter ledit au moins un message pendant ladite durée d'existence de ladite information corrélante. Dans un mode de réalisation particulier de l'invention, un tel dispositif peut se présenter sous la forme d'une entité de gestion de données de session. Dans un autre mode de réalisation de l'invention, un tel dispositif peut se présenter sous la forme d'une plateforme de services.
Selon un autre aspect, l'invention concerne également un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, et comprenant des instructions de code de programme pour l'exécution du procédé de transmission de données tel que décrit précédemment.
D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : la figure 1 est un diagramme de blocs décrivant le principe du procédé de transmission de données selon l'invention ; la figure 2, est un diagramme de blocs présentant le principe de transfert de session selon l'art antérieur ; - la figure 3 présente un diagramme de séquence présentant le principe de transfert de session en utilisant un serveur de données de session ; la figure 4 décrit une architecture simplifiée d'un serveur de gestion de données de session selon l'invention ; la figure 5 est un diagramme de séquence présentant le principe de transfert de session en utilisant un serveur de données de session et un dispositif spécifique selon un mode de réalisation de l'invention.
L'invention propose une méthode de gestion des messages échangés entre des entités d'un réseau de communication comprenant des plateformes de gestion de données de session et des plateformes applicatives. On rappelle à toute fin utile qu'une tel réseau mis en œuvre par la demanderesse peut notamment être destiné à s'interfacer avec un réseau téléphonique commuté classique, permettant par exemple à un utilisateur d'accéder à des services vocaux. On rappelle également que ce type de réseau peut être utilisé pour rendre à la fois des services vocaux en lien avec un réseau téléphonique commuté et que les mêmes plateformes applicatives peuvent, notamment grâce au procédé de l'invention, être utilisées pour rendre des services de type « vidéo » ou encore des services web, sans qu'il soit nécessaire de procéder à des développement de plateformes de services spécifiques. De plus, le procédé selon l'invention permet également d'envisager l'utilisation optimisée de plusieurs canaux de média en parallèle (voix/web, voix/vidéo, vidéo/web, vidéo/voix/web) pour rendre un même service à l'utilisateur.
L'invention propose donc une méthode de gestion spécifique des messages échangés entre les entités applicatives du réseau. On rappelle qu'un tel réseau comprend une entité de gestion de données de session d'usage liées à un ou plusieurs services à rendre à un client qui en fait la demande et que cette entité de gestion de données de session comprend des moyens permettant une transmission étagée des données applicatives d'une session.
Une telle entité de gestion de données de session permet de gérer les sessions d'usage dans le cadre de la mise en œuvre de services rendus à un client par une entité fournisseur de services (tel qu'un serveur), lorsque par exemple, un client intervient depuis un premier réseau de communication, de type Réseau Téléphonique Commuté (RTC) et que les services sont mis en œuvre au sein d'un deuxième réseau de communication, par exemple du type Internet.
On rappelle qu'une session d'usage peut être définie comme une chaîne d'activations successives de différents moyens de communication, tels par exemple un terminal mis à disposition d'un utilisateur ou des serveurs mis en oeuvre par des clients d'un système de communication.
La solution proposée repose sur la mise en œuvre, au sein d'une entité de gestion de données de session et des entités clientes, de la capacité à recevoir et à délivrer de l'information pertinente sous la forme de messages classés selon au moins quatre catégories : des messages de service ; des notifications des commandes ; - des requêtes.
Ainsi, à la différence des techniques antérieures, il n'est plus nécessaire de prévoir de multiples échanges de données complexes et des traitements applicatifs lourds qui ralentissent le système. La solution apportée par l'invention permet donc de réaliser une structuration des échanges, portant plus particulièrement sur la distinction des messages en requêtes et réponses, messages de service, notifications et commandes.
Ainsi, grâce à l'utilisation d'un protocole applicatif « ad hoc » présentant une structuration particulière des messages orientée gestion de contexte et données de session, il devient plus facile au développeur de service d'intégrer dans l'applicatif service les fonctions de traitement des messages applicatifs pour l'utilisation souhaitée.
Un autre avantage procuré par l'invention est de permettre de découpler totalement le protocole d'échange des messages et le contenu des messages eux- mêmes, et donc d'en disjoindre les traitements et d'augmenter la performance globale du système, grâce à l'utilisation d'un dispositif spécifique de traitement.
L'invention permet donc de réduire les temps de traitement et de mieux répartir la charge de traitement en fonction d'une typologie de messages échangés par les différentes entités applicatives intervenant dans le réseau de communication. Pour ce faire, l'invention met en œuvre des corrélants réseaux tel que conçus par les inventeurs tout en étageant (ordonnançant) la prise en charge des messages échangés entre les entités.
On présente, en relation avec la figure 1, le principe général de l'invention : Une entité 100, reçoit (1000) un message 101 émis par une première entité
102. Cette réception est effectuée en fonction de la typologie préalablement définie et le message 101 contient un corrélant réseau 103.
L'entité 100 active (1001) sélectivement un dispositif spécifique 104 propre à la typologie qui est apte à être mis en œuvre pour le message 101 pendant une durée de vie du corrélant réseau 103. Cette durée de vie du corrélant réseau ne correspond pas nécessairement à la durée de vie du message, qui peut être plus longue ou plus courte. La durée de vie de l'information corrélante (jeton)est plutôt limitée à celle des établissements d'appels ou des échanges réseaux. Ainsi, on parle d'une durée de vie "limitée" dans la mesure ou cette limitation peut être opérée par les clients ou les entités de gestion de données de session.
L'entité 100 fournit ensuite (1002), une réponse 105 au message 101 à destination de la première entité 102. La réponse inclue également le corrélant réseau 103, qui permet par exemple de vérifier la validité de cette réponse 105.
Par la suite, on présente notamment le cas d'un système de gestion des données de session autorisant une structuration des échanges telle que décrites dans l'invention. Il est clair cependant que l'invention ne se limite pas à cette application particulière, mais peut également être mise en œuvre dans de nombreux autres domaines, et par exemple dans le transfert de données entre des processus applicatifs différents d'une même application ou d'un même service, ou entre les applications d'un Système d'Information invoquées dans un processus de gestion de flux d'informations, et plus généralement dans tous les cas où les avantages listés par la suite sont intéressants. Description d'un mode de réalisation On présente, dans ce mode de réalisation, une mise en œuvre du procédé de transmission de données selon l'invention au sein d'un système de communication comprenant un serveur de données de session et des plateformes de services.
Conjointement à la mise en œuvre d'un mécanisme réseau de reroutage entre plateformes de services, ce serveur de données de session permet, par l'utilisation d'un jeton, le transfert de données applicatives entre ces mêmes plateformes de services. Le reroutage est un service offert aux plateformes de services connectées au réseau et qui souhaitent transférer un appel (vocal, vidéo, textuel) vers une autre plateforme de service ou à un terminal. Au contraire de l'aboutement (technique permettant de mettre en relation deux correspondants externes d'un système, bien connue de l'homme du métier), un tel transfert de l'appel évite de maintenir le premier service en prise sur la communication.
Selon les mécanismes de l'art antérieur, sur le RTC (réseau téléphonique commuté) par exemple, ce service du type réseau intelligent est supporté par un Point de Commande de Service commandant un commutateur. Sur un réseau de nouvelle génération (« NGN » de l'anglais « New Génération Network »), il est supporté par un serveur d'application commandant un serveur d'appels.
Selon ces techniques antérieures, pour la mise en œuvre du reroutage, les plateformes de services communiquent avec un serveur applicatif de reroutage en utilisant un protocole applicatif dit "de reroutage", véhiculé dans la signalisation des messages échangés (au sein d'un canal de signalisation). Un tel reroutage est par exemple mis en œuvre au sein du protocole RNIS (« Réseau Numérique à Intégration de Service »).
On présente, en relation avec la figure 2, une architecture classique d'un système d'information tel que ceux mis en œuvre par la demanderesse et dans laquelle il n'est pas fait appel à un serveur de données de session et qu'une structuration des messages n'est pas mise en œuvre. Dans un telle architecture, des plateformes de services aval 201 et amont 202 s'échangent des données par le biais d'une plateforme centrale 203 d'un réseau intelligent. Les messages échangés peuvent être représentés par trois couches 2001, 2002 et 2003, correspondant à des couches du modèle OSI :
La couche média 2001 ;
La couche signalisation 2002 ;
La couche reroutage 2003 qui est du domaine applicatif.
Les plateformes de services, qui doivent rendre des services applicatifs aux clients qui en font la demande intègrent directement tous les éléments (2011,
2012, 2013, 2021, 2022, 2023) qui permettent de gérer à la fois les problématiques de média, de signalisation et de reroutage. Il s'en suit qu'une plateforme de service est obligé de traiter, de la même manière, un message en provenance du canal média et un message de reroutage, par exemple, alors même que ces messages ne présentent pas le même intérêt du point de vue du client notamment du point de vue de la rapidité d'exécution du service rendu.
Dans le cas d'un reroutage dit "aveugle", il n'y a pas visibilité directe entre le « rerouteur » 201, initiateur du reroutage, et le « rerouté » 202, celui vers lequel est transféré l'appel. Les échanges d'informations entre ceux-ci se font en mode « tire-et-oublie », et, dans le cadre du reroutage, uniquement dans le sens amont vers aval.
Dans sa demande de reroutage aveugle, le service initiateur du reroutage
(le rerouteur) peut fournir des données, dites "de contexte", qui seront transmises au service vers lequel est effectué le reroutage (le rerouté) via une commande particulière (comme la commande "possibilités", pour un serveur raccordé en RNIS). Ce transfert d'informations peut notamment avoir pour objet de communiquer au service rerouté les circonstances du reroutage. Cependant, pour des raisons d'optimisation, le canal dédié à la signalisation réseau offre une capacité qui peut paraître trop limitée pour certains besoins des plates-formes de services. Ainsi, sur le RTC, dans certains modes d'implémentation, le volume maximum des données de contexte échangées lors d'un reroutage est de 23 octets.
Afin de palier ce type de limitation, un système, au sein duquel on met en œuvre un procédé de transmission de données selon l'invention, comprend un serveur de données de session qui transfert les données en se reposant sur l'utilisation de jetons. Le serveur de données de session permet donc l'échange de données après l'obtention d'un jeton.
Un tel système comprend également en parallèle une plate-forme de type Réseau Intelligent supportant la fonction du reroutage téléphonique.
Un réseau informatique dédié relie entre eux le serveur de données de session (SDS), et les plates-formes de services (PFS), afin de permettre les échanges de données relatives aux sessions d'usage des utilisateurs des services.
Pour adresser ces données de sessions (stockées plus ou moins temporairement sur le SDS) et de les rattacher à des événements réseaux tels qu'ils sont vus des plateformes de services, on utilise des jetons uniques (sur une période donnée). Ces jetons sont échangés par les plateformes de services dans la signalisation lors de la mise en œuvre du reroutage. L'unicité d'un jeton sur le réseau pour une période donnée, ainsi que la génération des identifiants de sessions sont ici assurées par le serveur de données de session mais elles pourront être implémentées en dehors du serveur de données de session dans d'autres modes de réalisation.
On présente, en relation avec la figure 3, un diagramme de séquence d'un échange de messages se déroulant dans une architecture évoluée d'un système d'information tel que ceux mis en œuvre par la demanderesse et dans laquelle un serveur de données de session est utilisé sans toutefois qu'une structuration des messages soit mise en œuvre. Un utilisateur 300 entre en relation (3000) avec une plateforme de services amont 301, laquelle obtient le profil de l'utilisateur 300, génère des informations de session d'usage (3001) et décide de faire appel à une plateforme de service 302 pour poursuivre la fourniture de service demandée par l'utilisateur 300. Pour ce faire, la plateforme de services amont 301 requiert (3002) un corrélant réseau auprès d'un serveur de données de session 303. Ce dernier génère le corrélant réseau (3003) puis l'envoie (30030) à la plateforme de service amont 301. Cette dernière associe (3004) les données de la session d'usage qu'elle vient de créer avec le corrélant réseau puis envoie (3005) ces données associées au serveur de données de session 303, qui se charge de stocker et de maintenir ces données (3006). Enfin, la plateforme de service 301 obtient du réseau le reroutage (3007) de l'appel du client 300 vers la plateforme de service aval 302, avec transmission du corrélant réseau.
A réception de l'appel suite au reroutage, après extraction du corrélant réseau de la signalisation, la plateforme de service aval 302 demande (3008) les données de session d'usage au serveur de données de session 303 en indiquant le corrélant réseau auquel ces données sont associées. Le serveur de données de session retrouve (3009) alors ces données et les transmet (3010) à la plateforme de service 302 afin qu'elle poursuive l'interaction avec l'utilisateur 300. II apparaît, à l'issue de cette description, que les ressources des plateformes de services pourraient être mieux utilisées. En effet, ces plateformes doivent non seulement gérer tout à la fois le service à rendre à l'utilisateur mais également les interactions avec le réseau, ce qui a pour conséquence de nuire aux performances générales des plateformes. L'invention permet notamment de palier cet inconvénient comme le montre la figure 5 en structurant les échanges de messages entre les entités du réseau.
Un utilisateur 500 entre en relation (5000) avec une plateforme de services amont 501, laquelle obtient le profil de l'utilisateur 500, génère des informations de session d'usage (5001) et décide de faire appel à une plateforme de service 502 pour poursuivre la fourniture de service demandée par l'utilisateur 500. Pour ce faire, la plateforme de services amont 501 requiert (5002), à l'aide d'un dispositif spécifique 510 un corrélant réseau auprès d'un serveur de données de session 503. Ce dernier identifie cette requête (50031) à l'aide d'une typologie de message, génère le corrélant réseau (5003) puis l'envoie (50050) à la plateforme de service amont 501. Cette dernière identifie la typologie de la réponse (50041) et associe, à l'aide d'un dispositif spécifique (5004) les données de la session d'usage qu'elle vient de créer avec le corrélant réseau puis envoie (5005) ces données associées au serveur de données de session 503, qui se charge de stocker et de maintenir ces données (5006). Enfin, la plateforme de service 501 met en œuvre un dispositif spécifique de routage (5071) et demande le reroutage (5007) de l'appel du client 500 vers la plateforme de service aval 502 en transmettant le corrélant réseau. Ce reroutage (5007) est effectué par l'intermédiaire du serveur de données de session 503. A réception de l'appel suite au reroutage, la plateforme de service aval 502 identifie le type de message (50081) et demande (5008), par l'intermédiaire d'un dispositif spécifique (50082) les données de session d'usage au serveur de données de session 503 en indiquant le corrélant réseau auquel ces données sont associées. Le serveur de données de session retrouve (5009) alors ces données et les transmet (5010) à la plateforme de service 502 afin qu'elle poursuive l'interaction avec l'utilisateur 500.
Ainsi, selon l'invention, pour alléger et structurer l'échange d'information entre les clients et le serveur de données de sessions, on procède à un échange structuré de messages applicatifs qui permettent de mettre en œuvre des modules spécifiques apte à traiter l'information de manière plus efficiente qu'une application de service qui a été créer pour rendre un service spécifique et non pas traiter des échanges de messages. Messagerie support Dans ce mode de réalisation, la solution proposée consiste en la mise en œuvre, tant sur les plates-formes clientes d'un Serveur de Données de Sessions que sur celui-ci, le cas échéant, de modules logiciels en charge de l'écriture et de la lecture de messages. De tels messages ont une syntaxe qui peut reproduire la logique arborescente de la structuration des données de session. Or, cette structuration relève du domaine métier de cette messagerie inter-services. Ainsi, au sein des plateformes clientes et du serveur de données de session, on permet une différentiation des traitements.
Le support de cette messagerie applicative pourra être basé sur l'utilisation de XML/HTTP/IP ou de SOAP, mais on pourrait également préférer un produit sur étagère, ou des requêtes SQL, et CFT pourrait être préféré à HTTP. Le réseau support de ces liens peut être un « intranet/extranet » dédié, accessible aux plates- formes de services d'opérateurs ou d'entreprises partenaires, voire aux terminaux utilisateurs.
Le protocole applicatif utilisé, par exemple HTTP, est un système bidirectionnel d'échanges de messages entre clients et SDS. Par exemple, des requêtes applicatives HTTP sont envoyées des clients vers le SDS, et des réponses
HTTP du SDS vers les clients. Le contenu des messages peut être au format
XML.
Messages échangés
Afin de faciliter le travail de développement des éléments du système et leur modularité, les messages échangés entre clients et serveur de données de session sont classés en plusieurs catégories : messages de service ; notifications ; commandes ; - requêtes ;
Les messages de service sont utilisés pour la gestion du réseau applicatif et sont traités au seul niveau des interfaces « bas niveau » des clients et SDS, tandis que les notifications et commandes et les requêtes concernent la gestion des données des services, et font appel à l'applicatif des clients et du SDS. Un message de service est par exemple le message « Hello », qui sert au SDS ou au client à tester la présence de l'autre.
Un message du SDS peut être adressé à un ou plusieurs clients et/ou à un ou plusieurs Groupes Fermés de Clients. Le message n'est envoyé qu'à eux seuls. On rappelle qu'un serveur de données de session intègre des mécanismes de gestion des clients et des groupes fermés de clients, et un mécanisme de gestion des droits de sessions ou des données de session des clients et des groupes fermés de clients, et des droits des clients et sous-groupes fermés de clients au sein des groupes fermés de clients. Les droits associés à une session peuvent être par exemple : lecture/écriture/modification du contenu de la session, et/ou des droits d'accès à celle-ci, et/ou des opérations autorisées sur la session. Le serveur de données de session intègre également des mécanismes de prise en charge de règles de gestion définies implicitement (par défaut) et/ou explicitement (par l'initiateur de la session) en fonction des droits de la session ou d'autres règles. Ces droits et règles peuvent être décrits sous la forme de masques (chaîne de bits) ou de scripts (structurés selon un langage approprié).
Les droits d'accès à la session (ou à tout ou partie des données et informations référencées) ainsi que la gestion des droits d'accès à la session sont définissables par le client initiateur de la session. Ces droits peuvent être définis par défaut par le serveur de données de session, qui sont alors mis en œuvre s'ils ne sont pas définis par l'initiateur. L'initiateur peut également définir les droits d'accès et/ou d'exécution et/ou de modification de ces droits attachés aux blocs de structuration des données. Les droits ainsi définis sont affectés à des ensembles de clients et/ou de groupes fermés de clients. Au niveau du réseau, l'envoi d'un message à un groupe fermé de client est en fait une série d'envois de point à point en parallèle (à chaque client), mais, au niveau applicatif, il s'agit d'une diffusion d'un message à un groupe de client.
Une commande est par exemple la commande de libération de jeton, qui sert au SDS à donner à un ou plusieurs clients destinataires (éventuellement tous) l'ordre de libérer tels ou tels jetons, voire tous leurs jetons. Il s'agit là aussi d'une diffusion au niveau applicatif.
Les autres messages sont par exemple les requêtes échangées du client vers le serveur de données de session, dont les réponses ne sont adressées qu'au seul client émetteur de la requête. Une liste de message est présentée en annexe, qui fait parie intégrante de la description.
Utilisation d'une interface spécifique en tant que dispositif de structuration des échanges
Dans un mode de réalisation de l'invention, on assigne à chaque catégorie de message échangé, une interface spécifique permettant de structurer les échanges. Une telle interface peut donc être dédiée à l'échange de certaines catégories de message tandis que d'autres interfaces peuvent être dédiées à l'échange d'autres catégories de messages. Cette interface fait office de dispositif spécifique de traitement du message. Elle peut se présenter, par exemple, sous la forme d'une adresse IP (de l'anglais « Internet Protocol » pour « Protocole
Internet »). Ainsi, on peut utiliser une adresse IP spécifique à l'échange des messages de services et des notifications, une adresse IP spécifique à l'échange des commandes et une autre spécifique à l'échange des requêtes. Une telle implémentation nécessite alors qu'un serveur dispose de trois adresses IP différentes.
Dans un autre mode de réalisation, il est également possible d'allouer, pour une même adresse IP, des ports de communication différents en fonction de la catégorie du message. Ainsi, pour une même adresse IP, par exemple 192.168.2.10, le port 1024 aux messages de services, 1025 aux notifications, 1026 aux commandes et conserver le port 80 pour les requêtes HTTP (requêtes applicatives). On évite ainsi de devoir allouer plusieurs adresses IP à un même serveur.
Bien entendu, des combinaisons des deux modes de réalisation précédents peuvent également être employées. Utilisation d'un module logiciel client en tant que dispositif de structuration et d'allégement des échanges.
Dans un mode de réalisation particulier de l'invention, un module logiciel client (MLC) peut être utilisé en tant que dispositif spécifique de traitement des messages échangés.
Ainsi, un module logiciel client (MLC) permet selon l'invention : d'assurer, pour le compte d'un client de l'entité de gestion de données de session, la prise en charge de couches basses des protocoles d'échanges avec l'entité de gestion de données de session (notifications, commandes) ; - d'assurer pour le compte d'un client de l'entité de gestion de données de session, et de façon transparente pour ce client, la gestion et les traitements des informations propres à ces couches basses et n'interférant pas directement avec les traitements des applicatifs services ; d'assurer pour le compte d'un client de l'entité de gestion de données de session, et de façon transparente pour celui-ci, l'aiguillage des messages émanant éventuellement de plusieurs entités de gestion de données de session ; d'être, pour les échanges avec le ou les entités de gestion de données de session éventuelles, porteur de l'identité du ou des clients au service desquels il travaille, que ces clients soient ou non distingués du point de vue de l'entité de gestion de données de session ; de mutualiser le cas échéant, lorsqu'il travaille pour plusieurs clients, les ressources partageables entre ceux-ci, comme par exemple des informations corrélantes de session, ou des identifiants de sessions. Dans un mode de réalisation particulier de l'invention, la solution proposée consiste en la mise en œuvre, sur les plates-formes clientes d'un Serveur de
Données de Sessions (SDS), des Module Logiciels Clients (MLC) de ce serveur de données de session, situé en coupure entre les applicatifs services clients de l'entité de gestion de données de session et l'entité de gestion de données de session. Ces MLC, mutualisables et réutilisables (sous forme de code informatique avec ou sans support matériel dédié), portent sur des couches basses des plates-formes de services assurant la gestion des échanges entre les applicatifs de services de ces plates-formes et les serveurs de données de sessions.
On trouvera en annexe, qui fait partie intégrante du contenu de la description, un ensemble de fonctionnalités des modules logiciels client.
Architecture d'un module logiciel client
On présente, une architecture d'un module logiciel client. Un tel module comprend un module de traitement qui réalise les opérations propres : à la réception et à l'envoi de messages vers un serveur de données de session; à la réception de commandes applicatives et à l'envoi de données en provenance d'un applicatif de service.
Pour réaliser ses traitements, le module de traitement dispose d'un accès à des paramètres de fonctionnement, d'une gestion d'informations volatiles (piles et timers) et de paramètres de configuration, comprenant notamment des identifiants et des adresses. Le module logiciel client dispose également d'un module d'administration et de supervision, qui par le biais d'une interface homme/machine permet de vérifier son fonctionnement.
On présente, une architecture d'un module logiciel multi-client (module logiciel multi-client). Un tel module comprend un module de traitement qui réalise les opérations propres : à la réception et à l'envoi de messages vers un serveur de données de session; à la réception de commandes applicatives et à l'envoi de données en provenance des plusieurs applicatifs de service.
Pour réaliser ses traitements, le module de traitement dispose d'un accès à des paramètres de fonctionnement généraux ainsi qu'à des paramètres de fonctionnement spécifiques à chaque service applicatif, d'une gestion d'informations volatiles générales (piles et timers) ainsi qu'à des informations volatiles propres à chaque service applicatif et de paramètres de configuration, comprenant notamment des identifiants et des adresses. Le module logiciel client dispose également d'un module d'administration et de supervision, qui par le biais d'une interface homme/machine permet de vérifier son fonctionnement.
Ainsi, le module logiciel client (ou module logiciel multi-client) rend possible la définition d'une interface d'accès au serveur de données de session simplifiée, pour les services, chargée notamment d'assurer la prise en compte de notifications (comme par exemple un arrêt du serveur de données de session...), de messages de services (type « hello »).
On réduit ainsi fortement le nombre de fonction à implémenter pour la définition d'un service. La tâche du développeur de service en est simplifiée, et les coûts de développement réduits.
Dans un mode de réalisation particulier de l'invention, le module logiciel client peut être situé sur un serveur physique distinct de la plateforme de service auquel il est connecté. Dans un autre mode de réalisation de l'invention, le module logiciel client peut être intégré au sein du même serveur physique que celui de la plateforme de service auquel il est appairé.
Dans un mode de réalisation particulier de l'invention, le module logiciel client peut prendre à son compte la gestion de données échangées de façon récurrente avec le serveur de données de session. Ainsi, les jetons ou corrélants temporaires de sessions existent en nombre limité sur les réseaux, et le serveur de données de session se charge de les répartir entre les clients actifs suivant de nombreux critères, avec une durée de vie limitée pour chaque jeton, pour sa réutilisabilité. Afin de tenir le temps réel, c'est sans délai que les services ont besoins des jetons réseaux. II est donc envisageable de confier au module logiciel client par exemple la gestion de la pile de jetons allouée temporairement à un client par un serveur de données de session.
Quand plusieurs serveurs de données de session sont accessibles, que ce soit pour des raisons de sécurisation, de partage de charge ou parce qu'ils sont exploités par des opérateurs distincts, le module logiciel client assure l'aiguillage des messages de et vers le bon serveur de données de session. La tâche du développeur de service en est simplifiée, et les coûts de développement réduits.
Plusieurs client peuvent le cas échéant utiliser un même module logiciel client ou plusieurs instances d'un même module logiciel client (Module Logiciel Multi-Client) pour s'interfacer avec un ou plusieurs serveurs de données de session, que ce soit pour des raisons simplification matérielle ou logicielle, le module logiciel multi-client assure alors l'aiguillage des messages de et vers le bon client. La tâche du développeur de service en est simplifiée, et les coûts de développement réduits. De plus, la possibilité de l'externalisation du module logiciel multi-client
(une ou plusieurs instances) sur une machine hôte distincte de la ou des plates- formes de services permet une plus grande flexibilité des architectures de plates- formes de services, notamment dans l'optique d'une sécurisation et d'une répartition de charge globale. Lorsque plusieurs clients utilisent un même module logiciel multi-client, ou plusieurs instances d'un même module logiciel client (chargement statique ou dynamique) pour s'interfacer avec un ou plusieurs serveur de données de session, on peut localement procéder à la mise en commun entre ces clients de certaines ressources réparties par les serveurs de données de session entre leurs clients respectifs, comme par exemple les jetons réseaux.
Une ressource rare devient donc plus facilement disponible pour chaque client serveur de données de session individuel, et l'exploitant de plates-formes de services est plus à même d'assurer dynamiquement l'allocation de cette ressource aux clients qu'il juge prioritaires à un moment donné. L'efficacité du système est donc augmentée.
Combinaison des interfaces spécifiques et des modules logiciels clients Dans un mode de réalisation particulier de l'invention, il est envisagé d'utiliser les interfaces spécifiques précédemment décrites pour la réception et l'envoi des messages entre le module logiciel spécifique et le serveur de données de session. Ainsi, par exemple, il est possible d'attribuer une adresse IP spécifique à un module logiciel spécifique qui serait par exemple chargé de la réponse à des notifications. Il est également possible d'attribuer un port spécifique d'une adresse IP générale à un tel module logiciel. Ainsi, on augmente encore les performances du système en établissant une classification bidimensionnelle des échanges. En effet, une telle classification permet, dans un mode de réalisation particulier de définir une architecture d'une plateforme de service qui comprend par exemple un ensemble de quatre modules logiciels clients (correspondant aux quatre types de messages de la typologie), utilisant chacun une interface spécifique constituée d'une adresse IP et d'un port spécifique de cette adresse. Ces quatre interfaces sont utilisées par le serveur de données de session pour s'adresser à la plateforme de services en fonction du degré d'échange exigé entre le serveur de données de session et le ou les services applicatifs disponibles sur la plateforme.
Il est donc possible de disjoindre totalement le module logiciel client de l'applicatif de service, de sorte que l'instanciation d'un module logiciel client n'entraîne pas une baisse des performances générales de la plateforme de service.
Architecture du serveur de données de sessions
On présente, en relation avec la figure 4, une architecture simplifiée d'un serveur de données de session selon l'invention. Il comprend une mémoire 41, et une unité de traitement 40 équipée d'un microprocesseur, qui est piloté par un programme d'ordinateur (ou application) 42. L'unité de traitement 40 reçoit en entrée, via un module d'interface d'entrée réseau 43, des réponses et des notifications 44.
Ces informations sont traitées par le microprocesseur, selon les instructions du programme 42, pour : émettre des messages de service 46a ; émettre des requêtes 46b ;
Ces données sont transmises via un module d'interface de sortie réseau 45 à destination des dispositifs du réseau de communication qui en ont la charge. ANNEXES
1. Fonctions des module logiciel client et module logiciel multi-client
1.1. Échanges entre module logiciel client/module logiciel multi-client et serveur de données de session
Les fonctions type de l'interface de programmation applicative d'un serveur de données de session comprennent notamment :
Requêtes (client vers serveur de données de session) : création de session, - retrait de session, récupération de l'identifiant de session, ajout de données, récupération des descriptions des données, récupération de données, - modification de données, suppression de données, récupération de droits, modification de droits, récupération de jetons, - test de validité de jetons, association d'un jeton à une session, libération de jetons, libération de tous les jetons. Messages de service : - ping (serveur de données de session vers client), pong (client vers serveur de données de session), timeout de session (serveur de données de session vers client), maintien de session (client vers serveur de données de session), hello = test de validité de client (client vers serveur de données de session), arrêt serveur de données de session (serveur de données de session vers client), redémarrage serveur de données de session (serveur de données de session vers client), arrêt ou redémarrage client (client vers serveur de données de session).
Notifications (serveur de données de session vers client): clôture de session, expiration de jeton, expiration de tous les jetons.
1.2. Échanges entre applicatifs services et module logiciel client/module logiciel multi-client
Un exemple d'un tel protocole est décrit de façon détaillée dans les documents références, et plus particulièrement du document [3], Manuel utilisateur Serveur de Données de Session.
En résumé, les fonctions type de l'API d'un Module Logiciel Client ou d'un Module Logiciel Multi-Client faisant fonction de client d'un Serveur de Données de Session pour le compte d'un o de plusieurs applicatifs de services peuvent être les suivantes : - Requêtes (client vers module logiciel client) : création de session, retrait de session, récupération de l'identifiant de session, ajout de données, - récupération des descriptions des données, récupération de données, modification de données, suppression de données, récupération de droits, - modification de droits, récupération de jetons, association d'un jeton à une session, libération de jetons, libération de tous les jetons. Messages de service : - arrêt serveur de données de session (module logiciel client vers client), redémarrage serveur de données de session (module logiciel client vers client), arrêt ou redémarrage client (client vers module logiciel client). - Notifications (module logiciel client vers client): clôture de session, expiration de jeton, expiration de tous les jetons.
1.3. Simplification des échanges entre applicatifs services et serveur de données de session
La simplification des échanges entre applicatifs services et serveur de données de session apportée par le Module Logiciel Client ou le module logiciel multi-client peut ainsi résider principalement dans prise en main de la gestion des messages de service ainsi que des requêtes relatives à la gestion de piles de jetons, pour le compte de l'applicatif service :
Requêtes (client vers module logiciel client) : test de validité de jetons. Messages de service : - ping (serveur de données de session vers module logiciel client), pong (module logiciel client vers serveur de données de session), timeout de session (serveur de données de session vers module logiciel client), maintien de session (module logiciel client vers serveur de données de session), hello = test de validité de client (module logiciel client vers serveur de données de session).
2. Données traitées par les module logiciel client et module logiciel multi- client Les module logiciel client et module logiciel multi-client gèrent, par exemple, les informations et données suivantes : Données de configuration : identifiants du ou des clients gérés par le module logiciel client ou le module logiciel multi-client, - adresses du ou des applicatifs services servis, adresses du ou des serveurs de données de session utilisables. Paramètres de fonctionnement : durée des timers des jetons, durée des timers des sessions, - durée des timers d'activité des serveurs de données de session, durée des timers d'activité des clients taille minimum de la pile de jetons affectable à tel ou tel applicatif service servi ou globalement à tous les applicatifs services. taille maximum de la pile de jetons affectable à tel ou tel applicatif service servi ou globalement à tous les applicatifs services.
Nombre maximum de jetons allouable à chaque client par le serveur de données de session. Informations volatiles : valeur des timers des jetons affectables aux applicatifs services servis, valeur des timers des sessions en cours des applicatifs services servis, contenu de chaque pile de jetons gérée, état (activité) de chaque applicatif service servi, - état (activité) de chaque serveur de données de session utilisé ou utilisable. sessions auxquelles participe chaque applicatif servi. jetons en cours d'utilisation par chaque applicatif (AS) servi. état (activité) de chaque serveur de données de session utilisé ou utilisable.
3. Traitements opérés par les module logiciel client et module logiciel multi- client
Les module logiciel client et module logiciel multi-client procèdent, par exemple, aux traitements suivants, sur réception de signaux ou changement d'état : - Message ping reçu du serveur de données de session :
S'il gère le client dont l'identifiant est précisé dans le ping, renvoie un message pong avec cet identifiant. Message arrêt du serveur de données de session :
Informe les AS gérés et mémorise l'information. - Message redémarrage du serveur de données de session :
Informe les AS gérés et mémorise l'information. Message timeout de session reçu du serveur de données de session :
Peut par défaut demander un maintien de session, ou transférer le message à l'AS ou aux AS concernés. - Timeout serveur de données de session ou client :
Envoie au(x) serveur(s) de données de session concerné(s) un message hello, avec l'identifiant du client servi. Taille minimum de pile de jeton d'un client :
Envoie au serveur de données de session une requête de demande de n=max-min jetons.
Entre ces jetons dans la pile du client concerné. Timeout de jeton :
Envoie au serveur de données de session une requête de test de validité du jeton. - Si NOK, supprime le jeton de la pile.
Message expiration de jetons reçu du serveur de données de session : Supprime les jetons concernés des piles Si les jetons sont déjà alloués à des AS, les en informe. Message expiration de tous les jetons reçu du serveur de données de session : - Supprime tous les jetons des piles
Si des jetons sont déjà alloués à des AS, les en informe. Requête récupération de j jetons reçue d'un AS :
Retire les j jetons de la pile de jetons affectée à cet AS. Requête libération de jetons de j jetons reçue d'un AS : - Remet les j jetons dans la pile de jetons affectée à cet AS.
Requête libération de tous les jetons reçus d'un AS :
Si mémorisation de l'état des jetons, remet les jetons dans la pile de jetons affectée à cet AS. Si non mémorisation de l'état des jetons, peut : - soit ignorer cette requête, soit vider la pile de jetons affectée à cet AS et transmettre cette requête au serveur de données de session. Message arrêt ou redémarrage client reçu d'un AS :
Informe les serveurs de données de session concernés en précisant les identifiants clients et mémorise l'information.
Pour les autres messages, les modules logiciels clients et module logiciel multi-client peuvent transférer les messages des AS vers les serveurs de données de session et des serveurs de données de session vers les AS, en mettant à jour les indicateurs d'états et les timers.

Claims

REVENDICATIONS
1. Procédé de transmission de données, caractérisé en ce qu'il comprend : une étape de réception d'un message émis par une entité émettrice, ledit message comprenant : un identifiant de typologie, désignant un type prédéfini de message ; une information corrélante, identifiant des données de session d'usage dans un serveur de données de session, et ayant une durée d'existence limitée ; une étape d'utilisation sélective d'au moins un dispositif spécifique audit type pour traiter ledit message pendant ladite durée d'existence de ladite information corrélante.
2. Procédé de transmission de données selon la revendication 1, caractérisé en ce qu'il comprend, postérieurement à ladite étape d'utilisation une étape d'émission d'une réponse audit message à destination de ladite entité émettrice, par le biais dudit dispositif spécifique.
3. Procédé de transmission de données selon l'une quelconque des revendications 1 et 2, caractérisé en ce que ladite typologie de message comprend des types de messages appartenant au groupe comprenant au moins : des messages de service ; des notifications ; des commandes ; - des requêtes.
4. Procédé de transmission de données selon l'une quelconque des revendications 1 à 3, caractérisé en ce qu'il comprend, préalablement à ladite étape de réception, une étape d'obtention d'une information corrélante apte à être utilisée au sein dudit message.
5. Dispositif de transmission de données, caractérisé en ce qu'il comprend : des moyens de réception d'un message émis par une entité émettrice, ledit message comprenant : un identifiant de typologie, désignant un type prédéfini ; - une information corrélante, identifiant des données de session d'usage dans un serveur de données de session, et ayant une durée d'existence limitée ; des moyens d'utilisation sélective d'au moins un dispositif spécifique audit type et apte à traiter ledit au moins un message pendant ladite durée d'existence de ladite information corrélante.
6. Dispositif de transmission de données selon la revendication 5, caractérisé en ce que ledit dispositif spécifique se présente sous la forme d'au moins un module logiciel client spécifique pour chaque type de message appartenant à ladite typologie.
7. Dispositif de transmission de données selon la revendication 6, caractérisé en ce que ledit au moins un module logiciel comprend une capacité d'échange de données avec au moins un module applicatif apte à rendre un service applicatif requit par ledit message.
8. Dispositif de transmission de données selon la revendication 5, caractérisé en ce que ledit dispositif spécifique se présente sous la forme d'au moins une interface spécifique pour chaque type de message appartenant à ladite typologie.
9. Dispositif de transmission de données selon la revendication 5, caractérisé en ce que ledit dispositif spécifique se présente sous la forme d'un module logiciel client combiné à une interface spécifique.
10. Dispositif de transmission de données selon l'une quelconque des revendications 8 et 9, caractérisé en ce que ladite interface spécifique est une adresse IP spécifique pour chaque type de message appartenant à ladite typologie.
11. Dispositif de transmission de données selon l'une quelconque des revendications 8 et 9, caractérisé en ce que ladite interface spécifique se présente sous la forme d'un port spécifique d'une adresse IP.
12. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution du procédé de transmission de données selon l'une au moins des revendications 1 à 4, lorsqu'il est exécuté sur un ordinateur.
PCT/FR2008/051355 2007-07-19 2008-07-17 Procede d'echange de messages entre serveur de donnees de session et des services clients WO2009013440A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0756606A FR2919140A1 (fr) 2007-07-19 2007-07-19 Procede d'echange de messages entre serveur de donnees de session et services clients
FR0756606 2007-07-19

Publications (1)

Publication Number Publication Date
WO2009013440A1 true WO2009013440A1 (fr) 2009-01-29

Family

ID=39332056

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2008/051355 WO2009013440A1 (fr) 2007-07-19 2008-07-17 Procede d'echange de messages entre serveur de donnees de session et des services clients

Country Status (2)

Country Link
FR (1) FR2919140A1 (fr)
WO (1) WO2009013440A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102447734A (zh) * 2012-02-14 2012-05-09 浪潮齐鲁软件产业有限公司 一种税务云计算网开im在线客服系统云端服务方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5717745A (en) * 1995-04-24 1998-02-10 Mci Communications Corporation System and method of efficiently evaluating different messages by a server in a telecommunications environment
US20050005133A1 (en) * 2003-04-24 2005-01-06 Xia Sharon Hong Proxy server security token authorization
US20060031283A1 (en) * 2000-12-18 2006-02-09 Timothy Tuttle Asynchronous messaging using a node specialization architecture in the dynamic routing network
US20060221925A1 (en) * 2001-10-03 2006-10-05 Cisco Technology, Inc. Token Registration of Managed Devices

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5717745A (en) * 1995-04-24 1998-02-10 Mci Communications Corporation System and method of efficiently evaluating different messages by a server in a telecommunications environment
US20060031283A1 (en) * 2000-12-18 2006-02-09 Timothy Tuttle Asynchronous messaging using a node specialization architecture in the dynamic routing network
US20060221925A1 (en) * 2001-10-03 2006-10-05 Cisco Technology, Inc. Token Registration of Managed Devices
US20050005133A1 (en) * 2003-04-24 2005-01-06 Xia Sharon Hong Proxy server security token authorization

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102447734A (zh) * 2012-02-14 2012-05-09 浪潮齐鲁软件产业有限公司 一种税务云计算网开im在线客服系统云端服务方法
CN102447734B (zh) * 2012-02-14 2014-01-15 浪潮齐鲁软件产业有限公司 一种税务云计算网开im在线客服系统云端服务方法

Also Published As

Publication number Publication date
FR2919140A1 (fr) 2009-01-23

Similar Documents

Publication Publication Date Title
EP2936782B1 (fr) Procédé de traitement de requêtes d'accès et navigateur web
EP2955875B1 (fr) Serveur, client et système de gestion d'un réseau d'interconnexion
FR2860616A1 (fr) Unite de commande de dispositif de memorisation et procede de commande de celui-ci
EP1617591A1 (fr) Procédé et serveur de référencement de diffusion poste à poste de fichiers demandés par téléchargement à ce serveur
EP2807815B1 (fr) Système et procédö de controle d'une requête dns
EP0524089A1 (fr) Structure de logiciel pour système de traitement de données, notamment pour système de télécommunications
EP2227048A1 (fr) Procédé de gestion de profils d'utilisateurs d'un réseau de pairs
WO2009013440A1 (fr) Procede d'echange de messages entre serveur de donnees de session et des services clients
WO2004080015A1 (fr) Procede de gestion de presence selective pour service de messagerie instantanee au sein d’un reseau de telecommunication tel que le reseau internet
EP2481200B1 (fr) Controle d'une session d'echange de donnees entre des terminaux d'un premier utilisateur avec au moins un terminal d'un deuxieme utilisateur
FR2888706A1 (fr) Procede de mise en relation interpersonelle
FR3006526A1 (fr) Chargement dynamique de composants applicatifs
EP1952599B1 (fr) Procede de diffusion maitrisee d'informations
EP1933531B1 (fr) Dispositif de contrôle de communications sur IP entre des équipements de communication IP, avec prise de contrôle automatisée de leurs flux de média(s)
FR3071993A1 (fr) Procede de gestion d'un echec d'etablissement d'une communication entre un premier et un second terminal
EP2446608B1 (fr) Technique de contrôle d'accès par une entité cliente à un service
FR2816419A1 (fr) Procede de repartition de charge entre serveurs d'un systeme informatique distribue
FR3027180A1 (fr) Procede de diffusion de contenus en streaming dans un reseau pair a pair
WO2024028472A1 (fr) Procédé de traitement d'une requête d'analyse statistique ou prédictive, procédé de communication et entités applicatives aptes à mettre en oeuvre ces procédés
EP4343568A1 (fr) Entité pour mettre en oeuvre un service dans un réseau, dispositif applicatif, et procédé d'éxecution d'une opération d'un service
FR3024315A1 (fr) Systeme et procede de mise a disposition de fichiers informatiques.
EP1936934A1 (fr) Procédé de diffusion d'un flux depuis une plate-forme de service, produit programme d'ordinateur et plate-forme de service correspondants
FR2893472A1 (fr) Procede et dispositif pour collecter des donnees en provenance de nombreux terminaux
FR3062543A1 (fr) Procede de mise a jour d'une liste noire de reference associee a au moins un utilisateur
EP2479669A1 (fr) Procédé et dispositif de médiation pour faire interagir des applications indépendantes au sein d'un réseau de communication

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08826626

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08826626

Country of ref document: EP

Kind code of ref document: A1