1
Java State Management
Mitch Upton
Jeff Trent
Presenting with
LOGO
2
Introductions
Mitch Upton - mitch.upton@oracle.com
– At Oracle for 11 years
– Spec Lead for JSR-350 – Java State Management
– WebServices Lead for Reliable Secure Profile, Clustering,
Persistence
– Former Lead on WebLogic Integration (Application Integration)
– Expert on Java Connector 1.5 (JSR-112)
Jeff Trent - jeff.trent@oracle.com
–
–
–
–
–
At Oracle for ~7 years
In Server Technologies Division
Security Lead for OC4J (previously)
WebLogic Server Team & GlassFish/Hk2
Former Spec Lead for JSR-350 - Java State Management
3
The following is intended to outline our general
product direction. It is intended for information
purposes only, and may not be incorporated into any
contract. It is not a commitment to deliver any
material, code, or functionality, and should not be
relied upon in making purchasing decisions.
The development, release, and timing of any
features or functionality described for Oracle’s
products remains at the sole discretion of Oracle.
4
Agenda
• Motivations
<Insert Picture Here>
• Goals
• A case study example (with demo)
• Challenges
• API pre preview
• Anticipated schedule
• Q&A
5
DISCLAIMER
The views expressed in this presentation are strictly
speaking my own. All members of the JCP Expert
Group for Java State Management (JSR-350) will
jointly shape this JSR, and arrive at the eventual form
of this JSR. The final form of this JSR may therefore
look very different from the opinions expressed
herein.
6
What is “State”?
• A unit of business data we call a ‘value’
• State is separate from the business logic that consumes
and manipulates it
• A value is uniquely identified by a key within a “scope” and
“namespace”
• E.g., <jsessionid> could be the key to the Session [scoped] state for
a user in an application namespace.
• Generally represented as values in a java.util.Map
• Typically transient in nature (e.g. it will be created, have a
finite lifetime, and be destroyed)
7
a few examples...
• Servlet
• HttpSession
• Web Services
• Reliable Messaging Sequence State
• Secure Conversation Tokens
• Conversational State
• JSF
• StateHolder
• CDI
• @RequestScoped
• @SessionScoped
• @ApplicationScoped
• @ConversationScoped
8
How is “State” managed today
• Conventional implementation strategies
• In Memory / File
• Database
• Cluster/Grid storage (e.g., Coherence, ActiveCache)
• Traditionally managed by a “Container” in the Platform
Provider
• Each container in Java EE handles state
• State managed manually using java.io, javax.sql, etc. in
Java SE environment
• All this management is essentially custom code written for
each purpose
• Clearly there is overlap here
9
• Motivations
<Insert Picture Here>
• Goals
• A case study example (with demo)
• Challenges
• API pre preview
• Anticipated schedule
• Q&A
10
Motivation #1
• Eliminate redundant code needed for state management
• Allow user code and containers to focus on other areas
• Modularize the EE Platform
• Address overlap and fragmentation - many similarities in existing
EE containers / specs (servlet, ejb, cdi, etc.)
• Consistency of Implementation (e.g., expiry/timeout, configuration,
storage)
11
Motivation #2
• We need a “File System” for the Cloud
• Hosting applications with varying QoS requirements for state
• QoS requirements for state in any app can evolve over time
• Applications may collaborate in ways we can’t envision.
Management of state is key to sharing it.
• HA & recovery from catastrophic failures by having state managed
(and persisted) outside the service tier
12
Motivation #3
• Cloud environment means more
fluid relationships between
applications, and how we
manage state
• Existing Java EE APIs don’t
address this need (e.g. HTTP
Session isn’t enough)
• Wouldn't it be nice to share
state across two or more
applications?
• Sometimes you want others to
“play” in your sandbox
13
Motivation #4
• We need to continue to open up the EE Platform
• New vendor opportunities
• Extensible solutions
• We can offer new capabilities to the ME Platform
• State on mobile devices
• Abstract physical storage into API
14
Motivation #5
• There is not a one size fits all solution. We need the EE
Platform to support additional scaling options
• Varying degrees of QoS requirements (by environment and time)
• Hybrid, best-of-breed providers
• State management providers can be scaled from the RI outward to
massive commercial applications using the same API.
Commercial
open source
15
And of course...
We want:
*** Available in SE too!
*** Standards based!
16
• Motivations
<Insert Picture Here>
• Goals
• A case study example (with demo)
• Challenges
• API pre preview
• Anticipated schedule
• Q&A
17
Intended Audience
• Platform providers …
• Container writers would be API callers/SPI implementors to
the state management framework, or
• Container writers would add pre-built state managers to the
state management framework at runtime
• Consumers …
• Applicable for SE, EE, (and possibly ME) usage
18
Goal #1
• Provide a common, logical abstraction to “state”
management
caller
caller
state-management
Built-in Provider #1
Third-party Provider #2
Custom Provider #3
*
19
Goal #2
• Further modularize the platform. Containers and
applications are both consumers of state management.
Servlet
Container
Your EE
Application
state-management
Built-in Provider #1
Third-party Provider #2
Custom Provider #3
*
Java SE
Application
20
Goal #3
• New Possibilities for easily sharing state across
applications and environments
Remote
i-net User
Directly share
Session data
across
applications
app1
app2
EE Platform
state-mgt
Session Data
21
Goal #3 (Continued)
Example for blending SE with EE
Remote user
calls customer
service to assist
with order placement
Remote
i-net User
HttpSession
servlet
EE Platform
state-mgt
In-house
CSR
SE / CRM App
state-mgt
Session Data
22
Goal #4
• Allow producers and consumers of state to declare their
requirements around managing that state
• This fosters an ‘ecosystem’ for state management
• Supports dynamic deployment of applications that
can declare what they need as they are deployed
• Supports a market for third-party providers of state
management and platform providers to meet those
requirements
• Define an extensible declaration system to support new
capabilities and open configuration model
23
Goal #4 (Continued)
• Define a capabilities-based provider resolution model
(capability extension model)
Examples:
• Listener – subscribe to value changes and lifecycle events
• Transactional – simple to advanced (JTA / XA compliant)
• Atomic – allow for atomic operations to occur (move decision
logic to the data instead of pulling data into logic)
• Expirable – automatic cleanup of state (inactivity or wall
clock)
• Secure – Cryptographic strong keys; transport level; storage
level
• Queryable – simple (key, alternate key) to advanced
(conjunctive, disjunctive, etc.)
24
Goal #4 (Continued)
Capabilities-based provider resolution model
Requirement
Caller
#2
Built-in Provider #1
Must-be:
Transactional
Must-be:
Queryable
Nice-to-have:
Transactional
state-management
Caller
#1
Third-party Provider #2
A
T L T
Custom Provider #3
Q L
*
Caller
#3
“The one that
Application X is
using for Session
state”
25
Case Study / Demo
26
Web Services Case Study
• Simple web services are stateless
• Advanced web services are stateful
• WS-ReliableMessaging (WS-RM)
• WS-SecureConversation(WS-SC)
• WS-MakeConnection (WS-MC)
• Asynchronous Web Services
• Client/Service-Side Considerations
• Either can be hosted in Java EE, or Java SE
• State storage must be available everywhere
27
Web Services Case Study
Client and Service Containers
• Different QoS
• Different Capabilities
Client Container
Service Container
Request
Service
Client
Response
State
State Management
• Must Adjust for Container
• Must Give Best-Match
State QoS
28
Web Services Case Study
Client/Service Host Container Possibilities
• Client
• Java SE (Standalone VM)
• Java EE (Single Server)
• Java EE (Cluster of Servers)
• Oracle Exalogic
• Service
• Java EE (Single Server)
• Java EE (Cluster of Servers)
• Oracle Exalogic
29
Web Services Case Study
• The Client/Service Container can *change* over
the lifecycle of an application
• For testing, out-of-box experience after install,
development, etc. we might use ‘In Memory’ state
• As time goes on, we may stage the app into more
robust containers and need more robust state
management (e.g. DB-based)
• For our demo, we show the same client code
executing using two different state management
providers
• In-Memory
• JDBC
30
• Motivations
<Insert Picture Here>
• Goals
• A case study example (with demo)
• Challenges
• API pre preview
• Anticipated schedule
• Q&A
31
Challenges
Security
JavaEE permissions (app. vs cont.)
Sandboxing is the default
Context determination
Tenancy
Lifecycle
Managing cleanup
Timeout & expiry
SE
Portability
Adoption
Capability extensions
Configuration
In other EE Specs
(e.g., Servlet & CDI) –
we will not dictate to
other specs that they
must integrate
32
One Last Disclaimer Regarding Adoption...
• It will be up to the other EE Specifications to decide
if/how it will integrate with State Management.
• EE 8 is the likely time frame for other specs to start
integrating.
• Preview (non-spec based) implementation available
earlier in GlassFish RI for Servlet.
• Will strive to add new providers (e.g., Amazon's S3, JSR-107
and/or 347 wrappers).
33
Lifecycle and Configuration is easier for container
EE
App
Server
state-management
Application Scoped
State Manager
Container
Managed
Session Scoped
State Manager
SE
SE-Provider1
SE-Provider2
Who is
managing
lifecycle
and config?
34
• Motivations
<Insert Picture Here>
• Goals
• A case study example (with demo)
• Challenges
• API pre preview
• Anticipated schedule
• Q&A
35
Adding a Provider
StateManagement stateMgmt = BasicStateManagement.getInstance();
// Create and register a provider
StateManagerProvider provider = new
InMemoryStateManagerProvider(“MyInMemoryStore”);
stateMgmt.addProvider(provider);
36
Finding and Using a Provider
// Form a query to get the provider and StateManager we need
Query query = stateMgmt.getResolver().newQuery();
query. requiredScopeName(MyObject.class.getName());
BasicInterfaceCapability<StateQuery> cap = new BasicCapabilityInterface<StateQuery.class>;
query.mustHav(cap);
// Get the provider
provider = stateMgmt.getResolver().getBestProvider(query);
StateManager<MyObject> mgr = provider.getOrCreate(query);
MyObject obj1 = new MyObject(“Object 1");
obj1.setOtherObjectId(“Object 1a");
// Store initial copy of object into store
String key = mgr.reserveKey();
State<MyObject> state = mgr.getOrCreateStateNow(key, obj1);
// Controlled “protective” cast / narrowing to a StateQuery
StateQuery sq = mgr.as(StateQuery.class);
37
• Motivations
<Insert Picture Here>
• Goals
• A case study example (with demo)
• Challenges
• API pre preview
• Anticipated schedule
• Q&A
38
Anticipated Schedule
Q3
1
Q4
2
2012
Q1
3
Q2
4
Q3
5
(1) Java State Management JSR approved (JSR-350)
(2) Expert group formed
(3) Early draft of specification completed
(4) Public review of specification
(5) Final release (incorporation into EE spec)
39
What is the relationship between Java State
Management and JCache [JSR-107] and JSR-347?
• State Management is about resolving to the right QoS [set of]
Providers
• JSR-107 and 347 will dictate a fixed set of required and optional
interfaces whereas State Management will not
• JSR-107 and 347 will be primarily about caching – whereas a
State Management provider might not have anything to do with
caching
– But... a JSR-107 and/or 347 provider will be mappable to State
Management Provider
• JSR-107 and 347 will be more application facing (via CDI
annotations, etc.) whereas State Management will likely be more
provider facing...
– And strictly API based
40
• Motivations
<Insert Picture Here>
• Goals
• A case study example (with demo)
• Challenges
• API pre preview
• Anticipated schedule
• Q&A
41
Q&A
42
<Insert Picture Here>
Appendix
• http://jcp.org
• http://java.net/java-state-management
43
2011 Fusion Middleware Innovation Awards
SOA, AIA, BPM
Fusion
Development &
ADF
Data
Integration
Join us to congratulate this year’s winners.
Cloud
Application
Foundation
Enterprise 2.0
Meet This Year's Most Impressive Customer Projects
Session #27740
Moscone West, Room 3007
EPM & BI
Identity
Management
Tuesday, October 4, 11:45am-12:45pm
Co-Sponsors
39
44
45