Service request apparatus, service request method, service request program product and computer-readable recording medium, service providing apparatus, and service providing method, service providing program product and computer-readable recording medium
A service request apparatus, which includes an application using a service provided by another apparatus by connecting to the another apparatus through a network, determines a communication method to call the service in response to a call request for calling a method with respect to the service, the call request sent from the application, and conducts a remote call of the method in response to the call request from the application based on the communication method.
1. Field of the Invention
The present invention generally relates to service request apparatuses, service request methods, service request program products and computer-readable recording media, service providing apparatuses, service providing methods, and service providing program products and computer-readable recording media, and more particularly to a service request apparatus, a service request method, a service request program product and computer-readable recording medium, which include an application using a service provided by another apparatus connected through a network, and a service providing apparatus, a service providing method, a service providing program product and computer-readable recording medium, which can provide a service by using at least two types of communication methods to the service request apparatus.
2. Description of the Related Art
Recently, application software based on a network environment has been developed. As the application software, a Web service technology is included. The Web service is a technology for associating applications being distributed through the network with each other by using a standard Internet technology. By applying the Web service, it is possible to associate the applications with each other by exchanging data based on an XML (Extensible Markup Language) in accordance with a protocol called a SOAP (Simple Object Access Protocol) on a protocol of a standard Internet such as an HTTP (HyperText Transfer Protocol), an FTP (File Transfer Protocol), an SMTP (Simple Mail Transfer Protocol), and a like. The data exchange is conducted between a Web service client for making a request using a SOAP message and a Web service provider for reading contents of the SOAP message and providing a predetermined function. In the following, referring to
Next, an information exchange between the client apparatus 1 and the service providing apparatuses 22, 33, and 44 in the regular Web service system in
In the following, the information exchange between the client apparatus 1 and the service providing apparatus 22 will be described with reference to
Japanese Laid-open Patent Application No. 2004-46817 discloses a technology related to the above-described information exchange.
It should be noted that the above-described information exchange is not limited to a case between the client apparatus 1 and the service providing apparatus, and may be conducted inside the client apparatus 1.
However, even in a case of exchanging information inside an apparatus, the information is sent and received by the SOAP message as described above. Accordingly, there is a problem in that processes concerning a data conversion and communication are not effectively conducted.
Also, since the SOAP uses an HTTP (HyperText Transport Protocol) on a transport layer, in a point in that the SOAP passes through a firewall and realizes an RPC (Remote Procedure Call), the SOAP is superior to other distribution object technologies. However, the SOAP message is a text base in an XML format. Accordingly, in a case in that it is unnecessary to communicate through the firewall and the SOAP message is used to realize the RPC, the communication by using the SOAP message causes a large overhead amount and is degraded.
SUMMARY OF THE INVENTIONIt is a general object of the present invention to provide service request apparatuses, service request methods, service request program products and computer-readable recording media, service providing apparatuses, service providing methods, and service providing program products and computer-readable recording media, in which the above-mentioned problems are eliminated.
A more specific object of the present invention is to provide a service request apparatus, a service request method, a service request program product and computer-readable recording medium, a service providing apparatus, a service providing method, and a service providing program product and computer-readable recording medium, in that an information exchange for calling a service can be properly conducted in response to a communication environment.
The above objects of the present invention are achieved by a service request apparatus including an application using a service provided by another apparatus by connecting to the another apparatus through a network, the service request apparatus including: determining a communication method to call the service in response to a call request for callinga method with respect to the service, the call request sent from the application; and conducting a remote call of the method in response to the call request from the application based on the communication method.
Moreover, the above objects of the present invention are achieved by a service providing apparatus capable of providing a service by at least two types of communication methods to a service request apparatus, the service providing apparatus includes: conducting a process defined in a method in response to a call request of the method with respect to the service by one of at least the two types of the communication methods; and returning a process request of the process to the service request apparatus based on the communication method concerning the call request, wherein the service request apparatus, which includes an application using a service provided by another apparatus by connecting to the another apparatus through a network, includes: determining the communication method to call the service in response to the call request for calling a method with respect to the service, the call request sent from the application; and conducting the remote call of the method in response to the call request from the application based on the communication method.
According to the present invention, it is possible to conduct the information exchange to call the service properly to the communication environment.
The above objects of the present invention can be achieved by a program for causing a computer to conduct processes described above in the apparatus or by a computer-readable recording medium recorded with the program code.
BRIEF DESCRIPTION OF THE DRAWINGSIn the following, embodiments of the present invention will be described with reference to the accompanying drawings.
In the following, embodiments of the present invention will be described with reference to the accompanying drawings. In the following embodiments, a system includes a client apparatus 1a, and service providing apparatuses 22a, 33a, and 44a, similar to the system shown in
[Client Module]
The client module 10a includes a WS client application 400, and a WS proxy 401. The WS client application 400 functions as a client of a Web service for conducting call requests to core modules 404 and 407, which will be described later, and conducts a determination process concerning the call requests to the core module 404 and 407. The WS client application 400 can be any application which can function as a client of the Web service, such as a Web application passing information to a lower module based on an input from a Web browser (not shown), a special application operating on an operating system such as Windows™, or a like.
The WS proxy 401 is automatically generated from a WSDL (Web Service Description Language), and includes an API (Application Program Interface) for the client module 10a to use the core module 404. When the client apparatus 1a conducts a connection process with the service providing apparatus 22a being an external apparatus, the WS proxy 401 sends a call request created by the WS client application 400 to the service providing apparatus 22a as the SOAP message.
[Service Providing Module]
The service providing module 20a includes a WS listener 402, a Web service 403, and the core module 404. The WS listener 402 parses the SOAP message when the WS listener 402 receives the SOAP message, and converts the SOAP message into a format type in which a lower module can process. The Web service 403 is a part to open a function of a relative core module to the outside. A main logic of this process is mounted to the core module 404, which will be described later. Hence, the Web service 403 itself does not have a special logic, because a method corresponding to the core module 404 is inhibited to be different from process contents of the Web service 403. The core module 404 implements a main logic for conducting a predetermined method in response to a call request from the client module 10a, and also includes a function as a service providing part for returning an execution result to an upper module.
In the first embodiment, the WS client application 400 has a feature of conducting a call process for calling the core module 404 being as a service object by a native call, instead of passing through the WS proxy 401, the WS listener 402, and the Web service 403.
A WS listener 405, a Web service 406, and the core module 407 are of the same configuration as the WS listener 402, the Web service 403, and the core module 404 in the client apparatus 1a, and explanations thereof will be omitted.
Next, process operations of the client apparatus 1a and the service providing apparatus 22a will be described according to the first embodiment of the present invention. The WS client application 400 of the client apparatus 1a starts a call process of a core module, which is to be a call subject, based on a command of a service providing request. The command of the service providing request includes location information to specify a location of the core module being the call subject. When the WS client application 400 determines that the core module being called exists with the WS client application 400, that is, when the WS client application 400 determines that the core module exists in the client apparatus 1a of the WS client application 400, the WS client application 400 conducts the native call to directly call a class method of the core module 404. When the core module 404 is called, the core module 404 returns an execution result of the class method to the WS client application 400.
On the other hand, when the WS client application 400 determines, based on the location information included in the command, that the core module as the call subject does not exist in the client apparatus 1a, the WS client application 400 connects to the service providing apparatus 22a being the external apparatus in the same procedure as a connection process of a regular Web service through the WS proxy 401. That is, the WS proxy 401 converts the command issued from the WS client application 400 into a command in the XML format, stores the command in the XML format in the SOAP envelope, and sends the SOAP message to the service providing apparatus 22a. After the WS listener 405 of the service providing apparatus 22a conducts a type conversion, a method is executed by the core method 407 through the Web service 406. An execution result is sent as the SOAP message to the client apparatus 1a through the WS listener 405. The client apparatus 1a parses the SOAP message by the WS proxy 401, and the execution result of the method is returned to the WS client application 400.
As specific information for the WS client application 400 to specify whether or not the core module being the call subject exists inside the client apparatus 1a, for example, a URI (Uniform Resource Identifier) specifying the core module, an IP address included in the URI, or a like can be used. The specific information is information to include the command created when the WS client application 400 calls the core module, and is used to determine whether or not the core module being the call subject exists in its apparatus. When it is determined whether or not the core module being the call subject exists in the client apparatus 1a, the WS client application 400 conducts a switching process for switching a call process to call the core module as described above, directly accesses the core module 404 of the client apparatus 1a itself by using the native call, and then receives a service conducted by a predetermined function.
By configuring as described above, it is possible to overcome the problems concerning the communication in a case in that the core module being the call subject exists in the client apparatus 1a. Thus, it is possible to call a respective core module without changing a mechanism for conducting a conventional connection process with the external apparatus, and changing an implementation to correspond to a new call process.
Moreover, in a case in that a function provided by the core module is related to document data (information including application data and image data), if a conventional call process for calling the core module existing in the external apparatus is used, it is required to create and store a temporary file used for a data conversion to attach data to the SOAP message as if the SOAP message is sent to the external apparatus, and for an analysis of the SOAP message as if the SOAP message is received to the external apparatus. However, by configuring as described above, the temporary file is not required, and the problems raised in the conventional configuration can be overcome.
In the first embodiment, the WS client application 400 includes a determination logic to determine whether or not the core module being the call subject exists in the client apparatus 1a. The WS client application 400 may be required to consider the determination logic to be implemented in the client apparatus 1a. Accordingly, the following embodiment is provided according to the present invention to solve this problem.
Second Embodiment In the following, a second embodiment will be described with reference to
Different from
A command of the call request of the core module from the WS client application 500 is input to the WS proxy wrapper 501 (step S1), the location of the core module is specified by the WS proxy wrapper 501 (step S2). When a determination result by the WS proxy wrapper 501 shows that the core module being the call subject exists in the client apparatus 1b, that is, when it is determined, based information showing the location of the core module, that the core module exists in the client apparatus 1b (Yes in step S3), the WS proxy wrapper 501 conducts a native call as described in the first embodiment without passing through the WS proxy 502 (step S4). When the core module 505 is called, the core module 505 conducts a process similarly to the core module 404 in the first embodiment, and returns an execution result of a method to the WS client application 500 through the WS proxy wrapper 501.
On the other hand, when a determination result in the step S3 shows that the client apparatus 1b does not implement the core module being the call subject (No in step the S3), the WS proxy wrapper 501 conducts a connection process with an external apparatus through the WS proxy 502 (step S5). Similar to the first embodiment, the WS proxy 502 conducts a general process concerning a SOAP process such as a parsing process for parsing the SOAP message, and calls the core module 508 as the call subject from the service providing apparatus 22b being the external apparatus (step S6). Thus, a result of a predetermined process conducted by the core module 508 is sent as the SOAP message. After the WS proxy 502 parses the SOAP message received from the service providing apparatus 22b, the execution result of the method is returned to the WS client application 500 through the WS proxy wrapper 501.
As described above, in the second embodiment, the WS proxy wrapper 501 determines whether or not the core module being the call subject exists in the client apparatus 1b. Advantageously, the WS client application 500 is not required to consider and implement the determination logic. If the client apparatus 1b implements a plurality of the WS client applications 500, the WS proxy wrapper 501 can be shared with the plurality of the WS client applications 500 to conduct the call process. Advantageously, each of the WS client applications 500 is not required to include a similar determination logic.
In the first embodiment and the second embodiment, calls from the WS client application 400 and 500 are classified into the native call and a call (remote call) through the network 3a or 3b, and the process concerning the native call is described to effectively realize.
An architecture in order to realize a remote call in a distribution object technology is not limited to the Web service using the SOAP. For example, an EJB (Enterprise JavaBeans™) realized by Java™ can be used for the architecture. As one of advantages to use the SOAP, the SOAP can pass through a firewall and realize the remote call. Accordingly, the SOAP is suitable to realize the remote call in a communication environment of communicating through the Internet. On the other hand, if the SOAP is used to realize the remote call in a network system using the firewall, it becomes inefficient because of a specification of the SOAP message. That is, the SOAP message is formed by a message in a test base using the XML, and the size of data becomes greater. Thus, the SOAP message is likely to increase a communication quantity. The following embodiment is provided to solve this problem.
Third Embodiment
In
The remote client wrapper 601 determines whether or not to call the SOAP or the EJB for a request the application 600 to the core module 607, and then calls the core module in accordance with a call method (communication method) in response to a determination result.
For example, as one of methods provided from the remote client wrapper 601 to the application 600, the following:
UserList userList=getUserList( ); Can be considered. When this method is called from the application 600, and the SOAP is used to call this method with respect to the service providing apparatus 22, a response in an XML format as shown in
Also, when the method is called with respect to the service providing apparatus 22c by the EJB, the remote client wrapper 601 conducts a process based on a source code as shown in
That is, the remote client wrapper 601 takes a difference between protocols or between the distribution object architectures, into the remote client wrapper 601 itself, and provides a common interface which can be shared with any application 600. Thus, the application 600 can make a request to the core module 607 without considering the difference between the protocols, or the like.
The SOAP client 602 functions as a client to make the remote call by the SOAP, and exchanges the SOAP message between the SOAP client 602 and the SOAP interface 605 of the service providing apparatus 22c. The EJB client 603 functions as a client to make the remote call by the EJB, and communicates with the EJB interface 606 of the service providing apparatus 22c to make the remote call.
On the other hand, in the service providing apparatus 22 in
The EJB interface 606 interprets the remote call by the EJB from the client apparatus 1c, and calls the method of the core module 607 corresponding to the remote call. That is, the service providing apparatus 22c can provide the function of the core module 607 in response to the remote call based on two types of communication methods such as the SOAP and the EJB.
In the following, process procedures of the client apparatus 1c and the service providing apparatus 22c in
When the remote client wrapper 601 receives a call request with respect to the core module 607 by receiving an indication indicating an identification name (for example, a method name) of a call-method and a server URI (Uniform Resource Identifier) of a call destination from the application 600 (step S11), the remote client wrapper 601 obtains the communication method (SOAP or EJB) for the service URI indicated by the call request from the communication method definition DB 604 (step S12).
Accordingly, the remote client wrapper 601 determines the communication method to communicate with the server being the call destination to call the method based on the server URI, by referring to the communication method definition DB 604 (step S13).
When the communication method for the server URI is set to be the SOAP (SOAP in step S13), the remote client wrapper 601 converts the call information concerning the call-method into a SOAP request format described in the XML format (step S14), and sends the call information (SOAP message) concerning the call-method with respect to the core module 607 through the SOAP client 602 (step S15).
When the communication method for the server URI is set to be the EJB (EJB in step S13), the remote client wrapper 601 converts the call information concerning the call-method into an EJB request format (step S16), and sends the call information concerning the call-method with respect to the core module 607 to the service providing apparatus 22c through the EJB client 603 (step S17).
On the other hand, when there is no record corresponding to the server URI (not listed in the step S13), the remote client wrapper 601 obtains a default communication method from the communication method definition DB 604 (step S18), and calls the call-method by the default communication method (step S19). That is, when the default communication method is defined as the SOAP, processes as the same as the step S14 and the step S15 are conducted (step S19). On the other hand, when the default communication method is the EJB, processes as the same as the step S16 and the step S17 are conducted in the step S19.
Consequently, the remote client wrapper 601 determines whether or not the call-method is successfully called by the default communication method (step S20). This determination process may be conducted based on whether or not a return value is normally obtained from the call-method in response to the call. When the call is successfully conducted by the default communication method (Yes in the step S20), the remote client wrapper 601 registers the default communication method by associating with the server URI, which is not registered when the call is made, into the communication method definition DB 604 (step S21). Accordingly, from a next call, the remote client wrapper 601 directly obtains the communication method for the server URI from the communication method definition DB 604.
On the other hand, when the default communication method fails to call the call-method (No in the step S20), the remote client wrapper 601 attempts to call by another communication method other than the default communication method (step S22). That is, when the default communication method is the EJB, the call-method is called by the SOAP.
When the call is successfully conducted by the another communication method (Yes in step S23), the remote client wrapper 601 registers the another communication method to the communication method definition DB 604 by associating with the server URI (in the step S21). On the other hand, when the another communication method fails to call the call-method (No in the step S23), the remote client wrapper 601 returns an error to the application 600.
Next, the process procedure at the service providing apparatus 22c being the call destination to call the call-method by the SOAP or the EJB will be described.
When the communication method is the SOAP (that is, when the call-method is called by the SOAP) (SOAP in step S31), the SOAP interface 605 receives the call information (SOAP message) in accordance with the SOAP (step S32), and calls the call-method of the core module 607 based on the SOAP message (step S33).
On the other hand, when the communication method is the EJB (that is, when the call-method is called by the EJB) (EJB in the step S31), the EJB interface 606 receives the call information in accordance with the EJB (step S34), and calls the call-method of the core module 607 based on the call information (step S35).
When the call-method is called to the core module 607, the core module 607 conducts a process defined in the call-method, and returns a process result to a caller (the SOAP interface 605 or the EJB interface 606) (step S36).
When the communication method is the SOAP (SOAP in step S37), the SOAP interface 605 converts the process result returned from the core module 607 into a SOAP response format (step S38), and sends a SOAP response to the SOAP client 602 of the client apparatus 1c (step S39).
On the other hand, when the communication method is the EJB (EJB in step S37), the EJB interface 606 converts the process result returned from the core module 607 into an EJB response format (step S40), and sends an EJB response to the EJB client 603 (step S41).
Subsequently, the process procedure of the client apparatus 1c receiving a response from the service providing apparatus 22c will be described.
When the communication method is the SOAP (that is, when the call-method is called by the SOAP) (SOAP in step S51), the SOAP client 602 receives the SOAP response from the SOAP interface 605 of the service providing apparatus 22c (step S52), the SOAP client 602 returns the SOAP response to the remote client wrapper 601 (step S53). The remote client wrapper 601 receiving the SOAP response converts the SOAP response into an interface format (for example, an interpretable format for the application 600 such as a C language structure) provided to the application 600 (step S54), and returns a converted process result to the application 600 (step S58).
On the other hand, when the communication method is the EJB (that is, when the call-method is called by the EJB) (EJB in the step S51), the EJB client 603 receives the response by the EJB from the EJB interface 605 of the service providing apparatus 22c (step S55), and returns the response to the remote client wrapper 601 (step S56). When the remote client wrapper 601 receives the response by the EJB, the remote client wrapper 601 converts the response into the interpretable format for the application 600 (step S57), and returns a converted process result to the application 600 (step S58).
As described above, according to the third embodiment, the client apparatus 1c can utilize a function of the service providing apparatus 22c by any one of remote calls by the SOAP passing through the firewall and by the EJB, which has higher process efficiency than the SOAP but cannot always pass through the firewall. Accordingly, with respect to the remote call within the firewall, the function of the core module 607 can be effectively utilized by using the EJB.
In the third embodiment, the EJB is exemplified as a higher speed remote call method than the SOAP, but for example, an RMI (Remote Method Invocation™) being a lower lever than the EJB can be used. Alternatively, other architectures or other protocol such as a DCOM (Distributed COM), CORBA (Common Object Request Broker Architecture), and a like can be used.
According to the present invention, it is possible to conduct the information exchange to call the service properly to the communication environment.
The present invention is not limited to the specifically disclosed embodiments, and variations and modifications may be made without departing from the scope of the present invention. For example, the above-described processes according to the present invention can be achieved by a program for causing a computer to conduct processes described above in the apparatus or by a computer-readable recording medium recorded with the program code.
The present application is based on the Japanese PriorityApplications No. 2004-231417 filed on Aug. 6, 2004 and No. 2005-216003 filed on Jul. 26, 2005, the entire contents of which are hereby incorporated by reference.
Claims
1. A service request apparatus including an application using a service provided by another apparatus by connecting to the another apparatus through a network, the service request apparatus comprising:
- determining a communication method to call the service in response to a call request for calling a method with respect to the service, the call request sent from the application; and
- conducting a remote call of the method in response to the call request from the application based on the communication method.
2. The service request apparatus as claimed in claim 1, wherein the call request of the method with respect to the service from the application includes information indicating a method identification name and a URI specifying the service.
3. The service request apparatus as claimed in claim 1, wherein the communication method to call the service is determined based on communication method definition information in which the communication method to call the service is defined for each service.
4. The service request apparatus as claimed in claim 3, wherein the remote call is made based on a default communication method when the communication method to call the service is not defined in the communication method definition information.
5. The service request apparatus as claimed in claim 4, wherein the remote call is made based on another communication method when the remote call in accordance with the default communication method fails.
6. The service request apparatus claimed in claim 4, wherein when the communication method to call the service is not defined in the communication method definition information and the remote call succeeds by the default communication method, the default communication method used for the remote call is registered to the communication method definition information by associating with the service.
7. The service request apparatus as claimed in claim 1, wherein return information returned from another apparatus in response to the remote call is converted into an interpretable format for the application from a format based on the communication method.
8. The service request apparatus as claimed in claim 1, wherein at least one communication method is a first communication method possible to pass through a firewall, and at least one communication method is a second communication method being higher than the first communication method.
9. The service request apparatus as claimed in claim 8, wherein the first communication method is a communication method using a structural description language.
10. The service request apparatus as claimed in claim 9, wherein the structural description language includes an extensible markup language.
11. The service request apparatus as claimed in claim 8, wherein the second communication method is a communication method using Enterprise JavaBeans™ or Remote Method Invocation™.
12. A service providing apparatus capable of providing a service by at least two types of communication methods to a service request apparatus, the service providing apparatus comprising:
- conducting a process defined in a method in response to a call request of the method with respect to the service by one of at least the two types of the communication methods; and
- returning a process request of the process to the service request apparatus based on the communication method concerning the call request,
- wherein the service request apparatus, which includes an application using a service provided by another apparatus by connecting to the another apparatus through a network, comprises:
- determining the communication method to call the service in response to the call request for calling a method with respect to the service, the call request sent from the application; and
- conducting a remote call of the method in response to the call request from the application based on the communication method.
13. The service providing apparatus as claimed in claim 12, wherein at least one communication method is a first communication method possible to pass through a firewall, and at least one communication method is a second communication method being higher than the first communication method.
14. The service providing apparatus as claimed in claim 13, wherein the first communication method is a communication method using a structural description language.
15. The service providing apparatus as claimed in claim 14, wherein the structural description language includes an extensible markup language.
16. The service providing apparatus as claimed in claim 13, wherein the second communication method is a communication method using Enterprise JavaBeans™ or Remote Method Invocation™.
17. A service request method conducted in a service request apparatus including an application using a service provided by another apparatus by connecting to the another apparatus through a network, the service request method comprising:
- determining a communication method to call the service in response to a call request for calling a method with respect to the service, the call request sent from the application; and
- conducting a remote call of the method in response to the call request from the application based on the communication method.
18. A service providing method conducted in a service providing apparatus capable of providing a service by at least two types of communication methods, the service providing method comprising:
- conducting a process defined in a method in response to a call request of the method with respect to the service by one of at least the two types of the communication methods; and
- returning a process request of the process to the service request apparatus based on the communication method concerning the call request.
19. A service request program product for causing a computer to use a service provided by another apparatus connected through a network, the service request program product comprising:
- determining a communication method to call the service in response to a call request for calling a method with respect to the service, the call request sent from the application; and
- conducting a remote call of the method in response to the call request from the application based on the communication method.
20. A service providing program product for causing a computer to provide a service by at least two types of communication methods, the service providing program product comprising:
- conducting a process defined in a method in response to a call request of the method with respect to the service by one of at least the two types of the communication methods; and
- returning a process request of the process to the service request apparatus based on the communication method concerning the call request.
21. A computer-readable recording medium recorded with a service request program for causing a computer to use a service provided by another apparatus connected through a network, the service request program comprising:
- determining a communication method to call the service in response to a call request for calling a method with respect to the service, the call request sent from the application; and
- conducting a remote call of the method in response to the call request from the application based on the communication method.
22. A computer-readable recording medium recorded with a service providing program for causing a computer to provide a service by at least two types of communication methods, the service providing program comprising:
- conducting a process defined in a method in response to a call request of the method with respect to the service by one of at least the two types of the communication methods; and
- returning a process request of the process to the service request apparatus based on the communication method concerning the call request.
Type: Application
Filed: Aug 4, 2005
Publication Date: Feb 23, 2006
Patent Grant number: 7624404
Inventor: Atsuko Yagi (Kanagawa)
Application Number: 11/196,620
International Classification: G06F 9/46 (20060101);