Java State Management

2. Java State Management Mitch Upton Jeff Trent Presenting with LOGO

3. 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

4. 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.

5. Agenda <Insert Picture Here> • Motivations • Goals • A case study example (with demo) • Challenges • API pre preview • Anticipated schedule • Q&A

6. 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.

7. 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)

8. a few examples... • Servlet • HttpSession • Web Services • Reliable Messaging Sequence State • Secure Conversation Tokens • Conversational State • JSF • StateHolder • CDI • @RequestScoped • @SessionScoped • @ApplicationScoped • @ConversationScoped ...

9. 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

10. <Insert Picture Here> • Motivations • Goals • A case study example (with demo) • Challenges • API pre preview • Anticipated schedule • Q&A

11. 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)

12. 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

13. 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

14. 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

15. 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

16. And of course... We want: *** Available in SE too! *** Standards based!

17. <Insert Picture Here> • Motivations • Goals • A case study example (with demo) • Challenges • API pre preview • Anticipated schedule • Q&A

18. 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

19. Goal #1 • Provide a common, logical abstraction to “state” management state-management Built-in Provider #1 caller Third-party Provider #2 caller Custom Provider #3 *

20. Goal #2 • Further modularize the platform. Containers and applications are both consumers of state management. state-management Built-in Provider #1 Servlet Container Third-party Provider #2 Your EE Application Custom Provider #3 * Java SE Application

21. Goal #3 • New Possibilities for easily sharing state across applications and environments Directly share Session data across applications Remote i-net User EE Platform app1 app2 state-mgt Session Data

22. Goal #3 (Continued)Example for blending SE with EE Remote user calls customer service to assist with order placement Remote i-net User In-house CSR EE Platform servlet SE / CRM App HttpSession state-mgt state-mgt Session Data

23. 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

24. 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.)

25. Goal #4 (Continued)Capabilities-based provider resolution model Requirement state-management Caller #1 Built-in Provider #1 Must-be: Transactional Third-party Provider #2 Caller #2 A T L T Custom Provider #3 • Must-be: • Queryable Nice-to-have: • Transactional Q L * Caller #3 “The one that Application X is using for Session state”

26. Case Study / Demo

27. 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

28. Web Services Case Study • Client and Service Containers • Different QoS • Different Capabilities Client Container Service Container Request Service Client Response • State Management • Must Adjust for Container • Must Give Best-Match QoS State State

29. 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

30. 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

31. <Insert Picture Here> • Motivations • Goals • A case study example (with demo) • Challenges • API pre preview • Anticipated schedule • Q&A

32. Challenges Security Lifecycle JavaEE permissions (app. vs cont.) Sandboxing is the default Context determination Tenancy 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

33. 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).

34. Lifecycle and Configuration is easier for container EE state-management Application Scoped State Manager Container Managed App Server Session Scoped State Manager SE SE-Provider1 Who is managing lifecycle and config? SE-Provider2

35. <Insert Picture Here> • Motivations • Goals • A case study example (with demo) • Challenges • API pre preview • Anticipated schedule • Q&A

36. Adding a Provider • StateManagement stateMgmt = BasicStateManagement.getInstance(); • // Create and register a provider • StateManagerProvider provider = new InMemoryStateManagerProvider(“MyInMemoryStore”); • stateMgmt.addProvider(provider);

37. 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);

38. <Insert Picture Here> • Motivations • Goals • A case study example (with demo) • Challenges • API pre preview • Anticipated schedule • Q&A

39. Anticipated Schedule 2012 Q3 Q1 Q3 Q4 Q2 1 2 3 4 5 • Java State Management JSR approved (JSR-350) • Expert group formed • Early draft of specification completed • Public review of specification • Final release (incorporation into EE spec)

40. 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

41. <Insert Picture Here> • Motivations • Goals • A case study example (with demo) • Challenges • API pre preview • Anticipated schedule • Q&A

42. Q&A

43. <Insert Picture Here> Appendix • http://jcp.org • http://java.net/java-state-management

44. 2011 Fusion Middleware Innovation Awards SOA, AIA, BPM Fusion Development & ADF Data Integration Enterprise 2.0 CloudApplicationFoundation EPM & BI Identity Management Join us to congratulate this year’s winners. Meet This Year's Most Impressive Customer Projects Session #27740 Moscone West, Room 3007 Tuesday, October 4, 11:45am-12:45pm Co-Sponsors 39