Skip to main content
Last updated May 30, 2012 15:59, by mitch.upton
Feedicon  

API Focus: Capabilities Model

Capability Model - Phases

  1. Provider deployed with advertised capabilities
  2. Client queries for capabilities and receives matching providers
  3. Client picks a provider and obtains a StateManager to do work against

Capabilities Design

The diagram below provides an overview of the capabilities interfaces.

The key interface is java.state.Capability which is implemented by BasicCapability. The JavaDoc notes that the Capability is:

 * For providers they are used to express the features / qualities of service they support.  They can
 * also be used to express default configurations, a form of capability.


The UML diagram below highlights the relationship to configuration. Note that a capability can have one or many configurations.

I did some more background reading on JSR 107 and JSR 347 as JSR 350 is positioned as supporting these. I found http://www.theserverside.com/discussions/thread.tss?thread_id=62204 particularly informative. For me it highlights a need to work closely with those JSR groups and indeed the teams which are likely to implement the APIs.

Some thoughts were:

API cleanup/elegance

  • having CoreCapabilities extending Constants at the top of the hierarchy seemed odd.

Clarify how providers advertise capabilities and consumers request them

  • I wondered if the 'advertising' is at compile time or run time. For compile time then documentation and availability of interfaces suffice. For runtime the current method of having the StateManager return a Collection of Capability looks fine as below.

 Collection<Capability> getCapabilities();


 
 
Close
loading
Please Confirm
Close