In WSO2 SOA Enablement Server, there are a number of execution contexts, some of which overlap. Every execution context provides data that is accessible and shared by all instances in the same context. Every execution context also contains a generic map into which application data may be stored.

On the server side, the possible contexts are Service Instance, Service Endpoint and Call Context.

In a service, every invocation has a unique context, represented by the class org.idoox.webservice.CallContext. Before a service call, CallContext is accessible by calling the getCallContext(). (For details, please see ServiceClient Settings). One can supply it with additional data, etc. This prepared call context is active during the call on the client side and is accessible to all custom serializers, header processors and transport interceptors using the getCallContext() method found in org.systinet.wasp.webservice.Current.

The Call context provides information unique to the call and facilitates communication between the application and the different handlers like header processors, custom serializers or transport interceptors. The contextual information is accessible using the method getContextData(). On the client side the Call context accesses ServiceClientContext data and on the server side it accesses ServiceEndpointContext data.

When a new service call starts, the call context data from the previous call is cleared.

The class org.systinet.wasp.webservice.ServiceInstanceContext represents the context of a single service instance (see the section Web Service Components).

Before the call, ServiceInstanceContext is accessible using the Runtime API (see Runtime Publishing).

The appropriate instance during call can be obtained using the static method getServiceInstanceContext() found in org.systinet.wasp.webservice.Current.

A service instance context carries the service instance representation and contextual information, such as the generic application-data map. The contextual information is accessible using the method getContextData().

In the service instance context, a service can store information common to all service endpoints of this service. This is often used for data shared among a group of objects that make up a more complex service implementation.

The class org.systinet.wasp.webservice.ServiceEndpointContext represents the context of a single service endpoint.

Before the call, ServiceEndpointContext is accessible using the Runtime API (see Runtime Publishing).

The appropriate instance can be obtained during a call by using the static method getServiceEndpointContext() found in org.systinet.wasp.webservice.Current.

A service endpoint context carries the service endpoint representation and contextual information, such as the generic application data-map. The contextual information is accessible using the method getContextData(). The service endpoint context also accesses ServiceInstanceContext data.

In the service endpoint context, an application can store information unique for this particular service URL, such as the necessary authorization credentials accepted by this URL.

The sections above describe the following contexts:

There is a hierarchical relation between these contexts. All data from the Service Instance context map is accessible from the Service Endpoint context map, whose data is in turn accessible from the Call Context context map. Thus you can access data from all maps using the Call Context only.

When you need to have data accessible from all service endpoints that share one service instance, you should add this data to the Service Instance Context. On the other hand, for data accessible from a particular service endpoint, put this data only in the Service Endpoint context. Similarly, data accessible for only one call should be put in the Call Context.

When there is an identical key in all contexts, the value in the Call Context map has higher priority than the value in the Service Endpoint context map, which has higher priority than the value in the Service Instance context map. Due to this functionality, the Service Instance Context can contain default data valid for all service endpoints. Some of this data can be overridden for a particular service endpoint or a particular call only.

The following code fragment in Example 36 shows how you can take advantage of the context hierarchy:

ServiceInstance serviceInstance = ServiceInstance.create(HelloService.class);
// put in the default value for both service endpoints
serviceInstance.getContext().getContextData().put("MY_KEY", "DefaultValue");
ServiceEndpoint serviceEndpoint1 = ServiceEndpoint.create(
                                       "/demo/basic/HelloService1", 
                                       serviceInstance);
// override default value for this service endpoint
serviceEndpoint1.getContext().getContextData().put("MY_KEY", 
    "HelloService2Value");
ServiceEndpoint serviceEndpoint2 = ServiceEndpoint.create(
                                       "/demo/basic/HelloService2", 
                                       serviceInstance);