Skip to main content
This revision made October 03, 2012 17:34, by mitch.upton


Design Goals


  1. To allow clients to express their requirements for state management without regard to the specific mechanisms that will be used to meet them.
  2. To free clients from understanding the details of state management, allowing them to focus on the use of state within their application.
  3. To match up clients with the state management provider that best meets the requirements they specify. Clients express these requirements by asking for 'capabilties' that should be supported by any state management provider they will use.
  4. To allow state management providers to innovate and provide unique value to state management clients (this is achieved by providers implementing and declaring capabilities and by the StateManagement runtime matching clients to their 'best fit' provider)
  5. Make core interfaces lean, such that:
    1. any provider can implement them fully (without having to leave some methods unimplemented only to throw UnsupportedOperationException)
    2. users need not write code to handle exceptions raised by using 'unimplemented' methods in the provider.
    3. interfaces/methods that are not considered 'core' functionality of StateManagement will be represented using capabilities.
  6. Interfaces and packages should be arranged by audience. The target audiences are user, provider, and platform. It should be clear for any audience which interfaces apply to them.

Main Concepts


State


State is a wrapper around a user-defined state value. It allows StateManagement to decorate a user-defined state value with system-defined attributes and behaviors. An instance of State has at least the following conceptual attributes:

[mupton] - Proposed alternative names:

  • StateContainer
  • StateWrapper
  • StateEnvelope
  • A globally unique key
  • A value of a user-defined type
  • Tracking information

Keys


A State instance has a globally unique key. This key can be used to identify a State instance from among the space of all other State instances, regardless of type, underlying provider, etc.

This key is composed of (at least) two components

  • A user-specified key. This key can be of any type the user desires
  • Extra information needed to generate a globally unique identifier (GUID)

The user should be able to retrieve and manipulate the State instance via the user-defined key even though the system thinks of it in terms of its GUID.

Values


A value may represent any type of data. It may or may not be a 'data structure'. Values could represent data streams, etc. Regardless of the type of data held in the value, we must have a Java type to represent the value. StateManagement does not provide any native Java type for values. The Java type is always user-defined.

The java type for a value may define an interface to manipulate or change the data within a value. If such an interface is available, the value is considered 'mutable'. If not, the value is considered 'immutable'. For example, a Java POJO might be mutable whereas a Java String is always immutable.

In order to support flexible handling of mutable and immutable values, State must include a method to make a wholesale replacement of the value contained within a State instance.

Tracking Information


The StateManagerProvider may need to track certain information about a State object, and users may find it useful to have some tracking information as well. Common tracking information might be:

  • Creation timestamp
  • Last update timestamp


StateManager


StateManager is a manager for State instances and the lifecycle control of State instances. At a minimum, StateManager must allow:

  • Create a State instance
  • Delete a State instance
  • Retrieve a State instance via its key/GUID

StateManagerFactory


This is a factory for StateManager instances, and used by clients.

StateManagerProvider


This is the main interface providers for StateManagement use to expose their capabilities. The StateManagerProvider interface is also a factory for StateManager instances. The provider that implements StateManagerProvider also implements StateManager and State, so it is the source of all behavior for those interfaces.

A provider must implement the base StateManagement interfaces (StateManagerProvider, StateManager, State). It can then choose to implement any other capabiliities it wishes. The provider makes its capabilties known via the StateManagerProvider interface.

StateManagerProvider instances are then registered (at runtime). Users can then be matched with a StateManagerProvider by performing a 'provider query' specifying any of the following:

  • Provider name
  • Capabilities a provider should support

Capability


A capability is some behavior or function that a provider offers that goes above and beyond those defined in the base interfaces for StateManagement (StateManagerProvider, StateManager, State). Capabilities may define a specific quality of service (QoS) such as the ability to durably store state data in the face of machine crashes. Capabilities may define specific behaviors like the ability to group operations on state data into transactions that allow the entire group of operations to be committed or rolled back as a unit. In some cases, these specific behaviors may require an extra functional interface, beyond those defined in the core of StateManagement.

A capability definition includes:

  • A unique name by which both clients and providers will refer to it
  • Optionally, the Java class name of any extra functional interface required to make use of the capability (for example, a transactional capability would require some method to request the commit or rollback of a transaction).
  • Optionally, configuration parameter definitions that describe any configuration that needs to be specified by the client in order to obtain the correct behavior from the capability (also in our transaction example, we may need to request a specific transaction isolation to be used for the transaction, such as 'repeatable read' or 'serializable').
Difference compared to previous revision
== State State is a '''wrapper''' around a user-defined state value. It allows StateManagement to decorate a user-defined state value with system-defined attributes and behaviors. An instance of State has at least the following conceptual attributes:[mupton] - Proposed alternative names: * StateContainer * StateWrapper * StateEnvelope * __TOC__ = Design Goals ... == StateManager StateManager is a fA globally unique key * A value of a user-defined type * Tracking information ... == StateManager StateManager is a mactonagery for State instances and clearing r for State instances and thouse for he lifecycle control of State instances. At a minimum, StateManager must allow: * Create a State instance * Delete a State instance ... * Delete a State instance * Retrieve a State instance via its key/GUID == StateManagerFactory This is a factory for StateManager instances, and used by clients. == StateManagerProvider This is the main interface providers for StateManagement use to expose their capabilities. The StateManagerProvider interface is also a factory for StateManager instances. The provider that implements StateManagerProvider also implements StateManager and State, so it is the source of all behavior for those interfaces. A provider must implement the base StateManagement interfaces (StateManagerProvider, StateManager, State). It can then choose to implement any other capabiliities it wishes. The provider makes its capabilties known via the StateManagerProvider interface.
 
 
Close
loading
Please Confirm
Close