WO2002051178A1

WO2002051178A1 - Centralized session management

Info

Publication number: WO2002051178A1
Application number: PCT/FI2001/001119
Authority: WO
Inventors: Markku Koskela
Original assignee: Sonera Oyj
Priority date: 2000-12-21
Filing date: 2001-12-18
Publication date: 2002-06-27
Also published as: FI20002821A0; FI20002821A; AU2002219265A1

Abstract

This invention relates to the handling of sessions between clients and services. The invention is to use a centralized element for keeping and managing information of the sessions. Each session (client) is identified by a session-specific ID. The application in the server to which the client is connected checks the session's, i.e. the client's, ID from a centralized element, called session management, by sending the ID to the session management. The session management checks that the ID is correct. If it is, the session management sends the session information of the client to the application. When the session information changes from the act of the client and/or the application, the application updates the changes to the session management.

Description

European patent (AT, BE, CH, CY, DE, DK, ES, FI, FR, For two-letter codes and other abbreviations, refer to the "GuidGB, GR, IE, IT, LU, MC, NL, PT, SE, TR), OAPI patent ance Notes on Codes and Abbreviations " appearing at the begin(BF, BJ, CF, CG, CI, CM, GA, GN, GQ, GW, ML, MR, ning of each regular issue of the PCT Gazette NE, SN, TD, TG).

Published:

Centralized Session Management

Field of the Invention

This invention relates to the handling of sessions between clients and services. In particular, the invention relates to the telecommunications field where there can be thousands of clients using the same sen/ice simultaneously. There can also be thousands of different services that are offered to the customers.

Background of the Invention

A session is conceived to be the time period between the login and the logout of a service in a datacommunications network, or the dialing of the phone number and the hanging up of the phone in a telecommunications network. The present evolution goes towards a common network structure, which is capable of transmitting data, voice and audio, i.e. towards a network comprising features of a datacommunications and telecommunications network.

Each session contains session-specific information, such as the phone number, the name of the client, the rights of use, and the state of the session. FIG. 1 shows an example of a known solution to handle the sessions and the session-specific information. Each client 1 has its own process (a copy of the application in use) 2 in a server 3 for offering the service to the client. The client-specific process handles the session information. For example, if the service (application) is a spreadsheet, each client has his own application copy of the sheet and the state of the sheet. The drawback of this solution is that the server must process several copies of the same application.

FIG. 2 shows another example of a known solution to handle the sessions and the session-specific information. In the Web, cookies are the normal way to handle session management. A cookie 21 is a code for identifying the browser 22 so that the process (the web-page application) 23 can identify each browser that is using the application. The server 24 containing the application sends client-specific cookies, which contain client-specific state information. Typically, the size of a cookie is about 2 kbytes. The browser can keep the cookie information in the cache only during the session, or the cookie is saved in the memory of the client for a certain period. The use of URLs (Uniform Resource Locator) corresponds to the use of cookies. URL is a string that gives the location of a piece of information (such as a web-page). Furthermore, URL may contain session-specific information. However, the capacity of URL is less than the capacity of a cookie to carry session information. Drawbacks of the cookie or URL are that they have a low capacity to carry information, and the communication traffic between the client and the server will grow. Furthermore, the client must have the ability to use cookies. In addition, session management is dependent on a client terminal. When the client wants to change something in the web-page (i.e. use the service page), the desired changes are delivered to the application using URL (or a query string technique). Also the cookie is sent back to the server containing the session information. The application is adapted for the client according to the desired changes. In turn, the application updates the cookie, and sends it back to the client. In this way, the session-specific information is sent back and forth between the client and the server, the browsers keeping the session-specific information in their memories.

The aim of the invention is to reduce the drawbacks of the known solutions and to offer a more efficient way to handle session management. These are achieved in a way described in the claims.

Summary of the Invention

The idea of the invention is to use a centralized element for keeping and managing information of the sessions. Each session (client) is identi- fied by a session-specific ID. In the case of a phone the ID can preferably be the phone number. The application in the server to which the client is connected checks the session's, i.e. the client's, ID from a centralized element, called session management, by sending the ID to the session management. The session management checks that the ID is correct. If it is, the session management sends the session information of the client to the application.

When the session information changes from the act of the client and/or the application, the application updates the changes to the session management. Due to the centralization, it is easy to monitor and manage sessions. Furthermore, the clients are independent of the technology used in an application. Brief Description of the Drawings

In the following the invention is described in more detail by means of FIGs 1 - 5 in the attached drawings where.

FIG. 1 illustrates an example of the traditional way to handle session information, FIG. 2 illustrates an example of the prior way to handle session information in a Web-based network, FIG. 3 illustrates an example of the way according to the invention to handle session information, FIG. 4 illustrates an example of where the client uses the services of the application according to the invention, FIG. 5 shows an example of a flow chart that describes the method ac- cording to the invention.

Detailed Description of the Invention

FIG. 3 shows an example of an arrangement according to the invention. When a client 31 wants to use some service 32, he calls the service number (or address). The client terminal is preferably a PC or a WAP phone. The client terminal can also be an SMS terminal, a normal phone, or any other type of device. The service, i.e. the application can be in any server 33 in the network. Actually, it is preferable that a sufficient number of the servers contain their own copy of the application. In this way, the service can be of- fered to very many clients in a large geographical area.

At the beginning of the session, when the client is logging in for using the application 32, the session ID does not exist. Thus the client does not send a cookie or URL containing the session ID which is noticed by the application. Noticing that the session is new, the application asks the session management 35 to create a data storage and session ID for session information. The session management sends the session ID to the application, which is now ready to create, use and update the session information storage in the session management. The application sends the created session ID, 34 to the client (in cookie or URL). When using the service the client sends the session ID to the application. The application checks that the client is ok, by using the session ID 34 (or the phone number) of the client. The checking is done by using the session management 35. The application asks the session information that is identified by using the session ID from the session management, which checks the validity of the ID, i.e. that the data storage that corresponds to the ID exists. If the ID is correct, the session management sends the session information 36 of the client to the application. The session information comprises the client-specific information, such as the client's name, address, phone numbers, state information of the application, and the rights of use. The client's session information of the application is created at the first ses- sion in the application, when the session information needed is saved in the session management.

It is worth noting that the client can actually use several applications during one session. For example, the client can use another application for a while, and then go back to use the originally used application. The ses- sion information keeps state information of both applications (or all applications used in the session) until the client logs out of the session when the session information is deleted in the session management.

The application can use databases 37 in the network for getting necessary information for accomplishing the required service. The state of the application (the session) changes when it is performing its tasks. The changes are saved in the application state information (in the session information). So, the session information needed is sent between the application and the centralized session management. Since the transmission path between the application and the session management is preferably in the net- work part with high capacity, there is no strict limit on the amount of session information. Usually, the path between the application and the session management is also safer than the path between the client and the application. When the session is terminated, the session information is deleted. So, the next time, when the client wants to use the application, a new client-specific session ID and a data storage in the session management must be created.

FIG. 4 shows an example of a calendar service. The client 41 wants to look at his calendar information, so he calls to the calendar service

42. The calendar service has been distributed all over the network, several servers 43 containing the calendar application 42. Preferably the nearest ap- plication handles the call. At the beginning of the session, the client-specific session ID 44 (in this case the WAP phone number) and a session informa- tion data storage 46 are created in the session management 45. The session management keeps a data storage for the session information of the clients. The session ID is sent to the application, which forwards it to the client. When the client uses the calendar, the changes are updated in the session man- agement. The calendar application uses the session ID for requesting and updating the session information. If the ID is valid (the session-specific storage exists), the session management sends the client-specific session information 45, such as the name, time, and date, to the application.

In this case, the application uses a special calendar database 47 for keeping the actual calendar information, such as meetings, holidays, and short memos. The application loads the calendar information from the database, and uses the date information of the session information for creating the calendar service for the client. The client can make necessary changes to the calendar, and the application handles the updating of the changes for the calendar database and for the session management. The application also sends the desired service information to the client.

Client-specific session information must be created in the centralized session management. This is done when the client logs into the service as mentioned before. In the session information configuration, the client gets a session ID, which is used when the client uses the application, for identifying the client and the client-specific information. Further, in the configuration, the session management saves the session information needed for successful running of the application. FIG. 5 shows an example of a flow chart according to the invention, illustrating the method in a running time, assuming that the session information configuration has been done earlier. First, the session ID must be checked 51. As described above, the checking is handled by the cooperation of the application and the session management. The application sends the session ID to the session management, and if the ID is ok, i.e. the session-specific information storage exists, the session manage- ment sends the session information to the application, i.e. the session information is requested 52 by the application. As the session information changes, it must be updated 53 in the session management. The application sends the update information to the session management. The aim is that the application does not keep the session information in its own cache, but in- stead, the session management does, as it has enough capacity to handle session information of several (thousands) clients. Due to this, the requesting and the updating steps must be repeated 54 as many times as needed during the session.

Session information is application state-specific and client-specific information for each application and client. Thus, the session management may contain a number of session information storages for each client, each storage containing the information that the application or applications need during the session.

As mentioned before, clients are independent of the technology used in the applications. Since the clients do not need to receive or keep session information, such as cookies or URLs, they do not need complicated features. Applications use, for example, HTTP-protocol, and the applications have been created using different techniques. For example, an application is a CGI (Common Gateway Interface) application having a connection for client terminals. Other possible application technologies are NSAPI (Netscape Application Program Interface), ISAPI (Internet Service Application Program Interface), and JavaServlet.

Since the session management information is sent in the trunk network with high capacity, it is possible to efficiently use the central session management as a database. The trend seems to be towards services, which need more session management information. The prior art solutions do not offer an efficient way to handle the growth of such services. Further, it is worth noting that the path between the application and the session management usually is safer than the path between the application and the client. For example, CORBA (Common Object Request Broker Architecture) can work as a technological base (interface) for the interworking between the application and the session management.

The invention is not restricted to the examples above. For example, the invention can comprise several session management elements, each of them handling a part of the network. It is worth noting, that in this case the session management elements have to update session information among themselves so that each element has the latest session information. It is evident that the invention can also be used in other solutions, in the scope of the inventive idea.

Claims

1. An arrangement for handling client-specific session information in a network that comprises at least one client terminal and at least one server, the server comprising at least one service application, whereby said session information is for a session established between a client terminal used by a client and a service application, and whereby the session is the period the client uses the service, characterized in that the arrangement further comprises a centralized element for keeping and managing the session information.

2. An arrangement according to claim 1, characterized in that the arrangement further comprises a session identifier for each session, for identifying the session information, specific for each client.

3. An arrangement according to claim 2, characterized in that the arrangement further comprises at least one connection between the central element and the service applications for transmitting the session information.

4. An arrangement according to claim 3, characterized in that the arrangement further comprises at least one connection between the client terminals and the service applications for transmitting services of the service applications to the client.

5. An arrangement according to claim 4, characterized in that the arrangement further comprises means in the client terminal for sending the session identifier to the application.

6. An arrangement according to claim 2, characterized in that the session identifier is the phone number of the client terminal, the terminal being a phone.

7. An arrangement according to claim 1, 2, 3, 4, 5, or 6, c h a r- acterized in that the arrangement comprises several central elements.

8. A method for handling client-specific session information in a communication network, the session being between a client and a service application in a network, characterized in that the method comprises the step of using a centralized element for creating, keeping, and managing session information of several clients.

9. A method according to claim 8, characterized by cre- ating a session information data storage and a session ID for the session at the beginning of the session.

10. A method according to claim 8 or 9, characterized in that the method comprises for each session the steps of

- checking that the client-specific session information exists using the ID of the session for identifying the session information, - requesting the client-specific session information from the centralized element that keeps and manages the session information, for the use of the application,

- updating the client-specific session information in the central element, when needed, and - repeating the requesting step as many times as needed during the session

- repeating the updating step as many times as needed during the session.

11. A method according to claim 10, characterized in that the checking step comprises the steps of

- sending the session ID from the client to the application,

- sending the session ID from the application to the central element.

12. A method according to claim 8, 9 or 10, characterized in that the method further comprises the step of updating the session specific information among several central elements.