WO2004090750A2

WO2004090750A2 - Access to web services

Info

Publication number: WO2004090750A2
Application number: PCT/GB2003/005426
Authority: WO
Inventors: Brian Hulse; Philip David Rowley; Christopher Edward Sharp
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2003-04-12
Filing date: 2003-12-12
Publication date: 2004-10-21
Anticipated expiration: 2005-10-12
Also published as: GB0308523D0; AU2003292411A1; WO2004090750A3

Abstract

The present invention provides a method, apparatus and computer program product which enable a web service gateway which provides support for business services which are described in a document of a particular document format, for example Web Services Definition Language (WSDL), to further provide support for web clients which do not recognise that particular format and use a profile of a different format, for example as specified by RosettaNet. The web client provides its profile to the gateway. The gateway then uses the profile to locate a document, in a format not recognised by the web client, which describes a web service suitable to handle the requests from the client. Any requests form the web client are then routed to the web service.

Description

AtTCESS TO WEB SERVICES

Field of the Invention

The present invention relates to web services and more particularly to providing a web client with access to web services via a web services gateway.

Background to the Invention

Over recent years it has become commonplace for a business to provide a web site on the Internet which, for example, enables a web client to purchase goods from the business over the world wide web. Following on from this success it has more recently become a requirement to handle more complex e-business applications on the Internet which, for example, enable business to business communication and this requirement; has been satisfied by the arrival of web services. Web services are modular and enhanced e-business applications that enable programmatic interaction between applications across the Internet.

A web service may, for example, be based on shared, open, and emerging technology standards and protocols, such as SOAP (Simple Object Access Protocol) , UDDI (Universal Description, Discovery and Integration) , and WSDL (Web Service Definition Language) . In this environment web services can communicate, interact, and integrate with heterogeneous applications, irrespective of their implementation formats, thereby enabling web services to interact with one another across the Internet to facilitate dynamic integration between businesses, suppliers, partners, and customers .

For example, a web service which provides an e-business application publishes its URL in a well known UDDI directory. A client can then obtain the URL from the UDDI directory and contact the e-business using the URL in order to obtain a WSDL document. The WSDL describes the interface provided for clients by the service e-business application, one or more transport mechanisms each supporting a communication protocol, for example SOAP over HTTP (HyperText Transport Protocol) and an end point address for each transport mechanism. Once a web client has the WSDL it can invoke the interface via the specified end point using the communication protocol of the specified transport mechanism. Further if the client has an e-business application with which the service e-business application may wish to communicate, the client and service may exchange WSDL documents in order to make this possible. Further, in order to enable clients and web services to communicate when each uses a different communication protocol, a web service gateway is used to transform client requests from one communication protocol to another.

However, whilst many web clients and services have made use of the WSDL documents and a UDDI registry many other web services have made use of other business to business (b2b) protocols, such as those specified, for example, by RosettaNet, cXML, and the Internet Engineering Task Force (AS1 and AS2) . These protocols enable business partners using the same b2b protocol to communicate. However it is not currently possible for a web client which makes use of one of these other, non WSDL based, business to business protocols, to communicate with web services which are described using a WSDL document. Therefore, such clients cannot carry out e-commerce with a business partner which publishes it services using a WSDL document.

Summary of the invention

Accordingly the present invention provides a method for a web services gateway to enable a web client to access a web service, the method comprising the steps of: receiving a profile from the web client, the profile containing web client requirements of a web service with which the web client wishes to communicate, the profile being in a format not recognisable to web service; locating a document, in a format not recognisable to the web client, describing the web service which satisfies the web client requirements; and returning to the client a location in a web services gateway to which the client can send a request for forwarding to the web service.

According to a second aspect the present invention provides a web services gateway which enables a web client to access to a web service, the gateway comprising: means for receiving a profile from the web client, the profile containing requirements of a web service with which the web client wishes to communicate, the profile being in a format not recognisable to the web service; means for locating a document, in a format not recognisable to the web client, describing the web service which satisfies the client requirements; and means for returning to the client a location in a web services gateway to which the client can send a request for forwarding to the web service. According to a third aspect the present invention provides a computer program product comprising instructions which, when executed on a data processing host, cause the data processing host to carry out the method according to the first aspect.

Optionally the location returned to the web client could be in a different web service gateway to that which received the profile from the web client. Alternatively it is in the same web service gateway and preferably the gateway subsequently receives a request from a web client, at the location returned, to access the web service. In this case the gateway locates a document, in a format not recognisable to the web client, describing a web service suitable for handling the request and uses details from the document to convert and send the request to the web service it describes. Note that the document used to convert the web client request can be the same or a different document to that which was located on receipt of the web client profile.

On receipt of a web client request to access a web service the gateway must locate a document, in a format not recognisable to the web client, describing a web service suitable for handling the request. Optionally the location returned to the client could be used by the gateway to identify the document, for example if the gateway provides the client with a location which uniquely identifies the document to use. Alternatively the gateway obtains information from the received request, for example the operation called, which can be used to locate an appropriate documen .

Preferably the document format which is not recognisable to the client is according to the Web Services Definition Language (WSDL) and further could be any WSDL based format, for example WSDL4J (WSDL for Java) or XLANG (WSDL with extensions) . Alternatively the document format could be in another definition language, for example CORBA IDL.

Preferably the profile is specified according to RosettaNet standards. Alternatively it could be, for example, according to other standards such as those specified by cXML, and the Internet Engineering Task Force (AS1 and AS2) .

Note that the WSDL document could be in any WSDL based format, for example WSDL4J (WSDL for Java) or XLANG (WSDL with extensions) . Brief Description of the Drawings

The invention will now be described, by way of example only, with reference to a preferred embodiment thereof, as illustrated in the accompanying drawings, in which:

Fig. 1 is a schematic diagram of a data processing environment in which the preferred embodiment of the present invention can be advantageously applied;

Fig. 2 is a schematic diagram of an example web client sending a request to a web service through a gateway based on use of a UDDI registry and WSDL documents according to the prior art;

Fig. 3 is a schematic diagram of an example of a b2b client written to RosettaNet standards sending a request to a web service via a gateway where the web service is implemented to use a WSDL document;

Fig. 4 is a schematic diagram of finding a WSDL document which satisfies web client requirements as specified in a RosettaNet profile provided by the web client .

Fig. 5a is a flow diagram of the method followed by a gateway server ^■ on receipt of a b2b profile from a b2b client; and

Fig. 5b is a flow diagram of the method followed by a gateway server on receipt of a request from a b2b client for a web service;

Note that in the figures like numbers are used to denote like parts.

Description of the Preferred Embodiment

Figure 1 is a block diagram of a data processing environment in which the preferred embodiment of the present invention can be advantageously applied; In Figure 1, a client/server data processing host 10 is connected to client/server data processing hosts 12 and 13 via a network 11, which could be, for example, the Internet. For example a client program could be executing on host 10 which is accessing a arget service on host 12 via a gateway server on host 13. Client/server 10 has a processor 101 for executing programs that control the operation of the client/server 10, a RAM volatile memory element 102, a non-volatile memory 103, and a network connector 104 for use in interfacing with the network 11 for communication with the other client/servers 12 and 13.

In the preferred embodiment which follows the document describing' a web service is a WSDL document. Note that a WSDL document contains details of the web service such as Port Type, Bindings, Ports, Messages, Types etc. The Port Type and messages define the operations and associated parameters provided by the web service, the Bindings specify the communication protocols supported by the web service, and the Ports specify end point addresses for channels providing access to the web service using the communication protocols.

Further note that the preferred embodiment considers a web client service implemented using the RosettaNet standard b2b protocol. According to RosettNet business partners exchange b2b profiles. A b2b profile includes such information as one or more communication protocols to use for communication with the business, one or more locations at which the business can be contacted, and details of a Partner Information Process (PIP) and an XML Document Type Definition (DTD) which respectively describe the exchange protocols and format of the operations which the business uses. Further the RosettaNet standards specifies many standard PIPs and XML DTDs, for example PIP3A4 and XML DTD3A4, PIP3A4 specifying that a buyer sends a purchase order request operation to the seller and the seller sends a purchase order confirmation operation to the buyer and XML DTD3A4 specifying the format of those operations. As a result, for example, a Book business which sells books may send its b2b profile to one or more business partners which may then use information from the b2b profile in order to purchase books from it. (RosettaNet and PIP are trademarks of the RosettaNet organisation) .

Figure 2 is a schematic diagram of an example of a web client 201 sending a request to a WSDL-aware eBook web service 206, herein denoted *eBook", through a gateway 210 based on the use of a UDDI registry 218 and WSDL documents 208, 213, and 214, according to the prior art. The eBook service 206 is available from a target server 205 which has a channel 207 which supports communication using a communication protocol of SOAP over HTTP. The eBook service provides the ability to purchase books using a purchase order request from a client to whom the ebook service sends a purchase order confirmation. Details of the eBook service are described in a WSDL document WSDL1 208 which specifies Port Types of

PurchaseOrderRequest ( ) and PurchaseOrderResponse ( ) , bindings and port for the channel 207 which specify a communication protocol of SOAP/HTTP, and an end point address of the channel through which the service can be contacted. The target server 205 provides (230) WSDLl 208 to the gateway 210 which saves a copy of WSDLl 213. In the gateway WSDLl 213 is passed (231) to the gateway engine 212 which, for example, changes the binding and port of the eBook service channel to those provided by the gateway, thereby producing (232) an new WSDL, WSDLla 214. In this example the gateway has two channels, a SOAP/Java Message Service (JMS) channel 215 and a SOAP/HTTP channel 216 (Java is a registered trademark of Sun Microsystems Inc.). The gateway then registers (233) the eBook service with a known UDDI directory 218 by providing to the UDDI directory the type of the service and the URL of the servlet 211 from which a client can obtain a copy of the modified WSDL, WSDLla 214. The UDDI directory may be known to the gateway, for example, through configuration information.

A web client process 201 is running an application 202 which wishes to access the eBook service. The client process includes a channel 203 which provides a transport mechanism of SOAP over JMS. The application first accesses (234) the UDDI directory 218 to obtain details of a book service and in return receives details of the URL of the servlet 211 in the gateway 210 from which the modified WSDL, WSDLla 214, of the eBook service can be obtained. The client application 202 then requests (235) the WSDL document describing the eBook service from the servlet 211. As a result of this request the servlet 211 obtains (236) WSDLla 214 and returns it to the client application. Then, based on this document, the client application requests the purchaseOrderRequest ( ) operation of the eBook service as specified in the Port Type of the WSDL document using a communication protocol of SOAP/JMS as specified in the bindings of the WSDL document and directing the request to the end point address of the SOAP/JMS communication channel as specified as a Port in the WSDL document. To make the request the client application 202 passes (237) the request to SOAP/JMS channel 203 in the client process which then forwards it (238) to the SOAP/JMS channel 215 in the gateway server 210.

When the SOAP/JMS channel 215 of the gateway 210 receives this request it passes (239) the request to the gateway engine. The request includes details of the WSDL document, WSDLla 214, which the client application used to make the request, and based on this information the gateway engine discovers the original WSDL, WSDLl 213, which was used to create WSDLla. From WSDLl the gateway engine then obtains the bindings and port for the eBook service and as a result passes the request to the SOAP/HTTP channel 216 of the gateway server giving details of the SOAP/HTTP channel 207 of the eBook server. The SOAP/HTTP channel 216 then sends (241) the request to the SOAP/HTTP channel 207 of the eBook server

205 which then passes (242) it on to the eBook service 206.

Figure 2 also shows a second web client 221 but which is implemented according to Rosetta Net standards. As a result it has a b2b profile 224 which defines the interface of a web service with which it wishes to do business and an application 222 written to use that interface. However, according to the prior art the client cannot access the ebook service 206 through the ebook server 205 directly or use the gateway 210 to access the eBook service 206 because the web client does not understand WSDL documents and the gateway and e-Book server do not understand Rosetta Net b2b profiles.

Fig. 3 is a schematic diagram of an example of a client business 221 written to RosettaNet standards sending a request to an eBook web service

206 via a gateway 210 where the web service is implemented to use a WSDL document 208, according to a preferred embodiment of the present invention. Note that in figure 3, where common reference numerals are used with figure 2, the associated function is the same as in figure 2. Details of the how the client business wishes to communicate with a Book service are described in a b2b Profile 224, which contains details of a Partner Interface process (PIP) and an XML Document Type Definition (DTD) , the communication protocols which the client business uses and the address at which the client business can be contacted. The PIP and XML DTD contain details of the business objects and associated exchange protocols. In this example the B2B profile 224 contains details of PIP3A4, XML DTD3A4, the RNIF/HTTP channel 223 and an end point address of the RNIF channel. PIP3A4 contains details an exchange protocol which says that the buyer sends a purchase order request operation to the seller and the seller sends a purchase order confirmation operation to the buyer, and XML DTD3A4 contains the data form of the purchase order request and purchase order confirmation operations. In this example the client business is a buyer, and as a result the client application 222 is written to make a purchase order request and receive a purchase order response.

When the web client wishes to find a business partner to purchase books from it sends (311) its b2b profile 224 to a profiler 301 in the gateway 210. Meanwhile, as described with reference to fig. 2 the eBook service 206 has provided its WSDL, WSDLl 208, to the gateway server which has kept a copy WSDLl 213. The WSDL includes a Port Type which specifies that the service accepts a purchase order request and responds with a purchase order confirmation. Now, when the profiler receives the b2b profile 224 from the client it uses information in the b2b profile to find a WSDL document which describes a service which is suitable for the client to do business with. As a result it finds WSDLl 213, the gateway's copy of the eBook service WSDL. Having found a suitable WSDL the profiler returns to the client application details of a location in the gateway to which the client can send its request, which in this case is the RNIF/HTTP channel 302. On receipt of this location the client application 222 provides (313) a purchase order request to its RNIF/HTTP channel 223 which forwards (314) it to the RNIF/HTTP channel 302 in the gateway server 210. When the request is received in gateway 210, the RNIF/HTTP channel provides (315) the request to the gateway engine 212 which then provides

(316) details from the request, for example which identify the request as a purchase order request, to the profiler 301 which then locates (312) the

WSDL, WSDLl 213, of the eBook service which can handle the request. Details of the WSDL are then returned to the engine 212 which obtains

(317) information from WSDLl 213 which includes a location at which the eBook service 206 can be contacted and the protocol to be used in sending requests to it. As a result the gateway engine transforms the client request from a RNIF/HTTP request to a SOAP/HTTP request and provides (318) it to the SOAP/HTTP channel 216 which then sends (319) it to the eBook service 206 via the SOAP/HTTP channel 207 of the eBook server 205. When the request is received by the SOAP/HTTP channel it forwards (320) it to the eBook service 206 which does not know that it did not come directly from the client application 224 and that the client does not use a WSDL document in order to describe itself.

In summary, according to the embodiment of figure 3, in which the web client is a RosettaNet compliant business and has a b2b profile which specifies PIP3A4 and XML DTD3A4, and uses a communication protocol of RNIF/HTTP. The target business is a web service which has an application which provides the correct BO's and exchange protocols required for PIP3A4 and XML DTD3A4 but details of which are provided to the gateway as a WSDL document. The client business contacts the gateway passing it's b2b profile and asking for a suitable business partner to use. The profiler in the gateway uses information from the b2b profile to match the b2b profile with a WSDL and, as a result, matches it with the WSDL of the web service. An address in the gateway for the client to send a request is then returned to the client. The client sends an RNIF/HTTP purchase order request which the gateway receives, asks the profiler for the matching WSDL of the web service. This is returned to the gateway which now knows to send the request to the web service using, for example, SOAP/JMS. Note that whilst the preferred embodiment has been discussed in terms of PIP3A4 and XML DTD3A4 which relate to requesting a purchase order there are many other PIPs and associated XML DTDs which are defined by the RosettaNet standard which could alternatively be used. For example PIPlAl and XML DTD3A1 for requesting account set-up, PIP1B2 and XML DTD1B2 for requesting Authorisation status, PIP2A1 and XML DTD2A1 to distribute new product information etc.

Further note that whilst the preferred embodiment has been discussed in terms of a b2b client which provides a b2b profile according to the RosettaNet standard, alternatively the b2b client could provide a b2b profile or equivalent according to any other standard such as this specified by cXML, and the Internet Engineering Task Force (AS1 and AS2) . According to the invention the requirement of the b2b client is to provide to the gateway sufficient (in a non-WSDL format) information for the gateway, to find a WSDL document describing a suitable web service and sufficient information comprises details of the interface supported by the b2b client and a communication protocol and address to use when communicating with it.

Further note that whilst the preferred embodiment describes use of SOAP/JMS, SOAP/HTTP and RNIF/HTTP channels by the gateway server, in another embodiment one or more of these channels may be omitted and/or replaced and/or added to. For example other additional/alternative channels could provide communication using, for example, Internet Inter-Orb Protocol (HOP), HOP Secure (HOPS), HTTP, HTTP Secure (HTTPS) , SOAP over JMS, Remote Method Invocation (RMI) over HOP, XML over JMS, SOAP over Simple Mail Transfer Protocol (SMTP) , or Enterprise JavaBean (JavaBeans is a registered trademark of Sun Microsystems Inc.).

Further note that the gateway of the preferred embodiment comprises a servlet 211, engine 212, and profiler 301. However, a skilled person would be aware that the functionality provided by these components could easily be distributed amongst fewer or more components and conceptually are provided by a single component which is the gateway 210. Further, the functionality of the gateway 210 could be provided in a server, such as target server 205, which further comprises a target service.

Fig. 4 shows how, according to the preferred embodiment of the present invention, with reference to fig. 3, the B2B profile (224) received from the web client (221) is matched with WSDLl (213) which describes a service suitable for handling a request from the web client. The b2b profile (224) contains details of a Partner Information Process (PIP) and an XML Document Type Definition (DTD) which specify the services required by the web client. In this example the b2b profile contains details of PIP3A4 and XML DTD3A4 which define the exchange protocols and format of the messages (operations) which are used in the exchange protocol, respectively. The gateway uses this information to obtain XϊL DTD3A4 (401) and PIP3A4 (404) which are publicly available documents and therefore not necessary to include directly in the b2b profile (224) . XML DTD3A4 is first converted (411) into an XML Schema (402) using a standard tool, for example Extensible Stylesheet Language Translation (XSLT) , and then information from the XML Schema (402) relating to the format of the operations (messages) is transformed and compared with a section (403) of a WSDL document (302) which describes the format of the messages supported by the web service. Assuming a match is found the information in PIP3A4 (404) is then transformed and compared (413) with a section (405) of the WSDL document (213) which describes the operations and associated exchange protocols supported by the service. Assuming this also matches an appropriate web service has been found and the binding information (406) from the WSDL document can be subsequently used to convert a client request for the web service to a request suitable for the web service to receive.

Fig. 5a is a flow diagram of the method followed by a gateway server on receipt of a b2b profile from a b2b client, for example, with reference to figure 3, the method of the profiler 301 on receipt of b2b profile 224 from the b2b client application 222. At step 501 the gateway receives (311 of fig. 3) the b2b profile from the b2b client and at step 502 the b2b profile received is used to locate (312 of fig. 3) a WSDL document which describes a web service which is suitable for the client to do business with. For example the WSDL describes a web service which supports the same interfaces as specified in the clients b2b profile. Having found a match the gateway then, at step 403, returns to the client a location in a gateway which the client can use to send a request to the web service identified at step 502. Note that the location returned by the gateway service could be in the same or a different gateway and could be a specific location for the client such that when the gateway receives the request it knows from which client the request was received and to which web service the request is targeted. Alternatively a more general location can be returned such that when the client request is received the gateway must re-match the request with a WSDL document of a target service when processing it. Note that if a match is not found at step 502 the gateway does not return a location to the web client. Fig. 5b is a flow diagram of the method followed by a gateway server on receipt of a request from a b2b client for a web service, for example, with reference to figure 3, the method of the channels 216 and 302, gateway engine 212, and profiler 301 on receipt (314) of a request from a client application 222 for a web eBook service 206. At step 510 a b2b client request which is targeted to a web service is received and at step 511 details which can be used to identify the web service which is the target of the request are obtained from the request. For example the details could be the operation of the web service which the b2b client is requesting. At step 512 these details are then used to find a WSDL document which describes a target service suitable for handling the request. Note that this could be the same or a different document to that found at step 502 of Fig. 5a. Note that alternatively the gateway can skip steps 511 and 512 if it can immediately associate the request with the WSDL document found at step 502 of Fig. 5a, for example by returning a specific location to the b2b client at step 503 of Fig. 5a. Once the WSDL of the web service is known details of the protocols supported by the web service can be obtained from it and at step 513 the request is, if necessary, modified to use a protocol supported by the web service. Finally at step 514 the request is sent to the web service at a location specified in the WSDL document used to convert the request. Thus a b2b client request based on a b2b profile has been received, modified and forwarded to a WSDL specified web service.

Note that a skilled person would realise that the methods described in figures 5a and 5b could be implemented in a variety of programming languages, for example, Java, C, and C++. Further a skilled person would realise that once implemented the methods can be stored in a computer program product comprising or more programs, in source or executable form, on a media, such as floppy disk, CD, and DVD, suitable for loading onto a data processing host and causing the data processing host to carry out the methods .

The present invention thus provides a method, apparatus and computer program product which enable a web service gateway which provides support for business services which are described in a document of a particular document format, for example Web Services Definition Language (WSDL) , to further provide support for web clients which do not recognise that particular format and use a profile of a different format, for example as specified by RosettaNet. The web client provides its profile to the gateway. The gateway then uses the profile to locate a document, in a format not recognised by the web client, which describes a web service suitable to handle the requests from the client. Any requests form the web client are then routed to the web service.

Claims

1. A method for a web services gateway to enable a web client to access a web service, the method comprising the steps of:

receiving a profile from the web client, the profile containing web client requirements of a web service with which the web client wishes to communicate, the profile being in a format not recognisable to web service;

locating a document, in a format not recognisable to the web client, describing the web service which satisfies the web client requirements; and

returning to the client a location in a web services gateway to which the client can send a request for forwarding to the web service.

2. A method according to claim 1, comprising the further steps of:

receiving a request from the web client, at the location returned to the web client, to access the web service; and

forwarding the request to a suitable web service comprising the steps :

locating a document, in a format not recognisable to the web client, describing a web service capable of handling the web client request;

using details from the document to convert the received request to a request suitable for sending to the web service; and

sending the converted request to the web service.

3. A method according to claim 2 wherein the step of locating a document describing a web service suitable for handling the web client request uses the location at which the request was received to locate the document .

4. A method according to claim 2 wherein the step of locating a document describing a web service suitable for handling the web client request uses information obtained from the request to access a web service to locate the document .

5. A method according to any preceding claim wherein the document format not recognisable to the web client is according to the Web Services Definition Language (WSDL) .

6. A web services gateway which enables a web client to access to a web service, the gateway comprising:

means for receiving a profile from the web client, the profile containing requirements of a web service with which the web client wishes to communicate, the profile being in a format not recognisable to the web service;

means for locating a document, in a format not recognisable to the web client, describing the web service which satisfies the client requirements; and

means for returning to the client a location in a web services gateway to which the client can send a request for forwarding to the web service.

7. A gateway according to claim 6, further comprising:

means for receiving a request from the web client, at the location returned to the web client, to access a web service; and

means for forwarding the request to a suitable web service comprising:

means for locating a document, in a format not recognisable to the web client, describing a web service suitable for handling the web client request;

means for using details from the document to convert the received request to a request suitable for sending to the web service; and

means for sending the converted request to the web service.

8. A gateway according to 7 wherein the means for locating a document describing a web service suitable for handling the web client request -uses the location at which the request was received to locate the document.

9. A gateway according to claim 7 wherein the means for locating a document describing a web service suitable for handling the web client request uses information obtained from the request to access a web service to locate the document .

10. A gateway according to any one of claims 6 to 9 wherein the document format not recognisable to the web client is according to the Web Services Definition Language (WSDL) .

11. A computer program product comprising instructions which, when executed on a data processing host, cause the data processing host to carry out the method as claimed in any one of claims 1 to 5.