COS builds on Rio to provide an environment where multiple ensemble applications can coexist using shared resources and operate securely in a distributed computing environment. A COS application is a named collection of clients and shared data, together with a an ensemble of services, that can be submitted to a resource provision grid for execution.
Like any good application, COS applications can be started, stopped and removed from the environment, upgraded and redeployed without interfering with other running applications.
This is essential for production systems and perfect for concurrency in development environments where many developers wish to run overlapping versions of the same code.
COS applications provide 100% continuity of service based on the contiguity of services running in the ensemble. A contiguous component can start and stop, and resume operation from exactly where it left off. This type of service creates a situation where each and any service can be taken off-line, upgraded, and restarted with nothing more than a performance degradation to active applications.
COS also allows you to specify dependencies between service runs. This is useful when one service depends on the result of another; in this case, the service distribution model is extended to message dependent services in the ensemble on the completion of all its dependencies.
COS provides a clean interface, CosConnectable, that enforces the methods used by 3rd party code (IE Crudlet taglib) to access any named service ensemble. It maps closely to the original Crudlet specification itself, with create, retrieve, update, delete, lifecycle and exists methods. There was no need for a 't' however and instead we have added a notifyEvent() method that allows client apps to listen for remote events from the space.
Lifecycle events provide persistent, guaranteed, service ensemble events that are not executed immediately on delegation to the COS. They are instead submitted along with a trigger condition object, that determines when and how often the ensemble event should be executed. These events are placed into the Cos as service ensemble events when a matching trigger event arrives in the space.
The state of the lifecycle service is stored in the JavaSpace, allowing multiple competing instances of the Lifecycle service in scalable designs.
There is a full discussion of the Cos Event Model at http://www.pronoic.org/cos_event_model.html