JP2006244428A - Session management method and session management system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To manage a session at each client application. <P>SOLUTION: Session information added to a request from a client application to a server application is retrieved and acquired from a session management table based on session management information, when managing the session indicating a logical connection relation between the client application and the server application by using a session management table for storing session information transceived between the client application and the server application, and session management information acquired at a client side while being correlated therebetween, and the session management information acquired at the client side and the session information are stored in the session management table while being correlated therebetween in a request when storing the session information received from the server application. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to a technique for managing a session indicating a logical connection relationship between a client application and a server application in a distributed environment.

  Accompanying the remarkable spread of the Internet in recent years, the interface between the client and the server in the client-server system that used the original interface has been made compliant with the standard protocol HTTP (Hypertext Transfer Protocol) / HTML (Hypertext Markup Language). The movement to make a web application that is a server service available from a client web browser is rapidly expanding without depending on a specific client platform.

  In addition, Web services that directly exchange data with client applications using Internet standard technologies such as XML (Extensible Markup Language), SOAP (Simple Object Access Protocol), and HTTP are beginning to spread.

  In data exchange performed on these networks, session management is performed. In the above HTTP protocol, every time a client application requests a Web server, a connection is established between the client and the server, a response to the request is made, and the communication is terminated, and then the connection is disconnected. .

  That is, a series of processes “connection, communication, disconnection” are performed. This series of processing is called a “session”. Information exchanged during one session becomes invalid when the session ends. Therefore, the information of one session cannot be carried over to the next session.

  However, in order to share information among a plurality of sessions, there are cases where it is desired to manage a plurality of sessions as one session. For example, if "Login", "Product selection", "Clearing process", "Logout", etc., which are a series of processes until product purchase at the shopping site, become separate sessions, the logged-in user information and the selected product information In this case, it is not known that the clearing information and the logout information are related to each other, and shopping processing is not established. Therefore, it is necessary to manage a plurality of sessions as one session. In this way, a mechanism for managing a series of processes as one session is called session management.

  As a general method for realizing this session management, for example, there is a method using a session ID issued by a server as information for identifying a session. In this method, a client holds a session ID added to a response to a request from the client to the server, and the held session ID is added when a request for the next process is transmitted.

  Based on this session ID, the server application performs processing using information held in units of sessions and makes a response. Normally, a client application can set whether or not to set up a session. When processing is executed with a setting that does not set up a session, a request is sent without adding a session ID. Even if a session ID is added to the response to the response, the session is terminated without holding the session ID.

  Regarding session management, it is desired that fine control can be performed on the client side, particularly when the server side is a Web service. This is because a Web service can be treated as providing a part of processing rather than providing a series of processing as a single flow like a Web application, and a client can provide one or more Web services. This is because a form in which various services are used in combination is established, and the flow is formed mainly by the client side.

By the way, conventionally, when a client application is executed in a multi-process environment, even if the access destination is the same server, the session ID is stored for each process. Therefore, even if there are a plurality of client applications, each client application can hold a separate session and execute a series of processes. Conversely, instead of handling independent sessions for each process, proposals have been made for applications to handle a common session intentionally (see, for example, Patent Document 1), and control the unit of session management. It is possible to do.
JP 2004-220318 A

  Some embedded devices have an architecture for starting a plurality of applications on an application platform that operates in a single process. When session management is performed with a common library that can be used in common by applications on such an architecture, even if access requests are made to the same server from different client applications, it is determined from which client applications the common library is requesting access. Can not do it. Therefore, the same session ID is used unintentionally between client applications.

  That is, when the same web service is accessed from different client applications, the web service is processed as the same session regardless of the different client applications, and cannot operate as an independent client application. There is a problem.

  Conventionally, it has been difficult to handle a session flexibly from a client application. When managing a session more flexibly from a client application, even if the client application is once terminated, processing continues in the previous session after restart, and conversely, a new session is restarted It is desirable to have the flexibility to select from the client application to initiate.

  Normally, a client application uses a web service via a web service library. The Web service library is a module that generates and analyzes a SOAP message that is exchanged between the client and the Web service. The client application generates an object as an interface for calling this module and exchanges data with the Web service.

  When a client application performs processing such as holding a plurality of sessions while holding a session for one server application, objects are generated for the number of sessions desired. However, it becomes inefficient on devices with few resources.

  Furthermore, when a session is flexibly managed from a client application, it is desired that the held session ID is initialized by the client application.

  Further, in an environment where resources are limited such as an embedded device, it is required to reduce the number of generated objects so that memory is not consumed as much as possible when an application is executed. However, when trying to start a new session for the same server, it is necessary to newly generate an object that calls a module for accessing the server and to access the object using the object.

  The present invention has been made to solve the above-described problems, and an object thereof is to enable session management for each client application.

  Another object of the present invention is to enable continuous session management on the client side.

  Another object of the present invention is to enable initialization of a session managed on the client side.

  The present invention provides a logical connection relationship between the client application and the server application using a session management table that stores session information transmitted and received between the client application and the server application and session management information acquired on the client side in association with each other. A session management method for managing a session indicating a session information search step for retrieving and acquiring session information to be added to a request from the client application to the server application from the session management table based on the session management information; When storing session information received from the server application, the session management information acquired on the client side at the time of request and the session information Characterized in that the association and a session information storage step of storing the session management table.

  Further, the present invention provides a logical connection between the client application and the server application using a session management table that stores session information transmitted and received between the client application and the server application in association with session management information acquired on the client side. A session management device that manages a session indicating a connection relationship, and retrieves session information to be added to a request from the client application to a server application from the session management table based on the session management information and acquires the session information search And session management information received on the client side at the time of the request and the session information received from the server application. And having a session information storage means for storing in said session management table in association with the information.

  According to the present invention, it is possible to flexibly manage a session indicating a logical connection relationship between a client and a server on the client side.

  The best mode for carrying out the invention will be described below in detail with reference to the drawings.

  Before describing this embodiment, an outline of processing in a Web service will be described first. FIG. 1 is a diagram illustrating an example of a configuration of a system in which a Web service is performed. As shown in FIG. 1, a system in which a web service is performed includes a client application 101 that uses the web service, a stub object 102, a web service library 103, a communication library 104, a network 105, and a server that provides the web service The application 106 is configured.

  The client-side applications, libraries, and the like are programs executed by an operating system (OS) in a computer such as a personal computer or an embedded device. Further, although the configuration on the server side is not shown in detail, it is assumed that libraries and modules necessary for providing the Web service are provided in the same manner as on the client side.

  The computer functioning as a client or server may be a general-purpose computer, and a description thereof is omitted here.

  The stub object 102 is a module that is a method call destination from the client application 101, and further performs type conversion of arguments and return values between the client application 101 and the Web service library 103. The class of the stub object 102 is automatically generated by a stub generation program from a service specification described in WSDL (Web Services Description Language), and there are different stub objects 102a and 102b depending on the provided methods. . Even when the same method is provided, different stub objects 102 and 102a exist for each client application.

  The above-mentioned WSDL is a Web service description language based on XML, and is formulated by W3C (World Wide Web Consortium). This WSDL defines a method for describing what functions a Web service has and what requests it should make in order to use it.

  The Web service library 103 is a module that mutually converts a method call from the stub object 102 and a SOAP message.

  The communication library 104 is a module that communicates with the server application 106 via the network 105, and performs communication using HTTP or the like.

  The server application 106 is a module that actually provides a service based on the SOAP message sent from the client, and returns the processing result to the client as a SOAP message.

  In this Web service processing, only the stub object 102 can be seen from the client application 101, and the stub object 102, not the server application 106, is recognized as the processing provider.

  Therefore, when using the Web service, the client application 101 first acquires the stub object 102. Once acquired, the stub object 102 can be used any number of times to call a method provided by the Web service.

  Next, the client application 101 sets a URL (Uniformed Resource Locater) of a desired server application 106 for the stub object 102. If the server application 106a that provides the same service and has a different URL is not used, this process may be performed once. If the server application 106a having a different URL is used, this process may be performed again.

  Next, in order to use the Web service, the client application 101 calls a method of the stub object 102 (process 111). On the other hand, the stub object 102 converts the argument of the called method into an object that can be processed by the Web service library 103, and calls the Web service library 103 (processing 112).

  Here, the Web service library 103 converts the method call from the stub object 102 into a SOAP message, and requests the communication library 104 to transmit (process 113).

  The communication library 104 transmits a SOAP message to the server application 106 through the network 105 using the HTTP protocol (process 114).

  Accordingly, the server application 106 interprets the received SOAP message, performs a predetermined process, and transmits the result as a SOAP message to the communication library 104 using the HTTP protocol (process 115).

  The communication library 104 passes the received SOAP message to the Web service library 103 (process 116). The Web service library 103 that has received the SOAP message from the communication library 104 converts the SOAP message into a response to the method call and returns it to the stub object 102 (process 117).

  The stub object 102 converts the return value of the response to the method call returned from the Web service library 103 into a type required by the client application 101 and returns it to the client application 101 (processing 118).

  With the above processing, the client application 101 can request processing from the server application 106 on the network 105 and obtain a response by simply calling a normal method.

  Further, if the client application 101 uses the same server application 106, the above-described processing 111 may be repeated.

  The above-described processing is an example of a Web service mounting method, and there is an implementation that does not use the stub object 102. However, the mechanism in which a method call from the client application 101 is converted into a SOAP message and transmitted to the server application 106, and a SOAP message returned from the server application 106 is converted into a method return value and returned to the client application 101 is a Web mechanism. This is the basic structure of the service.

[First Embodiment]
Next, the first embodiment according to the present invention will be described in detail with reference to FIGS. As shown in FIG. 2, the first embodiment further includes a session management table 201 in the configuration of FIG. 1, and the Web service library 103 performs session management based on the session management information registered in the session management table 201. Is.

  FIG. 3 is a diagram illustrating an example of a configuration of a session management table according to the first embodiment. As shown in FIG. 3, in the first embodiment, the session management table uses the object ID 301 of the stub object 102 as session management information, and manages the URL 302 and session information 303 of the server application as connection destination server information. It is.

  Further, instead of the object ID 301 of the stub object 102, the object ID of the client application 101, or the object itself of the stub object 102 or the client application 101 may be used as the session management information. Further, the Web service library 103 may generate a unique value such as a UUID (Universally Unique Identifier), and the UUID may be used as session management information.

  An object ID 301 of the stub object 102 is an object ID of the stub object 102 that mediates between the client application 101 and the Web service library 103, and this ID is different for each stub object 102. Further, when the stub object 102 is acquired after restarting the client application 101 or the system, a different ID is used each time.

  If the server application 106 used in the client application 101 is not changed in the session management table, the URL 302 of the server application may be omitted.

  304 and 305 shown in FIG. 3 are when the session management ID 301 is “Stub Object1” and the URL 302 of the server application is different between “http://aaa.com/” and “http://aaa1.com/”. , “Session1”, “Session1A”, and the like, different session information is being managed. Also, 306 shown in FIG. 3 is different in session management ID 301 from “Stub Object2” as compared to 304, but the server application URL 302 is the same “http://aaa.com/”, and session information different from 304 is obtained. The state in which “Session2” is managed is shown.

  The session information 303 is information used to manage a plurality of communications as a series in communication with the server application 106, that is, used for session management. When HTTP is used when communicating with the server application 106, the session information 303 is HTTP. This is unique information that is transmitted as Cookie information in the header, or transmitted by being added to the request URL to the server application 106.

  Here, with reference to FIG. 4, processing on the client side that manages a session by using the session management table shown in FIG.

  FIG. 4 is a flowchart showing the overall processing of the Web service in the first embodiment. The part surrounded by a solid line is processing by the client application 101, the part surrounded by a dashed line is processing by the stub object 102, and the part surrounded by a dotted line is processing by the Web service library 103. A portion surrounded by a dotted line is processing in the communication library 104.

  First, in step S401, the client application 101 acquires the stub object 102. Since the stub object can be reused, this acquisition process has only to be performed once, and this step is unnecessary in the second and subsequent method call processes described later.

  In step S <b> 402, the client application 101 sets the URL of the server application 106 for the stub object 102. Next, in step S403, the client application 101 calls a method of the stub object 102 in order to use the Web service. If the UUID issued by the Web service library 103 is used as the session management information, a UUID issue method provided in the Web service library 103 is called to acquire the UUID. The acquired UUID is set in the stub object 102 as session management information.

  Next, in step S404, the stub object 102 performs the type conversion processing of the argument of the method given from the client application 101, and the Web service library 103 is called. Here, the stub object 102 includes the method argument. The own object ID and the URL of the server application 106 set in step S402 are passed to the Web service library 103 as arguments. When the session management information uses a UUID issued by the Web service library 103 instead of the object ID, the UUID is passed to the Web service library 103 as session management information.

  As a result, the Web service library 103 first generates a SOAP message corresponding to the called method in step S405. Next, in step S406, the session management table is searched using the object ID of the stub object passed from the stub object 102 and the URL of the server application as keys. In step S407, the search result is determined.

  In step S407, if the object ID of the stub object and the URL of the server application are not set in the session management table and the corresponding session information 303 does not exist, the process proceeds to step S409, and the stub object 102 is sent to the communication library 104. Requests transmission of a SOAP message to the server application 106 of the URL passed from.

  In step S407, if the object ID of the stub object and the URL of the server application are set in the session management table and the corresponding session information exists, the process proceeds to step S408, and the session information 303 is transmitted to the communication library 104. To be added to the request header. In step S409, a request is made to send a SOAP message to the server application 106 with the URL passed from the stub object 102.

  On the other hand, the communication library 104 first transmits a SOAP message as a request to the server application 106 via the network 105 in step S410 and waits for reception of a response. In step S 411, when the communication library 104 receives a response from the server application 106, it passes the header information of the response and the SOAP message that is the result of the processing sent from the server application 106 to the Web service library 103.

  As a result, the Web service library 103 first acquires session information from the header information of the response in step S412. In step S413, the session management table is searched. In step S414, the search result is determined.

  If the session information acquired in step S412 is not registered in the session management table, the process proceeds to step S415, and the session information is registered in the session management table in association with the object ID of the stub object and the URL of the server application.

  If the acquired session information is registered in the session management table, the process proceeds to step S416, and the object ID of the stub object and the URL of the server application are registered in the session management table corresponding to the session information, and the session information is updated. To do. In step S 417, the received SOAP message is converted into a method response and returned to the stub object 102.

  In step S418, the stub object 102 converts the return value returned from the Web service library 103 into a type requested by the client application 101. Then, in step S419, the message is returned to the client application 101.

  Thereby, in step S420, the client application 101 that has returned the return value from the stub object 102 ends the method call processing.

  When the client application 101 uses the Web service for the second time or later, if the server application 106 having the same URL is used, the process starts from step S403. If the server application 106b having a different URL is used, the process starts from step S402.

  In the above description, if the object ID of the stub object and the URL of the server application are not set in the session management table in step S407, the session information acquired in step S412 is replaced with the object ID of the stub object in step S415. It was registered in the session management table in correspondence with the URL of the server application.

  However, it can also be realized as follows. That is, if the object ID of the stub object and the URL of the server application are not set in the session management table in step S407, they are registered in the session management table in association with the object ID of the stub object and the URL of the server application, and step S409. Proceed to In step S415, the session information acquired in step S412 is registered in the session management table in association with the object ID of the stub object and the URL of the server application.

  According to the first embodiment, even if a plurality of client applications use the same server application via the Web service library, session information can be managed separately, so that each client application can establish a session independently. It is possible to maintain a different processing state for each client application.

[Second Embodiment]
Next, a second embodiment according to the present invention will be described in detail with reference to FIGS. In the first embodiment, a session management ID (object ID) is set in the session management table, but in the second embodiment, an application ID is set and session management is performed. Here, the application ID is an identifier for identifying individual client applications.

  FIG. 5 is a diagram illustrating an example of a configuration of a session management table according to the second embodiment. As shown in FIG. 5, the session management table of the second embodiment uses an application ID 501 that is an identifier of the client application 101 as session management information, and manages the URL 502 and session information 503 of the server application as connection destination server information. To do.

  The application ID 501 is a unique identifier that is unique to the client application and does not change when the system is restarted. For example, the application ID 501 is a client application name or a serial number set in the client application. is there. Alternatively, the UUID issued from the Web service library may be permanently stored in the client application and used as the application ID 501 as described in the first embodiment, instead of information that the application originally has fixedly. .

  Similarly to the first embodiment, if the server application 106 used in the client application 101 is not changed in the session management table, the URL 502 of the server application may be omitted.

  504 and 505 shown in FIG. 5 indicate that when the application ID 501 is “ApplD1” and the URL 502 of the server application is different between “http://aaa.com/” and “http://aaa1.com/”. It shows a state in which different session information is managed, such as “Session1” and “Session1A”. 5 differs from 504 in that the application ID 501 is “ApplD2”, but the server application URL 502 is the same “http://aaa.com/”, and the session information “Session2” is different from that in 504. "Is being managed.

  Note that the session information 503 is the same information as the session information 303 described in the first embodiment.

  Here, with reference to FIG. 6, processing on the client side that manages a session by using the session management table shown in FIG.

  FIG. 6 is a flowchart showing the overall processing of the Web service in the second embodiment. In the second embodiment, as in the first embodiment, processing performed by the client application 101, the stub object 102, the Web service library 103, and the communication library 104 is divided according to the type of line.

  First, in step S601, when the system is started, the Web service library 103 loads a session management table from a permanent storage device 600 such as a hard disk onto the client memory. Here, without reading the session management table from the permanent storage device 600, the session management table on the permanent storage device 600 may be searched by the search processing of the session management table in step S608.

  Next, in the client application 101, the processing in steps S602, S604, and S605 is the same as the processing in steps S401 to S403 illustrated in FIG. 4 in the first embodiment, and a description thereof is omitted.

  In the second embodiment, an application ID 501 is set for the stub object 102 in step S603. If the application ID 501 is not set for the stub object 102, as in the first embodiment, the session management table 301 uses the stub object ID, which is the session management ID 301, and the URL 302 of the server application as keys. A search is performed, and the transmission of a SOAP message to the server application 106 is requested using the obtained session information 303.

  However, in the first embodiment, when the UUID issued from the Web service library 103 is handled as session management information, it is not possible to determine whether session information is to be permanently stored using only session management information. It is set in the stub object 102 that management is necessary. The stub object 102 informs the Web service library 103 that persistent management is required when a method is called.

  Next, the processing of the stub object 102, the Web service library 103, and the communication library 104 shown in steps S606 to S618 is the same as the processing in steps S404 to S416 shown in FIG. Is omitted.

  Next, when the registration process or update process in step S617 or S618 is completed, in step S619, the Web service library 103 stores the session management table in the permanent storage device 600. Note that this step is not necessary when direct registration processing or update processing is performed on the session management table on the permanent storage device 600 in step S717 or S618.

  Next, the processing after step S620 is the same as the processing after step S417 shown in FIG. 4 in the first embodiment, and a description thereof will be omitted.

  According to the second embodiment, when the application ID is specified as the session management information by the client application, the session management information and the session information are stored in association with each other, so that the same session management is performed even after the client application is restarted. By specifying information, it is possible to continue processing using session information before restart.

[Third Embodiment]
Next, a third embodiment according to the present invention will be described in detail with reference to FIGS. In the third embodiment, session management is performed by adding sub ID information to the session management table described in the first embodiment. Here, the sub ID information may be any information as long as it is unique within the client application.

  FIG. 7 is a diagram illustrating an example of a configuration of a session management table according to the third embodiment. As shown in FIG. 7, in the third embodiment, the session management table uses the object ID 701 of the stub object 102 as the session management information, and manages the URL 702, sub ID 703, and session information 704 of the server application as connection destination server information. To do.

  As in the first embodiment, the object ID of the client application 101 may be used instead of the object ID 701 of the stub object 102 as the session management information.

  Further, if the server application 106 used in the client application 101 is not changed in the session management table, the server application URL 702 may be omitted.

  In FIG. 7, 705 and 706 have the same session management ID 701 “Stub Object1” and the server application URL 702 “http://aaa.com/”, but the sub ID 703 is “SubID1”, “ This indicates that different session information such as “Session1” and “Session1_1” can be managed when they differ in “SubID2”.

  Here, with reference to FIG. 8, processing on the client side that manages a session by using the session management table shown in FIG. 7 and uses a Web service will be described.

  FIG. 8 is a flowchart showing the overall processing of the Web service in the third embodiment. In the third embodiment, as in the first embodiment, processing performed by the client application 101, the stub object 102, the Web service library 103, and the communication library 104 is divided according to the line type.

  First, in the client application 101, the processes in steps S801, S802, and S804 are the same as those in steps S401 to S403 shown in FIG. 4 in the first embodiment, and a description thereof will be omitted.

  In the third embodiment, a sub ID 703 is set for the stub object 102 in step S803. Here, when the sub ID 703 is not set, the operation is the same as in the first embodiment.

  Next, the processes of the stub object 102, the Web service library 103, the communication library 104, and the client application 101 shown in steps S805 to S821 are the object ID 701 and sub ID 703 in steps S404 to S420 shown in FIG. 4 in the first embodiment. The other processes are the same except that is used, and the description thereof is omitted.

  According to the third embodiment, in addition to the effects of the first embodiment, by using the sub-ID, it is possible to access the server using the same object while retaining other session information. It is not necessary to create a new object

[Fourth Embodiment]
Next, a fourth embodiment according to the present invention will be described in detail with reference to FIGS. 9 and 10. In the fourth embodiment, sub-ID information is added to the session management table described in the second embodiment to perform session management. Note that this sub ID information may be any information as long as it is unique within the client application, as in the third embodiment.

  FIG. 9 is a diagram illustrating an example of a configuration of a session management table according to the fourth embodiment. As shown in FIG. 9, the session management table of the fourth embodiment uses an application ID 901 that is an identifier of the client application 101 as session management information, and a server application URL 902, sub ID 903, and session information 904 as connection destination server information. Is to manage.

  The application ID 901 is information similar to that in the second embodiment.

  Similarly to the second embodiment, if the server application 106 used by the client application 101 is not changed in the session management table, the URL 902 of the server application may be omitted.

  905 and 906 shown in FIG. 9 have the same application ID 901 “ApplD1” and the server application URL 902 “http://aaa.com/”, but the sub IDs 903 are “SubID1” and “SubID2”. It is shown that different session information can be managed like “Session1” and “Session1_1”.

  Here, with reference to FIG. 10, processing on the client side that manages a session by using the session management table shown in FIG. 9 and uses a Web service will be described.

  FIG. 10 is a flowchart showing the overall processing of the Web service in the fourth embodiment. Note that, in the fourth embodiment, similarly to the second embodiment, processing performed by the client application 101, the stub object 102, the Web service library 103, and the communication library 104 is divided according to the type of line.

  First, in step S1001, when the system is activated, the Web service library 103 loads a session management table from a permanent storage device 1000 such as a hard disk onto the client memory. The management table reading process is the same as the process in step S601 shown in FIG. 6 in the second embodiment.

  Next, in the client application 101, the processes in steps S1002 to S1004 and S1006 are the same as those in steps S602 to S605 shown in FIG. 6 in the second embodiment, and a description thereof will be omitted.

  In the fourth embodiment, a sub ID 903 is set for the stub object 102 in step S1005. Here, when the sub ID 903 is not set, the operation is the same as in the second embodiment.

  Next, the processing of the stub object 102, the Web service library 103, the communication library 104, and the client application 101 shown in steps S1007 to S1024 is performed in steps S606 to S623 shown in FIG. 6 in the second embodiment. The other processes are the same except that is used, and the description thereof is omitted.

  According to the fourth embodiment, in addition to the effect of the second embodiment, by using the sub-ID, it is possible to access the server using the same object while holding other session information. It is not necessary to create a new object

[Fifth Embodiment]
Next, a fifth embodiment according to the present invention will be described in detail with reference to FIG. In the fifth embodiment, when a plurality of users use a Web service, a session is managed for each user.

  FIG. 11 is a diagram illustrating an example of a configuration of a session management table list according to the fifth embodiment. As shown in FIG. 11, in the fifth embodiment, the session management table used in the first to fourth embodiments is provided for each user who uses the Web service from the client application 101, and the Web service library 103 is provided for each user. A session is managed based on a user identifier for identifying a user. The user identifier is, for example, the user name of a user who has logged in to the device.

  In the first to fourth embodiments, in the session information search process (for example, step S406 in FIG. 4), first, a user identifier is acquired, and a session management table corresponding to the acquired user identifier is acquired from the session management table list 1100. To do. Then, the session information is searched for the acquired session management table.

  By performing the above processing, it is possible to manage a session for each user and use a Web service without newly generating a stub object.

[Sixth Embodiment]
Next, a sixth embodiment according to the present invention will be described in detail with reference to FIG. In the sixth embodiment, a unique and permanent ID is set in the system for each client application, and a session is managed based on the permanent ID. Here, the permanent ID is a unique identifier that is unique to the client application that does not change when the client application or the system is restarted. The name of the client application or the serial number set in the client application Etc.

  FIG. 12 is a diagram illustrating an example of the configuration of a client-side system that uses a Web service according to the sixth embodiment. FIG. 12 shows only the portion related to the permanent ID, but the overall configuration is the same as the configuration shown in FIG.

  Here, processing when using a Web service from an individual client application will be described. The processing on the client side in the sixth embodiment is the same as that in the second embodiment described with reference to FIG. 6, and different processing will be described here.

  First, similarly to the second embodiment, the client application A 1201a specifies the set permanent ID and calls the method of the application A stub 1202a. Next, the application A stub 1202a calls the Web service library 1203 by adding the permanent ID set by the client application A 1201a to the argument.

  As a result, the Web service library 1203 searches the session information from the session management table 1210 using the permanent ID as a key, adds the acquired session information, sends a SOAP message to the server application 1204, and executes the Web service. Use.

  Similarly to the second embodiment, the client application B 1201b specifies the set permanent ID and calls the method of the application B stub 1202b. Next, the application B stub 1202b calls the Web service library 1203 by adding the permanent ID set by the client application B 1201b to the argument.

  As a result, the Web service library 1203 searches the session information from the session management table 1210 using the permanent ID as a key, adds the acquired session information, sends a SOAP message to the server application 1204, and executes the Web service. Use.

  By performing the above processing, it is possible to use the same session information between different client applications by using the same permanent ID between different client applications.

[Seventh Embodiment]
Next, the seventh embodiment according to the present invention will be described in detail with reference to FIG. In the seventh embodiment, not only the permanent ID set in the sixth embodiment but also the sub ID is set, and the session is managed based on the permanent ID and the sub ID. Here, the sub ID may be anything as long as it is unique for each client application.

  FIG. 13 is a diagram illustrating an example of the configuration of a client-side system that uses a Web service according to the seventh embodiment. FIG. 13 shows only the portion related to the permanent ID, but the overall configuration is the same as the configuration shown in FIG.

  Here, processing when using a Web service from an individual client application will be described. The processing on the client side in the seventh embodiment is the same as that in the fourth embodiment described with reference to FIG. 10, and different processing will be described here.

  First, similarly to the fourth embodiment, the client application A 1301a specifies the set permanent ID and sub ID and calls the method of the application A stub 1302a. Next, the application A stub 1302a calls the Web service library 1303 by adding the permanent ID and sub ID set by the client application A 1301a as arguments.

  As a result, the Web service library 1303 searches the session management table 1310 for session information using the permanent ID and sub ID as keys, adds the acquired session information, and sends a SOAP message to the server application 1304. Web services are used.

  Similarly to the fourth embodiment, the client application B 1301b specifies the set permanent ID and sub ID and calls the method of the application B stub 1302b. Next, the application B stub 1302b calls the Web service library 1303 by adding the permanent ID and sub ID set by the client application B 1301b to the argument.

  As a result, the Web service library 1303 searches the session management table 1310 for session information using the permanent ID and sub ID as keys, adds the acquired session information, and sends a SOAP message to the server application 1304. Web services are used.

  By performing the above processing, by using the same permanent ID and sub ID between different client applications, it is possible to use the Web service using the same session information between different client applications.

[Eighth Embodiment]
Next, an eighth embodiment according to the present invention will be described in detail with reference to FIG. In the eighth embodiment, in addition to the processing in the first and third embodiments, the stub object and the Web service library perform session initialization.

  FIG. 14 is a flowchart showing session initialization processing in the eighth embodiment. The portion surrounded by the solid line is processing by the client application 101, the portion surrounded by the alternate long and short dash line is processing by the stub object 102, and the portion surrounded by the dotted line is processing by the Web service library 103.

  First, in step S1401, the use of the Web service that has been performed as the same session ends, and in order to use the Web service in a new session, the client application 101 sets the URL of the server application, and the stub object 102 is requested to initialize the session.

  Next, in step S1402, the stub object 102 requests the Web service library 103 to initialize the session with the object ID of the stub object and the URL of the server application as arguments.

  Thus, in step S1403, the Web service library 103 first searches the session management table using the object ID of the stub object and the URL of the server application passed in step S1402. In step S1404, it is determined whether session information corresponding to the object ID of the stub object and the URL of the server application exists. If it exists, the process advances to step S1405 to delete the session information from the session management table, and the session initialization process ends. If session information does not exist, the session initialization process is terminated.

  According to the eighth embodiment, in addition to the effects in the first and third embodiments, by initializing the session ID from the client application, the same object can be reused and redundant objects need not be generated. .

[Ninth Embodiment]
Next, a ninth embodiment according to the present invention will be described in detail with reference to FIG. In the ninth embodiment, in addition to the processing in the second and fourth embodiments, the stub object and the Web service library perform session initialization.

  FIG. 15 is a flowchart showing session initialization processing in the ninth embodiment. Note that, in the ninth embodiment, similarly to the eighth embodiment, processing performed by the client application 101, the stub object 102, and the Web service library 103 is divided according to the type of line.

  First, in step S1501, the client application 101 sets an application ID for the stub object 102 in advance. In step S1502, the use of the Web service that has been performed as the same session ends, and in order to use the Web service in a new session, the URL of the server application is set, and the stub object 102 is set. Request session initialization.

  In step S1503, the stub object 102 requests the Web service library to initialize a session using the application ID and the URL of the server application as arguments.

  Thus, in step S1504, the Web service library 103 searches the session management table using the application ID passed in step S1503 and the URL of the server application as keys. In step S1505, it is determined whether session information corresponding to the application ID and the URL of the server application exists. If it exists, the process advances to step S1506 to delete the session information from the session management table, and the session initialization process ends. If session information does not exist, the session initialization process is terminated.

  According to the ninth embodiment, in addition to the effects in the second and fourth embodiments, by initializing the session ID from the client application, the same object can be reused and redundant objects need not be generated. .

  Even if the present invention is applied to a system composed of a plurality of devices (for example, a host computer, an interface device, a reader, a printer, etc.), it is applied to an apparatus (for example, a copier, a facsimile machine, etc.) composed of a single device. It may be applied.

  Another object of the present invention is to supply a recording medium that records software program codes for realizing the functions of the above-described embodiments to a system or apparatus, and the computer (CPU or MPU) of the system or apparatus uses the recording medium as a recording medium. Needless to say, this can also be achieved by reading and executing the stored program code.

  In this case, the program code itself read from the recording medium realizes the functions of the above-described embodiment, and the recording medium storing the program code constitutes the present invention.

  As a recording medium for supplying the program code, for example, a floppy (registered trademark) disk, a hard disk, an optical disk, a magneto-optical disk, a CD-ROM, a CD-R, a magnetic tape, a nonvolatile memory card, a ROM, or the like is used. be able to.

  Further, by executing the program code read by the computer, not only the functions of the above-described embodiments are realized, but also an OS (operating system) operating on the computer based on the instruction of the program code. It goes without saying that a case where the function of the above-described embodiment is realized by performing part or all of the actual processing and the processing is included.

  Further, after the program code read from the recording medium is written in a memory provided in a function expansion board inserted into the computer or a function expansion unit connected to the computer, the function expansion is performed based on the instruction of the program code. It goes without saying that the CPU or the like provided in the board or the function expansion unit performs part or all of the actual processing and the functions of the above-described embodiments are realized by the processing.

It is a figure which shows an example of a structure of the system by which Web service is performed. It is a figure which shows an example of a structure of the system by which Web service is performed using a session management table. It is a figure which shows an example of a structure of the session management table in 1st Embodiment. It is a flowchart which shows the whole process of the Web service in 1st Embodiment. It is a figure which shows an example of a structure of the session management table in 2nd Embodiment. It is a flowchart which shows the whole process of the Web service in 2nd Embodiment. It is a figure which shows an example of a structure of the session management table in 3rd Embodiment. It is a flowchart which shows the whole process of the Web service in 3rd Embodiment. It is a figure which shows an example of a structure of the session management table in 4th Embodiment. It is a flowchart which shows the whole process of the Web service in 4th Embodiment. It is a figure which shows an example of a structure of the session management table list | wrist in 5th Embodiment. It is a figure which shows an example of a structure of the client side system which utilizes the Web service in 6th Embodiment. It is a figure which shows an example of a structure of the client side system which utilizes the Web service in 7th Embodiment. It is a flowchart which shows the session initialization process in 8th Embodiment. It is a flowchart which shows the session initialization process in 9th Embodiment.

Explanation of symbols

101 Client Application 102 Stub Object 103 Web Service Library 104 Communication Library 105 Network 106 Server Application 201 Session Management Table

Claims (10)

A session indicating a logical connection relationship between the client application and the server application by using a session management table that associates and stores session information transmitted and received between the client application and the server application and session management information acquired on the client side A session management method for managing,
Session information retrieval step for retrieving and acquiring session information to be added to a request from the client application to the server application from the session management table based on the session management information;
In the case of storing session information received from the server application, it has a session information storage step of associating the session management information acquired on the client side at the time of a request with the session information and storing it in the session management table. Session management method.   In the session management table, connection destination server information is also stored in association with session information and session management information. In the session information search step, the session management table stores the session management table based on the session management information and the connection destination server information. Session information is retrieved and acquired, and in the session information storage step, the session management information acquired from the client side at the time of the request, the session information, and the connection destination server information are associated and stored in the session management table. The session management method according to claim 1.   The session management method according to claim 1, wherein the session management information is information that is uniquely managed by the session management table.   A unique identifier is set as the session management information, and when information specifying permanent management of the session management information is set, the session information is permanently managed in the session management table. The session management method according to claim 3.   5. Further information for identifying a client application is set in the session management table, and a session is managed for each client application based on the further information. Session management method according to item. Having a user information acquisition step of acquiring information of a user who uses the client application, storing a session management table for each acquired user information
6. The session information search step and the session information storage step search and store the session information in a session management table corresponding to the user information. Session management method according to item.   The session management method according to any one of claims 1 to 6, further comprising a session initialization step of initializing session information corresponding to the specified session management information and connection destination server information. . A session indicating a logical connection relationship between the client application and the server application by using a session management table that associates and stores session information transmitted and received between the client application and the server application and session management information acquired on the client side A session management device to manage,
Session information search means for searching and acquiring session information to be added to a request from the client application to the server application from the session management table based on the session management information;
When storing session information received from the server application, it has session information storage means for associating the session management information acquired on the client side at the time of a request with the session information and storing it in the session management table. Session management device.   A program for causing a computer to execute the session management method according to any one of claims 1 to 7.   A computer-readable recording medium on which the program according to claim 9 is recorded.

Images