How is “State” - Java.net

egyptiannorweiganInternet και Εφαρμογές Web

31 Οκτ 2013 (πριν από 3 χρόνια και 10 μήνες)

117 εμφανίσεις

1

2

LOGO

Presenting with

Java State Management

Mitch Upton

Jeff Trent

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

<Insert Picture Here>

Agenda



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.

open source




Commercial

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


Provide a common, logical abstraction to “state”
management


state
-
management



Built
-
in Provider #1

Third
-
party Provider #2

Custom Provider #3

*

caller

caller

Goal #1

20

state
-
management




Further modularize the platform. Containers and
applications are both consumers of state management.


Built
-
in Provider #1

Third
-
party Provider #2

Custom Provider #3

*

Servlet

Container

Your EE

Application

Goal #2

Java SE

Application

21


New Possibilities for easily sharing state across
applications and environments


Goal #3

Session Data

EE

Platform

Remote

i
-
net User

app1

Directly share

Session data

across

applications

state
-
mgt

app2

22

Goal #3 (Continued)

Example for blending SE with EE

Session Data

EE

Platform

SE

/ CRM App

Remote

i
-
net User

In
-
house

CSR

servlet

HttpSession

Remote user

calls customer

service to assist

with order placement

state
-
mgt

state
-
mgt

23


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


Goal #4

24


Define a capabilities
-
based provider resolution model
(capability extension model)

Examples:


L
istener


subscribe to value changes and lifecycle events


T
ransactional


simple to advanced (JTA / XA compliant)


Ato
m
ic


allow for atomic operations to occur (move decision
logic to the data instead of pulling data into logic)


E
xpirable


automatic cleanup of state (inactivity or wall
clock)


S
ecure


Cryptographic strong keys; transport level; storage
level


Q
ueryable


simple (key, alternate key) to advanced
(conjunctive, disjunctive, etc.)


Goal #4 (Continued)

25

state
-
management



Built
-
in Provider #1

Third
-
party Provider #2

Custom Provider #3

*

Caller

#1

Caller

#2

Goal #4 (Continued)

Capabilities
-
based provider resolution model

Must
-
be:


Transactional

Requirement

Must
-
be:


Queryable

Nice
-
to
-
have:


Transactional

T

L

A

T

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 Container

Service Container

State

State

Client

Service

Request

Response

Client and Service Containers


Different QoS


Different Capabilities

State Management


Must Adjust for Container


Must Give Best
-
Match QoS

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

Adoption

Portability


JavaEE permissions
(app. vs cont.)


Sandboxing is the default


Context determination


Tenancy



Managing cleanup


Timeout & expiry


SE



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

state
-
management



Application Scoped

State Manager

Session Scoped

State Manager

SE
-
Provider1

SE
-
Provider2

App

Server






SE









EE















Container

Managed

Who is

managing

lifecycle

and config?

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

Q4

Q3

Q1

Q2

1

2

3

4

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)


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

Co
-
Sponsors

SOA, AIA, BPM

Data
Integration

Cloud

Application

Foundation

Identity
Management

EPM & BI

Enterprise 2.0

Fusion
Development &
ADF

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


39

45