DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0042] FIG. 2 shows a web services infrastructure 201 in accordance with an embodiment of the present invention. The web services infrastructure 201 comprises client applications 15 , web service providers 20 , a gateway module 300 , client application connections 31 to the gateway module 300 , and web service connections 32 to the gateway module 300 . More or fewer client applications 15 , web services 25 , and their respective connections 31 , 32 , may exist in the web services infrastructure 201 .

[0043] The client applications 15 may be end user applications 10 , other web service providers 20 , or any application which requests access to a web service 25 . Some client applications 15 may be used by client application developers to obtain a web service application programming interface (API) contract to develop other client applications 15 that will consume or use that particular web service 25 . Each client application 15 has a client application connection 31 . Client application connections 31 may be any suitable connection that allows the transfer of information between the client application 15 and the gateway module 300 . The web service providers 20 have web services WS 1 to WSx, WS 1 to WSy, and WS 1 to WSz, where x, y, and z are integers greater than zero. The web services 25 may be different for each web service provider 20 . Each web service 25 has a web service connection 32 to the gateway module 300 . Web service connections 32 may be any suitable connection that allows the transfer of information between the web services 25 and the gateway module 300 . The gateway module 300 is an application that adds common and additional functionality, as will be described below, to any web service 25 registered with the gateway module 300 . The gateway module 300 remains transparent to the client application 15 and the web service 25 . Web services 25 are registered with the gateway module 300 as described below. In this description, clients may sometimes be referred to as users, consumers, and/or end users.

[0044] FIG. 3 shows an example of a gateway module 300 in accordance with an embodiment of the present invention. The gateway module 300 comprises a client application interface unit 310 , a communication processor 311 and a web services interface unit 312 . These components of the gateway module 300 comprise code that may be executed as software or embedded in hardware. The client application interface unit 310 receives web services requests coming from a client application connection 31 (shown in FIG. 2 ) connecting a client application 15 (shown in FIG. 2 ) with the gateway module 300 . The client application interface unit 310 sends web services requests to the communication processor 311 . The communication processor 311 determines which web service 25 is being requested and sends the web service request to the web services interface unit 312 . The web services interface unit 312 sends the web service request to the appropriate web service 25 through the web service connection 32 (shown in FIG. 2 ) connecting that web service 25 with the gateway module 300 . Other components may be added to the gateway module 300 as described below.

[0045] Alternatively, the gateway module 300 may not include a client application interface unit 310 , whereby the function of the client application interface unit 310 is performed by either the communication processor 311 or an external module. Parts of the remainder of this application will refer to a gateway module 300 containing a client application interface unit 310 . However, the client application interface unit 310 may be removed, and the communication processor 311 modified, as described above.

[0046] As is described above, the gateway module 300 may be used by both client application developers and client application users. When developing client applications 15 that may use a web service 25 , client application developers may use the gateway module 300 to obtain a web service API contract from a web service 25 . When a client application 15 is used by a client application user, the client application 15 may use the gateway module 300 to send a method call to a web service. Some method calls instruct a web service to perform a task. Some method calls instruct a web service to return an item or response. The web service 25 may use the gateway module 300 to return an item or response to the client application 15 .

[0047] FIG. 4 shows a method for managing functionality for one or more web services 25 ( 400 ) in accordance with an embodiment of the present invention. The method ( 400 ) begins with receiving a web service request from a client application 15 ( 401 ). This step may be performed by the client application interface unit 310 , or the communication processor 311 as described above. Next, the web service request is processed ( 402 ). This step may be performed by the communication processor 311 . Finally, the web service request is delegated to the appropriate web service 25 ( 403 ). This step may be performed by the web services interface unit 312 . Once the appropriate web service 25 has the web service request ( 403 ), the method is done ( 404 ). Further steps may be added to this method ( 400 ) as described below.

[0048] An aspect of an embodiment of the gateway module 300 pertains to the field of distributed computing, where software running on a client system interacts with software running on remote server systems. More specifically, where the software running on a server has been developed such that its capabilities can be discovered programmatically using the tools based on a standard network protocol based on a standard language. An example of a standard network protocol is the Internet protocol known as simple object access protocol (SOAP), which is itself based on the standard extensible markup language (XML). The actual data transmitted between the client application 15 used by client application user and the server code may be transmitted via SOAP. The server functionality is typically referred to as web services. A typical client application 15 may be either a web browser or an Internet-aware application. The following description refers mainly to SOAP communication, but the gateway module 300 may be used with other standard protocols based on a standard language.

[0049] FIG. 5 shows another example of a web services infrastructure 501 in accordance with an embodiment of the present invention. The web services infrastructure 501 comprises client applications 15 , client application connections 31 , a gateway module (or gateway module) 500 , web services WS 1 , WS 2 and WS 3 , and web service connections 32 . More or fewer client applications 15 , web services 25 , and their respective connections 31 and 32 may exist in the web services infrastructure 501 . The gateway module 500 comprises a client application interface unit 310 , a communication processor 311 , a web services interface unit 312 , an authentication module 520 , an authorization module 525 , and a web service registry repository 530 . The gateway module 500 is a centralized access point for client applications 15 to connect to web services 25 . The authentication module 520 and the authorization module 525 may alternatively be contained in a combined authentication and authorization module. Other components may be added to the gateway module 500 , as described below.

[0050] The client application interface module 310 may operate on hypertext transfer protocol (http) and SOAP. The communication processor 311 and the web services interface unit 312 may be similar to those described above referring to FIG. 3 . The authentication module 520 and the authentication module 525 may comprise code for authenticating and authorizing a client application 15 . The web service repository 530 is a centralized registry of web services being exposed. It may store a unique identifier (ID) of the web service 25 , its location, an API contract request string, and a brief description, all of which is mapped to the web service's unique name or uniform resource identifier (URI).

[0051] The gateway module 500 is an application that sits between client applications 15 and the web services 25 being consumed, intercepting communication between them. Some communication between client application 15 and web service 25 occurs over the SOAP protocol, while some communication includes the exchange of an API contract description, such as a web service description language (WSDL) contract document. The gateway module 500 acts as a SOAP processor with respect to communication between a web service 25 and a client application 15 used by a client application user. Furthermore, the gateway module 500 acts as an API contract (for example, WSDL) processor with respect to communication between a web service 25 and a client application 15 used by a client application developer. Therefore, the gateway module 500 transparently alters both the way the client application 15 calls the web service 25 , and how the web service 25 appears to the client application 15 without either party being aware of the gateway module 500 .

[0052] FIG. 6A shows another example of a method for managing functionality for one or more web services 25 ( 600 ) in accordance with an embodiment of the present invention. This example relates to a client application user. To request the use of a web service 25 , a client application 15 sends a SOAP based method call through the client application connection 31 . The client application interface unit 310 receives the method call ( 601 ) and passes the method call to the communication processor 311 . The communication processor 311 determines which web service 25 is associated with the method call. The method call is then passed to the authentication module 520 to authenticate the method call as coming from the client application 15 ( 602 ). The method call is passed back to the communication processor 311 . If the client application is authentic ( 602 ), then the method call is passed to the authorization module 525 to determine if the client application 15 has authorization to use the requested web service 25 ( 603 ). The method call is passed back to the communication processor 311 . If the client application is not authentic ( 602 ), then the method call is rejected ( 609 ). If the client application 15 is not authorized to use the method in the web service 25 ( 603 ), then the method call is rejected ( 610 ). A rejected method call may be returned back to the client application 15 through the corresponding client application connection 31 . The rejection may include an error message explaining why the method call is rejected. Alternatively, a rejected method call may be ignored and the corresponding client application connection 31 closed. If a method call is rejected ( 609 ) or ( 610 ), the method is done ( 611 ).

[0053] If the client application 15 does have authorization ( 603 ), then the method call is passed to the web services interface unit 312 . The web services interface unit 312 searches the web service registry repository 530 to determine the location of the requested web service 25 ( 604 ). The web service registry repository 530 provides a mapping from the identity of the web service (a URI) to the physical location of the web service 25 and any other attributes of the web service 25 that are desirable to assist the gateway module 500 to interpret, process, and make actual requests or method calls of said web service 25 . Once the location of the web service 25 is determined ( 604 ), the method call is delegated to the web service 25 via the corresponding web service connection 32 ( 605 ).

[0054] If the method call does not have a corresponding response ( 606 ), then the method is done ( 610 ). Otherwise, the web services interface unit 312 receives a corresponding response from the web service 25 ( 607 ), in response to the method call. The web services interface unit 312 passes the response to the communication processor 311 to be passed back to the client application interface unit 310 . The client application interface unit 310 sends the response through the appropriate client application connection 31 to the client application 15 from which the method call originated ( 608 ). The method is done ( 611 ).

[0055] FIG. 6B shows another example of a method for managing functionality for one or more web services 25 ( 620 ) in accordance with an embodiment of the present invention. This example also relates to a client application user. To request the use of a web service 25 , a client application 15 calls an authentication method through the client application connection 31 . The authentication method call contains the client application credentials such as user name and password. The client application interface unit 310 receives the authentication method call ( 621 ) and passes the authentication method call to the authentication module 520 to authenticate the client application credentials ( 622 ). If the credentials are authentic ( 622 ), i.e., the client application is registered with the gateway module 500 , then the authentication module 520 issues an authentication identifier (ID) ( 523 ) and passes the authentication ID to the client application interface unit 310 to pass to the client application 15 . If the credentials are not authentic ( 622 ), then the authentication call is rejected ( 631 ) and the method is done ( 633 ). Alternatively, the authentication module 520 issue an error response to be sent to the client application 15 .

[0056] An issued authentication ID may be passed as a parameter with subsequent web service method calls invoked by the client application 15 . The client application interface unit 15 receives a web service method call ( 624 ) and passes the method call to the communication processor 311 . The communication processor 311 determines which web service 25 is associated with the method call. The method call is then passed to the authorization module 525 to determine if the client application 15 associated with the authentication ID is authorized to use the method call in the web service 25 ( 625 ). For example, authorized client applications 15 for methods in web services 25 may be listed in a repository. If the client application 15 is not authorized to use the method call ( 625 ), then the method call is rejected ( 632 ) and the method is done ( 633 ).

[0057] If the client application 15 is authorized to use the method call ( 625 ), then the method call is passed to the communication processor 311 to be processed ( 626 ), i.e., prepared to be delegated to the web service 25 . The authentication ID parameter is removed from the method call and the modified method call is passed to the web service interface unit 312 . The web services interface unit 312 searches the web service registry repository 530 to determine the location of the requested web service 25 , as described above. The method call is delegated to the web service 25 via the corresponding web service connection 32 ( 627 ).

[0058] If the method call does not have a corresponding response ( 628 ), then the method is done ( 633 ). Otherwise, a response is received from the web service 25 ( 629 ) and sent to the client application 15 ( 630 ), as described above. The method is done ( 633 ).

[0059] FIG. 6C shows another example of a method for managing functionality for one or more web services 25 ( 650 ) in accordance with an embodiment of the present invention. This example relates to a client application developer. To request an API of a web service 25 , a client application 15 sends an API request method call (API request) through the client application connection 31 . The client application interface unit 310 receives the API request and passes the API request to the communication processor 311 ( 651 ). The communication processor 311 determines which web service 25 is associated with the API request. The API request is then passed to the web services interface unit 312 . The web services interface unit 312 searches the web service registry repository 530 to determine the location of the requested web service API ( 652 ). The web service registry repository 530 provides a mapping from the web service 25 URI to the physical location of the web service 25 and any other attributes of the web service 25 that are desirable to assist the gateway module 500 to interpret, process, and make actual requests or method calls of said web service 25 . Once the location of the web service 25 is determined ( 652 ), the API request is delegated to the web service 25 via the corresponding web service connection 32 ( 653 ).

[0060] The web services interface unit 312 receives the requested web service API contract from the web service 25 ( 654 ) in response to the API request. The web services interface unit 312 passes the API contract to the communication processor 311 to be passed back to the client application interface unit 310 . The client application interface unit 310 sends the response through the appropriate client application 31 to the client application 15 from which the API request originated ( 655 ). The method is done ( 656 ). Alternatively, the method may include access restriction measures such as requirements for authentication and/or authorization, as described above with respect to web service method calls.

[0061] The gateway module 500 is transparent to the client application 15 and the web services 25 . The gateway module 500 processes communication between client application 15 and web service 25 . In the case of a client application developer, a single entry point, i.e., a single address, is exposed for client application developers to retrieve a web service API contract document, such as WSDL. WSDL contains a port, which is a single address in which to bind a client application 15 . A WSDL returned by normal web services 25 contains its own address. Hence if a client application 15 has ten web services, the client application 15 will require ten addresses to connect to these web services 25 (as depicted in FIG. 1 ). An API contract processor in the communication processor 311 , such as a WSDL processor, replaces this port address with the address of the gateway module 500 before returning the WSDL back to the client application developer. This ensures that the client application 15 that will be created by the client application developer will send its SOAP requests to the address that is associated with the client application interface unit 310 . Subsequent SOAP requests sent by the client application 15 are received by the client application interface unit 310 and delegated to a web method call processor, such as a SOAP processing module, in the communication processor 311 .

[0062] Two scenarios are described above: A) requests from a client application user (method calls over SOAP); and B) requests from a client application developer for the API contract (WSDL). In scenario A, the gateway module 500 acts as a SOAP processor. Scenario A occurs over the SOAP protocol whenever a method of the web service 25 is invoked. In scenario B, the gateway module acts as an API contract (WSDL) processor. Scenario B does not occur over SOAP and occurs during the design/development time of the client application 15 consuming the web service 25 . In both scenarios, there may be two areas of processing: i) the processing of the request before the request is forwarded to the web service 25 ; and ii) if there is a response, the processing of the response before it is returned to the client application 15 .

[0063] This description contains references to login and logon procedures. The embodiments of the inventions described in this specification apply to both login and logon procedures. A login reference is intended to include a logon reference and vice versa.

[0064] A client application user or client application developer may call a Login method, passing his/her credentials, through the use of a client application 15 . The credentials may be authenticated and a list of web services 25 to which the client application 15 is authorized to access may be established and stored in a repository. After authenticating the credentials, the gateway module 500 returns an authentication ID to be passed with every method call. Advantageously, this simplifies the authentication and authorization checking steps in the management of web service 25 functionality. The use of authentication IDs will be described further below.

[0065] In order to achieve the transparency described above, client application developers may use parameters added to and/or modified from existing parameters to method calls of web services 25 API contract. These extra and/or modified parameters are created by an administrator or developer of the gateway module 500 and assist the gateway module 500 to distinguish method calls from one client application 15 from method calls of another client application 15 . Furthermore, the extra and/or modified parameters assist in other administrative functions such as classification and storage of the web service 25 method calls, and storage of authentication IDs. The API contract request method may also include extra parameters. The areas of processing referred to above relate to i) transformations between the method call received from the client application 15 and the method call passed to the web service; and ii) transformations between the response, if any, received from the web service and the response passed to the client application 15 .

[0066] FIG. 7A shows a depiction 701 of the web services infrastructure 501 as a SOAP processor in accordance with an embodiment of the present invention. A client application 15 (such as an end user application used by a client application user) invokes a SOAP method call (client call) 701 . The client call 701 is received by the gateway module 500 , as described above. The client call 701 is modified by a SOAP processor of the communication processor 311 of the gateway module 500 . The modification here may include the removal of an extra parameter which was added to the web service SOAP method call by the client application developer. Thus the modification translates the client call 701 into the actual web service SOAP method call (WS call) 702 understood by the web service 25 . The WS call 702 is sent by the gateway module 500 to the web service 25 , as described above.

[0067] The gateway module 500 receives a web service SOAP response (WS response) 703 from the web service 25 , as described above. The SOAP processor of the communication processor 311 translates the WS response 703 into a SOAP based response (client response) 704 that the client application 15 will understand. The translation may be the addition or modification of a parameter in the WS response. The gateway module 500 then sends the client response 704 to the client application 15 , as described above.

[0068] The ability to act as a SOAP processor allows the functionality of the web services 25 to be better managed. Since the web services infrastructure 501 is listening to SOAP communication between client 15 and web service 25 , the web services infrastructure 501 has the information to determine what methods 701 are being called, under what conditions and even by whom, provided that identification information was given by the caller. Furthermore, the web services infrastructure 501 is able to check authentication, authorization, and/or billing information and determine if the method call should be allowed to proceed to the service. When the response from the web service 25 returns, the web services infrastructure 501 is then able to update any relevant billing or audit information, as described below. In general the web services infrastructure 501 can perform infrastructure functions common to the related web services 25 because the web services infrastructure 501 is privy to the information passed from client application 15 to web service 25 .

[0069] FIG. 7B shows a depiction 750 of the web services infrastructure 501 as an API contract processor in accordance with an embodiment of the present invention. A client application 15 (such as a programmer application used by a client application developer) may make a method call (developer call) 751 requesting the API contract of a web service 25 . The developer call 751 is received by the gateway module 500 , as described above. The developer call 751 is modified by an API contract processor of the communication processor 311 of the gateway module 500 . The modification here may include the removal of an extra parameter which was added to the API contract method call. Thus the modification translates the developer call 751 into the actual API contract method call (API call) 752 understood by the web service. For example, an HTTP GET request method call may be used to obtain a web service API contract. The API call 752 is sent by the gateway module 500 to the web service 25 , as described above.

[0070] In response to the API call 752 , the gateway module 500 receives an API contract (for example, WSDL) 753 from the web service 25 as described above. The API contract processor of the communication processor 311 translates the WSDL 753 into a modified WSDL 754 that the client application developer will use. The translation may be the addition or modification of a parameter in the WSDL 753 , such as the modification of an address, as described above. The gateway module 500 then sends the modified WSDL 754 to the client application 15 , as described above.

[0071] By modifying the API contract (WSDL) 753 as it is delivered from the web service 25 to the client application 15 , the web services infrastructure 501 is able to enforce the requirement of the consuming client application developer to insert parameters into any or all method calls in that web service 25 . This allows the newly developed client application 15 to believe the added or amended parameters are part of the web service 25 method being invoked while the web service 25 is not even aware that parameters exist. When the new client application 15 calls the method 701 , the SOAP processor in the gateway module 500 strips out the extra parameters, performs any processing required, and passes the SOAP message (minus the extra parameters) 702 onto the web service 25 . For example, the web services infrastructure 500 can receive and process a user identifier parameter which allows for the association of method calls 701 , 702 to a given client application 15 and all of the authorization and billing information appropriate for that client application 15 . The web services 25 are not concerned with the identifier and the identifier need not be a parameter for any of their methods 702 . From the client application 15 point of view, however, the methods 701 use this parameter.

[0072] FIG. 8 shows an example of a modification to an API contract through the gateway module 500 in accordance with an embodiment of the present invention. A web service API contract 753 may contain many method calls, i.e., WS calls 702 . As an example, FIG. 8 shows a web service WS 1 API contract 753 as containing 50 WS calls 702 . Three examples of WS calls 702 given in FIG. 8 include:

[0073] method1(string param1, int param2, MyType param3);

[0074] method2(char param1, MyType param2); and

[0075] method 3( ).

[0076] FIG. 8 also depicts the modified web service WS 1 API contract 754 as seen by the client application 15 with method calls, i.e., client calls 701 , that contain an additional parameter “gparam1” of type “AuthID”. For example, this additional parameter may be an identifier that the client application 15 is authorized to use the method in the web service 25 . In this example, the additional parameter is placed as the first parameter to all client calls 701 . Other parameters may be added to the client calls 701 . Thus, the three corresponding examples of client calls 701 in the client application 15 are:

[0077] method1(AuthID gparam1, string param1, int param2, MyType param3);

[0078] method2(AuthID gparam1, char param1, MyType param2); and

[0079] method3(AuthID gparam1).

[0080] Additionally, if it is a requirement for a web service 25 to have certain parameter types converted to other types (from the perspective of the client caller), these parameters, along with the associated target types, and the conversion method would be described in the web service registry 530 , or an additional table indexed off of the web service registry 530 .

[0081] By modifying the API contract, the gateway module 500 can make it appear that any web service 25 has any set of methods as desired, regardless of what methods the service actually implements. As long as calls to these methods are honored somewhere inside of the web services infrastructure 501 , it appears to the client application 15 as though the client method was really implemented by the web service 25 . The web service 25 remains unaware that the client method exists let alone that the separate client call 701 was made. In general the web services infrastructure 501 is able to dynamically modify the methods that would appear to be offered by a web service 25 ; even adding methods that might have a central implementation somewhere inside of the web services infrastructure. For example, for more convenient calling on the client side, the web service provider 20 may add a DoMethod( ) method that takes an enumeration of the methods offered by a given web service 25 to each web service 25 it offers.

[0082] In similar ways that extra methods can be added to a given web service 25 , new virtual services can be composed of methods from various other web services 25 using the infrastructure 501 . By creating a complete API contract 753 for a virtual service that does not really exist, the infrastructure 501 can then route the client calls 701 made to said virtual service methods to the real web services 25 that implement the WS methods 702 . These virtual services could be composed by a system administrator through an application that interfaces with the infrastructure's databases.

[0083] Again, through modification of the API contract 753 whenever it is requested, the gateway module 500 is able to make it appear that a web service 25 resides at any virtual location. By ensuring that the WSDL processor of the gateway module 500 intercepts references to the web service 25 at this virtual location, the gateway module 500 can then route the call to one of the physical locations where it actually exists. When a web service 25 changes its physical location, it is just a matter of updating the data table in the web service registry repository 530 that indicates its location to the gateway module 500 . The original entry in the web service registry repository 530 may be created through a gateway module system administration application when a web service 25 is registered with the gateway module 500 . Clients need not even be aware that the web service 25 has moved.

[0084] FIG. 9 shows another example of a gateway module 900 in accordance with an embodiment of the present invention. The gateway module 900 includes a client application interface unit 310 , a communication processor 311 , a web services interface unit request dispatcher, 312 , a web services registry repository 530 , a metering module 950 , a web method call processor 960 , a web service API contract processor 965 , a billing module 970 , and a login services module 980 . The login services module comprises an authentication module 520 , an authorization module 525 , an authentication identifier (ID) provider 940 , and an authentication ID validator 945 . Components may be added to or removed from the gateway module 900 .

[0085] The client application interface unit 310 , communication processor 311 , web services interface unit 312 , authentication module 520 , authorization module 525 , and web services registry repository 530 may be similar to those described above. The metering module 950 keeps track of the usage of web service client call 701 methods for the specific client application 15 , including the number of client calls 701 made and amount of server resource consumed. The web method call processor 960 comprises code to perform the modifications to the method calls 701 , 702 and responses 703 , 704 described above. The web method call processor 960 may be a SOAP processor, or any suitable processor for other web method protocols. The API contract processor 965 comprises code to perform the modifications to the API method calls 701 , 702 and WSDL 703 , 704 described above. The API contract processor 965 may be a WSDL processor, or any suitable processor for other web service API. The billing unit 970 comprises code to bill client applications 15 for the transparent use of web services 25 . The login services module 980 comprises code to administer and service a login request received from a client application 15 , and to administer authorization and authentication of a client application 15 . The login request may be passed directly to the login services module 980 from the client application interface unit 310 . Alternatively, the login request may be first sent to the communication processor 311 to be sent to the login services module. The authentication ID provider 940 may comprise code which assigns one or more authentication IDs to a client application 15 when the client application 15 logs into a web service 25 . The authentication ID validator 945 may comprise code to validate the authentication ID. These components will be further described below.

[0086] FIG. 10 shows another example of a method for managing functionality for one or more web services 25 ( 1000 ) in accordance with an embodiment of the present invention. The method ( 1000 ) begins with listening for communications between client applications 15 and web services 25 ( 1001 ). The communications may be client applications 15 attempting to log into web services 25 , client applications 15 sending web service method calls 701 or API contract method calls 751 , or web services 25 sending responses to either method calls 703 or API contract method calls 753 .

[0087] If the client application interface unit 310 receives a login request ( 1002 ) to a web service 25 , the client application interface unit 310 sends the login request to the login services module 980 . Alternatively, the login request may be passed to the communication processor 311 to be passed onto the login services module 980 . The login services module 980 processes the login request ( 1003 ). The authentication module 520 validates the client application 15 , as described above. If the login request is successful, i.e., the client application 15 is valid, then the authentication ID provider 960 issues an authentication ID for the client application 15 . Information regarding the web service 25 for which the authentication ID is valid may be stored in the authentication ID validator 965 . Alternatively, the information relating to the issued authentication ID may be stored in an additional repository accessible by the authentication ID validator 965 . The client application interface unit 310 returns the authentication ID to the client application 15 ( 1004 ). The gateway module 500 now returns to a state of listening for communications ( 1001 ). This thread will be further described below.

[0088] If the client application interface unit 310 receives a client call 701 or a developer call 751 ( 1005 ), the client application interface unit 310 passes the call 701 , 751 to the communication processor 311 . The call 701 , 751 contains an authentication ID passed as a parameter. The web method call processor 960 would process a client call 701 ( 1006 ), as described above. The API contract processor 965 would process a developer call 751 ( 1006 ), as described above. The removed authentication ID is sent to the authentication ID validator 965 for validation. If the authentication ID is valid, then the communication processor 311 passes the corresponding WS call 702 or API call 752 to the web services interface unit 312 to be delegated to the appropriate web service 25 ( 1007 ). Information regarding the client application 15 and the call 701 , 751 may be logged in a repository. The gateway module 500 now returns to a state of listening for communications ( 1001 ).

[0089] If the web services interface unit 312 receives a WS response 703 or a WSDL 753 ( 1008 ), then the web services interface unit 312 passes the WSDL 703 to the communication processor 311 . The web method call processor 960 would process a WS response 703 ( 1009 ), as described above. The API contract processor 965 would processes a WSDL 703 ( 1009 ), as described above. If the call 702 , 752 and the response 703 , 753 are asynchronous, then information stored in a repository may be accessed to determine the client application 15 which sent the original call 701 , 751 corresponding to the response 703 , 753 . If the call 702 , 752 and the response 703 , 753 are synchronous, then the identity of the client application 15 which sent the original call 701 , 751 is clear. The client response 704 or modified WSDL 754 is passed to the client application interface unit 310 to be sent to the client application 15 ( 1010 ). The gateway module 500 now returns to a state of listening for communications ( 1001 ).

[0090] Other steps may be added to the method ( 1000 ), including metering the gateway module 900 usage and billing the client application 15 , as well as billing a web service provider 20 .

[0091] In alternative examples of a communication processor 311 , the web method call processor 960 and the API contract processor 965 may comprise further sub-components, to handle their tasks. For example, the web method call processor may either contain a SOAP method call processor and a SOAP response processor. Similarly, the API contract processor may contain a WSDL communication processor and a WSDL response processor. Method call processors for other protocols and API contract processors for other API contract documents may be added to the web method call processor and the API contract processor, respectively. Furthermore, the communication processor 311 may be created to only contain desired sub-components.

[0092] An alternative to the login thread ( 1001 - 1002 - 1003 - 1004 - 1001 ) described above will now be described. Some of the detail in this alternative description may be used to augment the description of the above thread as well.

[0093] Using a secured channel is safer but slower than an unsecured channel since a secured channel requires the extra encryption/decryption steps. An alternative solution is to have the client application 15 log into the web service 25 once by sending client application credentials, typically a user name and password, over the secure channel and in return the client application 15 will receive a unique authentication identifier (ID) over the secured channel. Sometimes an authentication ID is called a session ID. However, there is a distinction between a session ID that refers to a locked communication between a client and a server and a session ID that refers to the fact that authentication has occurred. Thus, the term authentication ID is used in this specification.

[0094] Successive calls to the web service 25 are then made over an unsecured channel with the authentication ID to identify the client application 15 . Since the client application credentials are not sent during the successive calls, the calls no longer needs to be done over a secure channel. The calls can be sent over an unencrypted channel, such as http. This will improve performance as well as limit the number of times that the client application credentials are sent. When the server receives a web service call, it will authorize the client application 15 by verifying that the authentication ID is valid at that point in time.

[0095] This use of an authentication ID is only partially acceptable since the client credentials are safe as they are passed over the secure channel once and the client application 15 can still be authenticated for access to web services using the authentication ID. The problem is that since the web service calls are not done over a secured channel, the authentication ID could be compromised. Anyone who is observing the unsecured channel could note the authentication ID as it is used in the web service calls. The observer could then reuse this authentication ID and gain unauthorized access to the web service 25 .

[0096] One adaptation to the use of an authentication ID is to have the authentication ID time out after a certain period of time. Once an authentication ID has expired, anyone who has obtained it with or without authorization will no longer be able to use it and the authorized user will have to logon again and receive a new authentication ID. While the time-out of an authentication ID solution is better than no solution, there is still the problem that a misuse of a web service may occur for a limited time.

[0097] Another aspect of the gateway module 900 described here uses a pool of authentication IDs. A pool of authentication IDs contains a plurality of authentication IDs. As described above, the authentication ID provider 940 may comprise code which assigns one or more authentication IDs to a client application 15 when the client application 15 logs into a web service 25 . These authentication IDs are passed as parameters in the method calls 701 , 751 as described above. The authentication ID validator 945 may comprise code to validate the authentication ID. This authentication code be done in a number of ways. In an example of an embodiment of the present invention, a working table mapping is setup when the client application 15 is authenticated (i.e., authentication ID returned). The authentication ID is checked every time a method is called, then deleted if the client application 15 logs off or the authentication ID expires. An alternative of using a hashing system would require care to remain as secure.

[0098] The user of a client application 15 logs onto a web service 25 by sending client application credentials, typically a user name and password, over a secured channel as described above. In return, the client application 15 will receive a group or pool of authentication IDs. The pool of authentication IDs returned is secure since the pool is sent back over the secured channel. The exact number of authentication IDs returned can vary depending on the system administration requirements for the web service 25 . Once the client application 15 has this pool of authentication IDs, the client application 15 may use a different authentication ID from this pool with each successive call to the web service 25 . The authentication ID that is used will then expire upon use so that it can not be reused. This means that even if an eavesdropper is able to compromise an authentication ID, the eavesdropper will not be able to use it since it can only be used once.

[0099] FIG. 11 shows the sequence of logging onto a web service 25 and using the pool of authentication IDs. In FIG. 11 , the sequences are listed as A, B, C 1 , R 1 , . . . , Cn, Rn, where n is an integer greater than one. The step “A” represents a client application 15 sending client application credentials over a secured channel, such as https. The step “B” represents the server authenticating the user and returning a pool of n authentication IDs over the secured channel. The steps “C 1 ” to “Cn” represent the client application 15 making up to n web service calls over an unsecured channel using a different authentication ID from the pool of n IDs returned. Each authentication ID will expire upon use. The steps “R 1 ” to “Rn” represent the server validating the authentication ID used and returning the result of the web service call to the client application 15 .

[0100] After the client application 15 has used up all the authentication IDs in the pool that was given, the client application 15 may log on again to receive another pool of authentication IDs. No one other than the client application 15 will be able to use the authentication IDs since the authentication IDs are always given to the client application 15 over a secured channel and the authentication IDs expire upon use. Each authentication ID is not compromised during or after its use over an unsecured channel because an unauthorized person who manages to capture an authentication ID only receives an expired authentication ID.

[0101] Further security features may be added to the pool of authentication IDs. For example, unused authentication IDs in a pool of authentication IDs can be set to expire after a preset event such as the expiry of a period of time.

[0102] FIG. 12 shows a method for providing a pool of authentication IDs ( 1200 ) for use in web services communication. The method begins with the client application interface unit 310 receiving a request for a pool of authentication IDs ( 1201 ) over a secured channel. Typically, the request will come from a user using a client application 15 . The request is passed to the authentication ID provider 940 of the login services module 980 . The authentication ID provider 940 creates and assigns a pool of authentication IDs ( 1202 ). The authentication IDs may be passed as parameters by the client application 15 during web service communication, such as SOAP communication. The authentication IDs may be created and assigned by code in the authentication ID provider 940 . The pool of authentication IDs is passed to the client application interface unit 310 to be sent to the client application 15 ( 1203 ) over a secured channel and the method is done ( 1204 ). The client application 15 may now use the authentication IDs.

[0103] FIG. 13 shows a method for using a pool of authentication IDs. During subsequent client calls 701 over an unsecured channel such as http, an authentication ID from the pool of authentication IDs is sent as a parameter in the client calls 701 . The client application interface unit 310 receive a client call 701 containing the authentication ID ( 1301 ). The authentication ID is parsed from the client call 701 by the communication processor 311 , as described above, and passed to the authentication ID validator 945 . If the authentication ID is not valid ( 1302 ), then the client call 701 is rejected and the method is done ( 1305 ). If the authentication ID is valid ( 1302 ), then the next step is to check whether the client application 15 is authorized to access the web service method relating to the client call 701 ( 1303 ). If the client application 15 is not authorized ( 1303 ), then the client call 701 is rejected and the method is done ( 1305 ). If the client application 15 is authorized ( 1303 ), then the WS call 702 is sent ( 1304 ), as described above, and the method is done ( 1305 ).

[0104] FIG. 14 shows another example of a login services module 1400 in accordance with an embodiment of the present invention. The login services module 1400 may be used by the gateway module 900 . The login services module 1400 comprises an authentication ID provider 940 , an authentication ID validator 945 , an authentication module 520 , an authorization module 525 , and an information repository 1401 . The authentication module 520 , authorization module 525 , authentication ID provider 940 and authentication ID validator 945 are similar to those described above. The information repository 1401 contains information used to authenticate and authorize client applications 15 , as well as storing authentication ID allocations. The information repository 1401 may be a database. The authentication ID provider 940 , authentication ID validator 945 , authentication module 520 , and authorization module 525 are connected to the information repository 1401 and may be accessed by the communication processor 311 .

[0105] Alternatively, the repository 1401 may be accessed by components of the gateway module 900 , including the metering module 950 and the billing module 970 . Client applications 15 may be charged for the pool of authentication IDs based upon the size of the pool of authentication IDs. Packages of authentication IDs may be available for a client application 15 to order. For example, a client application 15 may order a basic package of 100 authentication IDs, or a premium package of 1000 authentication IDs. Other sizes of packages may be preset. A client application 15 may also be prompted by the authentication ID provider to enter the number of authentication IDs in the pool of authentication IDs.

[0106] Alternatively, the billing module 970 may charge based upon use of an authentication ID. In such a scenario, the metering module 950 tracks and records usage of the pool of authentication IDs. The information collected by the metering module 950 is stored in the repository 1401 , or another central repository which may be accessed by components of the gateway module 900 .

[0107] FIG. 15 shows a method for providing a pool of authentication IDs ( 1500 ) for use in web services communication. The method begins with the login module 1400 receiving a request for a pool of authentication IDs from a client application 15 . Specifically, the login services module 1400 receives client application credentials from the client application interface unit 310 which receives the request over a secured