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

Overview of StateManagement (JSR350)


What is State?


  • A unit of business data. A single unit of state is called a state object.
  • Each state object tracks a single contents object we call it's ‘value’
  • State is separate from the business logic that consumes and manipulates it
  • A state object is uniquely identified by a key. This key is composed of a namespace + simple key value and is globally unique.
    • [Mircea - so we have a 'state object' which is composed from a 'key' and a 'value'? In that case a better name might be 'state entry' - users might get the term easier as it is very similar in structure with the Map.Entry]
    • [Mitch - interesting thought. Note, we have an interface called javax.state.State in the API. Would you propose we call that java.state.StateEntry instead?]
    • E.g., For a servlet container:
      • a given session id (call it <jsession id value>) could be the simple key
      • namespace might be 'javax.servlet.Session'
      • unique key then becomes javax.servlet.Session<jsession id value>
  • A state object's value has a type, and a java binding that exposes that type for manipulation within java code
    • E.g, For a servlet container and Session state
      • state object value (or contents) would be represented as a java.util.Map.
      • keys and values in the map represent the session data the application-specific servlet code cares about
      • servlet specification/container only defines that there is a Map for the session, and that each has a unique id, and not the keys/values within the map
  • State objects are created, have a finite/specified lifetime, and are then destroyed. This lifetime is application-defined and may range from fractions of a second to years. The lifetime might be enforced by the application, or by the state management layer.


Examples of State


  • Servlet
    • HttpSession [lifetime is usually short once session is idle, enforced by servlet container]
  • Web Services
    • Reliable Messaging Sequence State [protocol defines max lifetime and an idle timeout. Can live for seconds to years]
    • Secure Conversation Tokens [protocol defines lifetime, but usually it is short for security reasons]
    • Conversational State [arbitrary lifetime specified by user, can be seconds to years]
  • JSF
    • StateHolder
  • CDI
    • @RequestScoped
    • @SessionScoped
    • @ApplicationScoped
    • @ConversationScope


What does it mean to 'Manage' State?


  • Store and catalog state objects
  • Retrieve state objects
    • Via a primary key (single state object returned)
    • Via some type of query (zero or more objects returned)
  • Handle expiry and purging of state objects to avoid infinitely expanding pools of data
  • Handle updates/removals of state objects with a specified QoS, such as...
    • Concurrency control (isolating individual consumers from the updates of others)
    • Redundancy
    • Fault tolerance

A system that intends to manage user state objects should support pluggability of multiple 'providers' that can bring different capabilities to bear for different customer needs. A provider of state management services (hereafter known as a state management provider) may have capabilities that make it more or less appropriate for a given scenario than another provider.

Why JSR 350 when we have JPA/JDBC/etc.?


Goals of the StateManagement JSR


  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 provider to innovate and provide unique value to state management clients (this is achieved by matching clients to their 'best fit' provider)

For example

  • a given environment may contain many providers for state management.
  • a client may request:
    • to manage Java objects of type com.myco.Foo
    • to enforce a specific lifetime for Foo objects
    • that Foo objects be managed in a durable fashion, surviving host failures, etc.
    • to query for Foo objects using various fields available on Foo objects
  • state management then pairs the client up with a 'best match' provider
  • client can work with Foo objects with no regard to how or where those objects are stored.
  • client doesn't have to worry about resource usage issues, availability guarantees, topology concerns, etc.
  • client focuses purely on providing value derived from manipulating/displaying/etc. Foo objects.

What is a 'Capability'


A capability is some behavior or function that a provider offers that can be expressed in a programmatic way. 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.

A capability definition includes:

  • A unique name
  • 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').

Relationship between State Consumer and Producer (JSR350 View)


JSR347 View (JSR350 as Consumer)


JSR347 View (JSR350 as Producer)


Difference compared to previous revision
** Redundancy ** Fault tolerance A system that intends to manage user state objects should support pluggability of multiple 'providers' that can bring different capabilities to bear for different customer needs. A provider of state management services (hereafter known as a state management provider) may have capabilities that make it more or less appropriate for a given scenario than another provider.== Why JSR 350 when we have JPA/JDBC/etc.? == Goals of the StateManagement JSR # To allow clients to express their requirements for state management without regard to the specific mechanisms that will be used to meet them.
 
 
Close
loading
Please Confirm
Close