Requirements for an API for Context Negotiated Services

Mark Baker
Sun Microsystems Inc.


A myriad of position dependant services are soon to be unleashed upon us as a few additional bits (location) are made available to services on the Web. These bits are a unique artifact of mobility; PCs are, by and large, fixed in place for their lifetime, whereas PDAs and mobile phones are constantly on the move in our pockets, or on our belts.

Physical location isn't the only thing that changes as we go increasingly mobile. Since these devices are with us 24 hours a day, they are conceivably privy to our interactions with other devices and people (more precisely, other people's devices) in many contexts; in the car commuting, at home playing with the kids, at a board meeting, on the phone with a customer. Making this sort of contextual information explicit and available to other devices and Web services, will allow extremely relevant (to one's current context(s)) services to be provided, and should create a huge market of context based services.

Undoutedly most of these services will be implemented over the Web, at the end of a HTTP connection. However, there is much value in leveraging the benefits of mobile code. Those include;


It is out of scope for this API to tackle wire protocols for service discovery or announcement. That is best handled by protocols such as Salutation (, SLP (, or the Jini ( protocols.

It is also out of scope how the implementation of this API becomes aware that a context change has been made. This is because a context change could be performed by any number of mechanisms;


Context and Lifecycle Management

A service should be able to have its current operating context saved for later retrieval, should a context change occur. When the context is resumed, the service should save its existing context and switch to the new one.

A context switch could also manifest itself as an entirely new service implementation, replacing the currently operating one for the duration that the context is maintained. This will involve managing the lifecycle of the service; suspending the existing one, and starting a new one.

Service Containment and Composition

Just as Web based network services are composed via proxies, locally implemented services should also be able to be composed with other local and remote services. To facilitate these compositional hierarchies, services should be able to logically contain one more other local or remote services.

With local services, composition will be straightforward; a subordinate service will be bound to an aggregating service by being added as a contained entity. This will bind the output of the contained entity to the input of the container.

See the next section for the requirement for composing remote and local services.

A Common Local and Remote Composition Model

Remote services already have a model for composition; the Web proxy/filter model. For the sake of simplicity, the local API should use this same model. More concretely, this means that local services should communicate via document transfer, not via procedure/method invocation. This is similar to XBeans ,

In order for remote services to be accessible via that same API, the container will need to transparently bind remote document transfer streams to a container; no local proxying entity need be required for this to occur.

No Parallel Composition

Containers must only contain one active service (an inactive one could be swapped out) at any given time. This greatly reduces the complexity of implementation as services are restricted to communicating with other services via containment, rather than through peered structures like event notifications. This requirement means less powerful composition, but much remains possible with only serial composition.

Dynamic Loading of Code

Services must be able to be loaded from the network at runtime (though how its loaded is out of scope), installed locally, and made available for composition with the existing services already on-device.