EP1881675A1

EP1881675A1 - System and method for managing a plurality of web services

Info

Publication number: EP1881675A1
Application number: EP06015020A
Authority: EP
Inventors: Harald Dr. Schöning; Johannes Dr. Viegener; Keith Swenson
Original assignee: Software AG
Current assignee: Software AG
Priority date: 2006-07-19
Filing date: 2006-07-19
Publication date: 2008-01-23
Anticipated expiration: 2026-07-19
Also published as: US20080028316A1; CN101174983A; US8935370B2; ES2315970T3; DE602006002884D1; EP1881675B1; CN101174983B; ATE409384T1

Abstract

The invention concerns a system for managing a plurality of web services (WS1, WS2, WS3, WS1', WS2', WS3') comprising a registry (10) including a description (WSDL1, WSDL2, WSDL3) for at least one of the plurality of web services, wherein the description of the at least one web service comprises a first endpoint (WS1, WS2, WS3) for a first runtime condition and a second endpoint (WS1', WS2', WS3') for a second runtime condition.

Description

1. Technical field

The present invention relates to a system and a method for managing a plurality of web services of a service oriented software architecture.

2. The prior art

Web services are standardized interfaces for exchanging data from one computer to another over a computer network, for example the internet. An application may request data from a server over the computer network using a web service provided by the server. Such a request is typically enclosed in a SOAP envelope, which is conveyed using HTTP, and may comprise XML in conjunction with other web-related standards. More technically advanced applications combine various web services to obtain or process the desired data. A software architecture, which is developed around a plurality of web services, is called a service oriented architecture (SOA).
In a SOA resources are made available to participants in the network as independent services that the participants can access in a standardized way. Whereas most definitions of a SOA use SOAP requests conveyed via HTTP / HTTPS over TCP/IP, a SOA may use any web service-based technology. The web services interoperate based on formal definitions which are independent from the underlying platform and programming language. The interface definition encapsulates the specific implementations. A SOA is independent of a specific development technology (such as Java and .NET). The software components become very reusable because the interface is standards-compliant and is independent from the underlying implementation of the web service logic. For example, a C# (C Sharp) service could be used by a JAVA application and vice versa.
A developer of a new application in an SOA needs access to the various web services, which are to be used by the new application. This does not only address the availability of the interface specifications of the involved web services, but also the provision of actually active web services that can be called for testing the new application. However, such testing calls must not interfere with the real world. For example calling a web service causing a money transfer for test purposes must not result in a real money transfer.
A similar scenario applies after development, when the new application is to be tested in a larger setting before it is approved for production usage. Again, new test instances of web services called by the new application might have to be created, because of different requirements concerning stability or result generation during the development phase and the testing phase in a larger setting. When the application is finally approved for production, the calls to the various test web services have to be replaced by calls to the real services. The various replacement steps exchanging the web services for development, large scale testing and finally production present a substantial risk for introducing errors into the final application.
It is therefore the technical problem underlying the present invention to provide a system and a method which overcomes the above outlined disadvantages of the prior art and which in particular facilitate the change from the different development and testing stages to the actual deployment of a new application involving one or more web services without the risk of introducing errors.

3. Summary of the invention

In one aspect of the invention, this problem is solved by a system for managing a plurality of web services comprising a registry including a description for at least one of the plurality of web services, wherein the description of the at least one web service comprises a first endpoint for a first runtime condition and a second endpoint for a second runtime condition.
Accordingly, web services for different runtime landscapes (e.g. development, test, production) can be managed within a single registry without loosing control over the services of the landscapes and the involved risk of introducing errors. On deployment, the correct endpoints can be automatically selected depending on the respective runtime condition. As a result, various test and production environments of a new application can be automatically generated.
In one embodiment, the system is further adapted to select one of the first and second endpoint during runtime depending on an evaluation of environmental information concerning the runtime condition provided by an application calling the web service. Setting the value of a single variable in the application therefore allows to determine, which landscape is used, since the one or more descriptions of the web services in the registry automatically include endpoints adapted to the respective runtime condition (e.g. test, deployment, etc.)
In another embodiment, the system is further adapted to select one of the first and second endpoint during runtime depending on the runtime condition stored in the registry. The registry might for example store information which reflects the current state of the development process and accordingly selects the appropriate landscape of web services for the new application.
In one embodiment, the first and second endpoint are defined in a first and a second WSDL document for the web service stored in the registry, which are related to each other, for example by referencing each other, wherein each of the WSDL documents may be marked for its specific runtime condition.
However, in the presently preferred embodiment, the first and the second endpoint are defined in a single WSDL document for the web service, preferably as a property component of the WSDL document. As a result, the registry stores WSDL descriptions of web service "twins", wherein one of the twins is used for a first runtime condition and the other for another runtime condition. The value of the property component is in one embodiment determined during runtime using a SOAP module of a request for the web service.
In the presently preferred embodiment, the first endpoint is adapted to be used for testing an application calling the at least one web service, whereas the second endpoint is preferably adapted to be used for deployment of an application calling the at least one web service. However, the concept of the present invention might also be used to select between other landscapes, i.e. for other runtime conditions.
Preferably, the system further comprises means for monitoring the endpoints of the plurality of web services during runtime and means for issuing a warning if a first web service is called with an endpoint for a first runtime condition and a second web service is called with an endpoint for a second runtime condition. The monitoring function avoids inconsistencies, which are likely to cause errors in the execution of the new application.
According to a further aspect, the present invention relates to a method for managing a plurality of web services comprising the step of storing a description for at least one of the plurality of web services in a registry, wherein the description of the at least one web service comprises a first endpoint for a first runtime condition and a second endpoint for a second runtime condition.
Further advantageous modifications of embodiments of the system and the method of the invention are defined in further dependent claims.

4. Short description of the drawings

In the following detailed description, presently preferred embodiments of the invention are further described with reference to the following figures:

Fig. 1:: A general overview of an example of a simplified SOA comprising an application calling a Web Service and a registry with a description of the Web Service; and
Fig. 2:: A simplified overview of an SOA having two landscapes with a plurality of web service twins; and
Fig. 3:: A flow chart illustrating the steps performed during runtime in a system and method according to an embodiment of the invention.

5. Detailed description of preferred embodiments

Fig. 1 presents an overview of an extremely simplified SOA: An application 30 issues a request 31 for a web service 20. To this end, the application 30 needs at first a description about the interface definitions of the web service 20. This description 40, which may for example be provided in the Web Service Definition Language (WSDL), can either be obtained directly from the web service 20 or from a registry 10 (cf. Fig. 1).
The registry 10 comprises preferably descriptions of all web services of the SOA, for example WSDL files 40 with information about the function, the data, the data type and the exchange protocols of the respective web service. Therefore, if the application 30 intends to send a request to the web service 20, it can obtain the WSDL file 40 from the registry 10 to find out how to access the web service 20.
However, when the new application 30 is being developed, it is necessary to repeatedly contact the involved web service 20 already for testing purposes, for example to verify, whether all requirements of the interface in the call to the web serve are satisfied and whether the response from the web service is properly received and processed by the application 30. If the web service 20 is actually deployed, each of these testing calls will cause some real world operation (for example the reservation of an airline ticket or the transfer of money from one account to another). In this context, it is to be noted that the web service 20 might be somewhere on the internet and its operation may not necessarily be under the control of the developer of the new application 30.
The present invention therefore provides according to a preferred embodiment service "twins" as schematically shown in Fig. 2: As can be seen, the registry 10 stores preferably single descriptions WSDL1 - WSDL3 of corresponding web services, however with multiple endpoints, each carrying a reference to the runtime landscape 50 or 50' it belongs to. The term "landscape" refers to a specific part of the overall SOA 100, which can be distinguished by some kind of designated attribute. In the simplified embodiment shown in Fig. 2 there is a separate test landscape 50 and separate production landscape 50'. Both landscapes 50, 50' provide at least partially the same web services WS1 - WS3 and WS1' - WS3', but only the production web services WS1' - WS3' are running in real life and are for example causing business transactions. The test versions of productive services (e.g. provided by some 3^rd party) can be automatically generated and added to the registry 10.
Other types of landscape distinctions can also be used, for example a development landscape versus a larger testing landscape or the landscape for one company versus the landscape for another company. Further, there may be not only two, but three or more landscapes.
To manage the above explained family of service twins without errors, the endpoints for the two landscapes 50, 50', in which the web services WS1 - WS3 and WS1' - WS3' exist, are defined in the single registry 10. Thus, the web service interface descriptions WSDL1 - WSDL3 are shared between the landscapes 50, 50', while the endpoints are not.
However, it is to be noted that instead of using single WSDL descriptions WSDL1 - WSDL3 for the web services WS1 - WS3 and WS1' - WS3', there could alternatively also be two sets of related descriptions WSDL1 - WSDL3 and WSDL1' - WSDL3' stored in the registry (not shown in Fig. 2), wherein the two WSDL descriptions belonging to a service twin (for example WSDL1 and WSDL1') are related to each other. Depending on the runtime condition one or the other (or possibly a third) description is used.
In the presently preferred embodiment, the endpoints for the two landscapes 50, 50' are defined in a single WSDL file for a service twin using the "properties" extensibility mechanism provided in WSDL 2.0. A "property" represents a named runtime value which affects the behavior of an aspect of a web service interaction. For example, a SOAP module of a request may specify a property to control the endpoints. This is illustrated in the following example for an exemplary WSDL file describing service twins:
As can be seen, two endpoints are defined, one for the test landscape, the other for the production landscape. The runtime value of the property component therefore determines one of two possible endpoints and thereby, whether the web service of the test landscape or of the production landscape will be addressed.
Alternatively, the endpoints of the two landscapes can be specified in accordance with the UDDI-XML-Schema (UDDI 3.0), as shown below:
An UDDI query to find the endpoint for a given landscape (e.g. test) could then look as follows:

 <find_binding xmlns="urn:uddi-org:api_v3"
       serviceKey="uddi:4fc7c540-ef08-11da-bf78-dc56dc1260cf">
 <findQualifiers>
   <findQualifier>exactNameMatch</findQualifier>
 </findQualifiers>
 <categoryBag>
   <keyedReference
       tModelKey="uddi:features.softwareag.com:landscapes"
       keyValue="test"/>
  </categoryBag>
 </find_binding>

The endpoint information thus manifested in the WSDL file or the registry (UDDI) can be used in various scenarios one of which is described in the following with reference to the flowchart of Fig. 3, which illustrates three components involved:

A web service execution component 70 is at runtime (for example of a test run) available to an application 30. The web service execution component 70 is called in step 200 by the application 30, when a web service 20 is to be executed, and receives a unique identification of the web service 20 as input (e.g. its UDDI key, or the URL of its WSDL file). In step 201, the web service execution component 70 prepares the execution of the call. In step 202, it accesses the information stored in the registry 10 to determine in step 204 the endpoint for the web service to be called, for example based on the WSDL file obtained from the registry 10. It is to be noted that the endpoint resulting in step 204 may depend on an input parameter provided by the application 30 and contained in its call as explained above, for example a certain property value in order to define a certain environment for the execution of the web service call. If there is no web service available at the indicated endpoint, an error is indicated. Otherwise, the web service execution component 70 calls the identified web service in step 205, which is executed in step 206 so that the results can be returned to the application 30 in step 207.

The described managing of the endpoints in the registry allows in addition at deployment time of the tested application 30 to identify all service endpoints previously used for testing that application and to permanently replace them by the endpoints already registered in the registry 10 for the production landscape. Further, web service calls can be monitored at runtime and checked whether a landscape crossing occurs, i.e. whether one web services is called, which belongs to a first landscape, such as the test landscape 50, and another web service 50' is called , which belongs to another landscape such as the production landscape 50'. If such an inconsistency is noted during runtime, a warning is issued.

Generally, the identification of the caller's landscape can use multiple mechanisms, e.g. a DNS-domain based separation of test and production landscape. The landscape information can be sent alongside the web service call. The following example of a WSDL file stored in the registry 10 requires such information and assumes that there is a specific SOAP module for landscape information management:

Alternatively, the registry 10 may store information about the development stage of a certain application and cause an appropriate selection of the endpoints (e.g. based on recorded deployment of the application). This may either be done for the whole landscape or also individually for each web service.

Claims

A system for managing a plurality of web services comprising a registry (10) including a description (WSDL1, WDSL2, WSDL3) for at least one of the plurality of web services, wherein the description (WSDL1, WDSL2, WSDL3) of the at least one web service comprises a first endpoint (WS1, WS2, WS3) for a first runtime condition and a second endpoint (WS1', WS2', WS3') for a second runtime condition.
The system of claim 1 further adapted to select one of the first (WS1, WS2, WS3) and second endpoint (WS1', WS2', WS3') during runtime depending on an evaluation of environmental information concerning the runtime condition provided by an application (30) calling the web service.
The system of claim 1 further adapted to select one of the first (WS1, WS2, WS3) and second endpoint (WS1', WS2', WS3') during runtime depending on the runtime condition stored in the registry (10).
The system of any of the preceding claims, wherein the first (WS1, WS2, WS3) and second endpoint (WS1', WS2', WS3') are defined in a first and a second WSDL document for the web service, which are related to each other.
The system of any of the preceding claims 1 - 3, wherein the first (WS1, WS2, WS3) and second endpoint (WS1', WS2', WS3') are defined in a single WSDL document (WSDL1, WDSL2, WSDL3) for the web service, preferably as a property component of the WSDL document.
The system of claim 5, wherein the value of the property component is determined during runtime using a SOAP module of a request for the web service.
The system of any of the preceding claims 1 - 6, wherein the registry (10) is an UDDI registry.
The system of any of the preceding claims, wherein the first endpoint (WS1, WS2, WS3) is adapted to be used for testing an application calling the at least one web service.
The system of any of the preceding claims, wherein the second endpoint (WS1', WS2', WS3') is adapted to be used for deployment of an application (30) calling the at least one web service.
The system of any of the preceding claims, wherein the registry (10) further comprises a third endpoint for a third runtime condition.
The system of any of the preceding claims, the system further comprising means for monitoring the endpoints (WS1, WS2, WS3, WS1', WS2', WS3') of the plurality of web services during runtime and means for issuing a warning if a first web service is called with an endpoint for a first runtime condition and a second web service is called with an endpoint for a second runtime condition.
A method for managing a plurality of web services comprising the step of storing a description (WSDL1, WDSL2, WSDL3) for at least one of the plurality of web services in a registry (10), wherein the description of the at least one web service comprises a first endpoint (WS1, WS2, WS3) for a first runtime condition and a second endpoint (WS1', WS2', WS3') for a second runtime condition.
The method of claim 12 further comprising the step of selecting one of the first (WS1, WS2, WS3) and second endpoint (WS1', WS2', WS3') during runtime depending on the evaluation of environmental information concerning the runtime condition provided by an application calling the web service.
The method of claim 12 further comprising the step of
storing the runtime condition in the registry; and
selecting one of the first (WS1, WS2, WS3) and second endpoint (WS1', WS2', WS3') during runtime.
The method of any of the preceding claims 12 - 14, wherein the step of storing a description for at least one of the plurality of web services in a registry comprises storing a first WSDL document for the web service indicating the first endpoint and storing a second WSDL document for the web service indicating the second endpoint, wherein the first and second WSDL documents are stored in the registry as related WSDL documents.
The method of any of the preceding claims 12 - 14, wherein the step of storing a description (WSDL1, WDSL2, WSDL3) for at least one of the plurality of web services in a registry comprises storing a single WSDL document for the web service with property components indicating the first and second endpoints.
The system of claim 16, wherein the values of the property components are determined during runtime using a SOAP module of a request for the web service.
The method of any of the preceding claims 12 - 17, wherein the registry (10) is a UDDI registry.
The method of any of the preceding claims 12 - 18, further comprising the step of using the first endpoint (WS1, WS2, WS3) for testing an application calling the at least one web service.
The method of any of the preceding claims 12 - 18, further comprising the step of using the second endpoint (WS1', WS2', WS3') for deployment of an application calling the at least one web service.
The method of any of the preceding claims 12-20, wherein the registry (10) further comprises a third endpoint for a third runtime condition.
The method of any of the preceding claims 12 - 21, further comprising the step of monitoring the endpoints (WS1, WS2, WS3, WS1', WS2', WS3') of the plurality of web services during runtime and issuing a warning, if a first web service is called with an endpoint for a first runtime condition and a second web service is called with an endpoint for a second runtime condition.