TU München - Fakultät für Informatik Lehrstuhl III: Datenbanksysteme

Context for Web Services

Contrary to parameters of a Web service, which are only of interest for this single service, the same context information is beneficial for a lot of Web services. Also, it can often be evaluated automatically, i.e., the service itself does not even have to know about it and to be able to process it. A further difference to (mandatory) parameters is that context is optional: It needs not to be passed to a Web service and if it is, the Web service needs not to understand and process it.

In our framework, context is transmitted as a header block in the SOAP messages that Web services send and receive. Similar to the SOAP header, a context header block contains several subelements, called context blocks. Each context block represents a different context type, i.e., a specific type of context information, and is uniquely identified by the qualified name of its top-level element. Figure 1 shows a context header block with two context blocks: a Consumer context block (with qualified name http://sg.fmi.uni-passau.de/context#Consumer) and a Client context block (with qualified name http://sg.fmi.uni-passau.de/context#Client).

A context header block can contain any type of context block. So, any application can insert its own context blocks into the context, as long as their qualified name is unique. Unknown context blocks are ignored by Web services or service platforms. ServiceGlobe itself provides an integrated set of context types which are explained in Section 5.

<Context xmlns="http://sg.fmi.uni-passau.de/context">
   <Consumer>
      <Name>John Doe</Name>
      <Email>john.doe@example.org</Email>
   </Consumer>
   <Client>
      <Hardware>
         <Defaults>http://example.com/PDADefault</Defaults>
         <ScreenSize>320x200</ScreenSize>
         <IsColorCapable>Yes</IsColorCapable>
      </Hardware>
   </Client>
</Context>        

1. Context Life-Cycle

Figure 2 depicts the life-cycle of context inserted into a Web service request:

First, a consumer's client inserts relevant context information from the consumer's local context into the SOAP request and sends it to the host executing the Web service. After the reception of such a request, the context is extracted and provided to the invoked Web service. During its execution, the service can read and modify this context. For example, in Figure 2 the first context block is modified (illustrated by the color change to gray) and a new context block is inserted (the dashed rectangle).

When the Web service invokes other services during its execution, its current context is automatically inserted into the sent requests. The response to such a request may also contain context information. In this case, the Web service can decide to extract the interesting data and insert it into its current context.

After the Web service terminated, the (modified) context is inserted into the service's SOAP response and sent back to the client which can use this context information to adjust the reply. Additionally, parts of the received context can be integrated into the consumer's local context (for future requests).

Whenever a SOAP request is created, it is possible to specify which context types should be inserted. A client uses annotations in the consumer's local context to determine such context types or it explicitly asks the consumer. A Web service specifies the context types which should be inserted either directly (in its sourcecode) or it utilizes annotations contained in its current context (which have been inserted by its invoker).

A security policy is required to allow consumers to specify what modifications a Web service is allowed to perform on the context. It must also specify what parts of the context the Web service is allowed to insert into requests to other Web services. Furthermore, the security policy must state if and in what ways a client is allowed to modify a consumer's local context. We are going to consider these issues in future work.

 

Figure 2: Life-Cycle of Context within a SOAP Message

2. Processing of Context Blocks

First of all, context information can be processed by the Web service that received the request. The service has full control on how the context information influences its execution and its reply and it can also modify the context. Besides the service, there are other components which can process context information:

First, the service platform can process the context to modify requests for and replies of invoked Web services. Thus, Web services can take advantage of context types unknown to them---either because they were unknown or regarded as unimportant at their development time. This is also beneficial for legacy Web services which cannot be modified, e.g., to provide the option of compressing their requests and responses depending on the context. Second, so-called context services can process context by pre- and/or post-processing Web service requests and responses based on the available context information. Context services are explained in Section 3. Third, the consumer's client can process context information returned to it. But there is only very limited sensible context information for a client (partly because clients only receive responses and no requests).

There are advantages and disadvantages to each of these components: Only Web services are able to adjust their internal process flow according to some context information. All other components can only modify the Web service's input and output data. On the other hand, shifting the context processing from the Web service to other components reduces the coding effort for Web services. Finally, Web services and service platforms are limited to use and process only context types known at their development time. Context services are a solution to this problem.

3. Context Services

A context service is a special kind of Web service that is able to rewrite the request to a Web service or its response based on a dedicated context type. The rewritten request or reply is then processed as normal, i.e., forwarded to the invoked Web service in case of a request or sent back to the invoker in case of a reply. Context services are distinguished into pre-processing and post-processing context services. The former process a Web service's request before it is passed to it, the latter process a Web service's reply before it is sent back. Of course, a context service can be both. The distinction is necessary to avoid unnecessary processing of context information. There are three ways to find appropriate context services:

First, the context block can be enriched with attributes (preService and postService) specifying the URIs of context services that should be used. A URI can either be a URL at which the service can be invoked using SOAP-HTTP or it can be the UUID of a bindingTemplate in a UDDI repository which contains information about how to connect to the context service.

Second, a Web service itself can specify which context services should be used by adding appropriate information to its UDDI metadata. These first two options are especially useful if a party (e.g., a consumer or a service provider) wants to ensure that only dedicated context services are used in conjunction with certain context types or Web services.

Third, UDDI can be used for finding context services for a given context type. Every context service which should be found this way must be associated with two tModels: the ContextService tModel and the ContextType tModel. The former marks a Web service as context service and links to a WSDL document which defines the abstract interface of a context service, i.e., that it receives a context block and an XML document as input and returns an XML document as output. As UDDI allows to specify parameters when associating a service to a tModel, it can also be specified whether the service is a pre-processing and/or post-processing service. The latter tModel is used to specify which type of context information the service is able to process by adding a parameter contextType with a value equal to the qualified name of the corresponding context block. To find appropriate context services for a context block, the context block's qualified name is determined and UDDI is searched for all services associated to both tModels and having the correct parameter values. One of these services is selected as pre-processing service, one (which may be the same) as post-processing service. Currently, the first suitable service is selected in both cases. For the future, we are going to consider the utilization of dynamic service selection [KSKK03, KSSK02] in this process.

With context services, the set of available context types can be extended dynamically at runtime. This means that a Web service can take advantage of context types which were unknown at its development time. Adding a new context type is simple: Just publish one or more context services associated to the tModels ContextService and ContextType (with appropriately set parameters). After that, when a SOAP request is received containing the new context type, it will be processed automatically utilizing one of the new context services.

4. Configuration Issues

In our approach, there are several components which can process a given context block. Additionally, a context block may be processed multiple times as it might be inserted into the outgoing requests of the Web service which received it. In some situations, consumers and also Web service providers may require more control on what components process a given context block. For example, assume a context block which requires that a Web service's reply is transformed into HTML. Such a context block should only be processed if the result is sent back directly to a consumer's client. It should not be processed if the invoker is another Web service which probably wants to process the reply, assuming that it is XML data.

Currently, every context block can have an attribute actor to specify which Web service or component should process the context block (similar to the actor attribute of a SOAP header block). We are still investigating these issues and we are going to consider them in more detail in future work.

5. Context Types

The ServiceGlobe system provides several integrated context types which are explained in this section. The Consumer context type contains information about the consumer invoking the original Web service, e.g., its name, email address, and so on. An example is shown in Figure 1. Client context information contains data about the client environment of the consumer, e.g., the hardware device or the software which is used by the consumer. The Location context type contains information about the consumer's current location, e.g., GPS coordinates. It can also include semantic location information, e.g., that a consumer is currently at work in his/her office. A DSS Constraints context block contains constraints and constraints sources for dynamic service selection (as described in [KSKK03]). The Connection Preferences context type allows to specify properties of the connections to Web services, e.g., if communication should be encrypted and/or signed. A Reply Properties context block is intended for a consumer's client. It contains properties of the invoked Web service's reply, e.g., a stylesheet which should be used to format the XML data.