OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-wsia message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [wsrp-wsia] RE: [wsrp-interfaces] [wsrp][interfaces] Concallsummaries for 7/24 and 8/1


In the spec today, the session id is not passed as a cookie. Rather, it is
passed in the SOAP message. So #1 needs to be addressed for private sessions
too because there is no insurance that the conversation from a Consumer will
always reach the same server. 

Of course, if we decide to adopt passing the Session ID as a JSESSIONID
cookie, that will solve the problem, but _only_ for J2EE-aware load
balancers.

What I was trying to say is that the mapping between "our" session ID (in
SOAP) and the load balancing session id is something that needs to be solved
both for private sessions as well as for shared sessions.

I'm not certain how #2 can be done producer-side. If two simultaneous
requests from the same Consumer arrive at the producer, both will create a
shared session, where it should have been only one session that should have
been created. Thus, Mike's proposals that the Consumer either serialize the
requests for producers needing shared sessions or that the shared session
will be explicitly created. Both of these Consumer-side solutions.

As for "legacy". It was the sentiment in the F2F (and I remember we even
voted on it!) that the usage of shared sessions to implement an "eventing
mechanism" (in which an action on one portlet influences another portlet) is
not the right way to go as it occurs "behind the scenes" and does not enable
the Consumer to optimize things or participate in this event orchestration.

OTOH, shared sessions are used by today's portlets for exactly that, and
thus the concept of shared sessions should be supported, but only as a
"legacy" option which is "not recommended".

Gil

-----Original Message-----
From: Andre Kramer [mailto:andre.kramer@eu.citrix.com]
Sent: Mon, August 05, 2002 11:21
To: 'Gil Tayar'; interfaces; wsrp-wsia
Subject: RE: [wsrp-wsia] RE: [wsrp-interfaces] [wsrp][interfaces]
Concall summaries for 7/24 and 8/1


Yes, any session that is accessed concurrently from the consumer
side, with the consumer indicating a common scope, requires 1 & 2 
to be addressed. As Yossi implied, a session that is private to a
portlet is likely to be only accessed over one http connection
(at any time), from a single consumer to the producer, so a http 
session can just be used for 1, as 2 is addressed by the assumed
connection usage. The same goes for both JSR 168 session scopes 
as client (browser) http requests are for a Portal "page".

For shared session, I am proposing that 2 be done at the producer
because I believe the use case of concurrent session-sharing
consumers (truly concurrent applets that are not able to achieve
2 by themselves) is an important one and because this keeps the
protocol cleaner.

Could you please explain what you mean by "legacy" as I was not
at the f2f?

	Andre

-----Original Message-----
From: Gil Tayar [mailto:Gil.Tayar@webcollage.com]
Sent: 05 August 2002 07:47
To: interfaces; wsrp-wsia
Subject: RE: [wsrp-wsia] RE: [wsrp-interfaces] [wsrp][interfaces]
Concall summaries for 7/24 and 8/1


Yossi,

From what I follow of the shared session/load balancing discussion, it is
trying to solve two separate problems:

1. How to translate a session id in a WSRP call to something that load
balancers can understand.

2. How to ensure that multiple requests for a shared session will generate
only one.

What I (badly) tried to say in this email is that the first problem is
common to private and shared sessions, whilst the second one is relevant
only to shared sessions.

What I suggest is to separate the two discussions - first deal with the
first (and more general) one, and then when the problem of sessions is
resolved, move on to the second one (which, by consensus in the F2F, is more
of a legacy problem).

Gil

-----Original Message-----
From: Tamari, Yossi [mailto:yossi.tamari@sap.com]
Sent: Mon, August 05, 2002 09:40
To: interfaces; wsrp-wsia
Subject: RE: [wsrp-wsia] RE: [wsrp-interfaces] [wsrp][interfaces]
Concall summaries for 7/24 and 8/1


Hi Gil,

What problem are you referring to with private sessions? It seems that as
long as each portlet uses his own JSESSION cookie, the requests for this
portlet for this user in this conversation will always go to the same server
instance, and I don't think this is a load balancing issue because the load
will be balanced across different users and different portlets.

	Yossi.

-----Original Message-----
From: Gil Tayar [mailto:Gil.Tayar@webcollage.com]
Sent: Monday, August 05, 2002 9:20 AM
To: interfaces; wsrp-wsia
Subject: RE: [wsrp-wsia] RE: [wsrp-interfaces] [wsrp][interfaces]
Concall summaries for 7/24 and 8/1


Andre,

Both you and Michael have addressed the problem of load-balancing of
portlets in the context of a _shared_ session. You are correct in that there
is a problem there. But the problem is not only there - the problem arises
also in _private_ sessions. Am I missing something - is the question of load
balancing of the private sessions simple and solved?

I think we should first deal with private sessions, and then tackle the
problem of shared sessions which in essence is the same as the one with the
private sessions, but also deals with the problem of multiple simultaneous
requests to create a session.

Gil

-----Original Message-----
From: Andre Kramer [mailto:andre.kramer@eu.citrix.com]
Sent: Fri, August 02, 2002 18:54
To: 'Michael Freedman'; interfaces; wsrp-wsia
Subject: [wsrp-wsia] RE: [wsrp-interfaces] [wsrp][interfaces] Concall
summaries for 7/ 24 and 8/1


The use case that I wish to be supportable by the WSRP protocol
involves multiple remote portlet viewers running as applets 
(independent mini applications, not necessarily Java Applets) 
on a consumer. These could be running directly but independently
on a client device or could be hosted on a load-balanced consumer 
Web tier (e.g., viewed in browser iframes, rendered by independent 
consumer-side Servlets). These applets are logically grouped, 
by the consumer, to be part of the same application or application 
suite, requiring that the remote portlets are able to maintain and 
update shared application state at the WSRP producer.

Note that, as the applets are started and run independently, 
using multiple WSRP transport connections, they are not able to 
serialize their requests (between applets). All they know is a 
pre-configured application scope name (the session group id, 
a URI/UUID) which they are able to communicate to the producer.

Since there is no natural place on the consumer side to establish 
a shared initialise-only-once variable, as would be required to 
hold a producer's shared session / grouping identifier, 
as returned in an rpc to the producer creating such a server side 
shared scope, Mike's proposal can not support this 
"concurrent consumer applets" use case.


The above is the main reason why I suggested that the producer be 
required to serialize creation of the shared application scope. 
Secondary desires also covered by this sentiment include:

- Not polluting the protocol with extra serialization round trips.

- Allowing http sessions (when supported) to be used but to allow
some isolation from (i.e. masking of) http session time out.

- Allowing SSL termination at a SOAP server. (SSL sessions could 
still be load balanced by some network component.)

My previous email described very broad approaches showing how 
producers and consumers could cooperate in order to allow the
producer to establish a shared producer side scope and "route"
consumer requests to an established scope, approaching the 
producer implementation problem from a distributed application 
view point, but showing how http sessions (as commonly supported 
by Web application servers) could be leveraged.

Basically, the idea is to employ a shared session identitifier
at the transport level that can be used by load balancing 
components in their load balancing decisions, providing some 
level of affinity in directing requests, containing the same 
transport level identifier(s), to the same producer side SOAP 
endpoint (a server / node or VM). Such schemes can still 
leverage http sessions but require that the producer implement
some "application logic" to address making scope creation atomic.

My believe is that:

- In the long term, a Web service standard or standard components 
will emerge that allow SOAP Web services to maintain "sessions"
in a load balanced environment (e.g. using special SOAP headers 
and SOAP interceptors (c.f. Web reverse proxies). Then all WSRP
has to do is fill in the routing headers (could even just be an 
encoding of the SOAP session identifier in the SOAPAction http
header). Meanwhile, http sessions can be leveraged, as we believe
is a common practice in SOAP implementations. But the producer 
will have to manage http session identifiers (cookies usually), 
ensure atomic shared session creation and be prepared to forward
requests when the consumer is unable to direct the load balancing
mechanism or when the session balancing mechanisms "times out".

- Also, that Producers fall in two distinct classes: simple 
producers that may not wish to support any shared scopes for 
their entities and sophisticated producers who will wish to 
manage shared applications scopes explicitly (i.e. it's a 
distributed application).


Mike places much emphasis on an intermediate type of producer: 
One that wishes to support shared sessions but is not very
sophisticated, wishing to only rely on existing Web application 
support for the shared application state implementation. 
I am unable to meet this requirement for the above use case 
(but I argue that consumer side approaches can't either) or for 
producer side serialization in general (i.e. using only J2EE 
Servlets) but can offer a range of implementation approaches to 
show how it could be achieved in a J2EE application server or as
a distributed system. Obviously, I have not fully worked though 
any of this in detail, wishing only to give some flavour of 
possible implementations mechanisms and how they could be used 
(which I totally failed to do in my previous email).


Producer Mechanisms:

p1) Intercept requests and replies at the producer allowing 
http session identifiers (usually cookies) to be read and set.

p2) Intercept requests and forward them as a new client request 
back into the same Web application / server farm (i.e. through 
same load balancing).

p3) Intercept requests and forward them to a new location/URL 
using SOAP or RMI/IIOP RPCs.

p4) Provide a producer side serialization point, such as a EJB
(statefull) session bean with a lock (for request serialization).

p5) Provide a full distributed persistent state mechanism (a 
java.io.Serializable Java object in a database with distributed 
read/write locking). Producers can read/write the state object 
to/from the database and all access is fully r/w serialized. 
An Entity bean per shared / group session object would do 
(or expert direct use of a JDBC database).


Consumer Mechanisms:

c1) Be able to read http session identifier on incoming replies.
Be able to set the http session identifier on outgoing requests.

c2) Include transport level identifiers (SOAP headers) or in the 
WSRP protocol.

An additional optimisation:

o) Consumer may do a "warm up" http request/reply to the producer, 
just to have the transport session set. Note, this call need not 
be serialized with other consumer side activity. This is used 
1) to avoid the need to forward requests at the producer (no 
p2 or p3) or 2) stops persistent state objects bouncing between 
server nodes (optimises p5).

I'm not sure all the above can be done with standard J2EE. 
Common Web servers certainly have the required flexibility but 
Java Servlet filters and Request/Reply wrappers may not suffice.


Possible combinations of above mechanisms:

A) Consumers perform concurrent requests. If the request has no 
session cookie then the producer receiver logic (think of a 
front-end Servlet) sends the request on to an EJB (p3). 
This EJB obtains a lock, serializing all requests on it, and
checks for a global session identifier to http session mapping. 
If none exists yet, it *re-sends the request* to the producer 
receiver logic Web tier (p2). This 2nd request will be load-
balanced and comes back with a http session identifier that the 
serialization bean returns back (along with the WSRP result, 
iff optimisation (o) is not used) to the Servlet, which in turn
returns the http session identifier to the consumer. 
The EJB remembers the group session identifier to http session 
mapping and returns that, if it is invoked again in the scope 
of the same session grouping identifier. This scheme needs 
some modification to allow http sessions to time out and to 
handle failure.

B) Consumers perform concurrent requests. The producer attempts 
to access an EJB entity bean using the the shared group session 
id as a key (under transactional locking). If none is found it 
creates one to become the session object (p5), allocates a http 
session in the usual way and returns the session identifier back 
to the client (p1). 

C) The above two schemes could be combined so that consumer 
requests are directed to a common server/node with high likelihood. 
This prevents the persistent shared session object trashing between 
server nodes and the database. The serialization servlet and its 
common http session identifiers maintain locality, while the 
persistent Entity bean provides fault-tolerance. I have attempted 
a rough sketch of this combination (see attached slides) 
but not everything (such as interception points and bean creation) 
is detailed. Slide 2 uses optimisation (o), to avoid forwarding the
WSRP request, simplifying the diagram.


As I already mentioned above, a sophisticated producer will wish to 
provide its own implementation of the shared state (p5). It is my 
opinion that it is better to only use the http session for the 
*private state* of an Entity, allowing the producer to fully exploit 
load-balancing scalability. The other producer mechanisms are then 
not required but a industrial strength implementation of shared 
portlet group state (p5) is. My favourite candidates technologies 
for this would be: JavaSpace or reliable atomic group multicast.

I hope I have provided enough of a sketch for people to decide that
a) the "concurrent consumer applets" use case is worthwhile 
supporting and b) that producer side (consumer transparent) shared 
session management is feasible in a J2EE environment.

regards,
Andre


-----Original Message-----
From: Michael Freedman [mailto:Michael.Freedman@oracle.com]
Sent: 02 August 2002 00:36
To: interfaces; wsrp-wsia
Subject: [wsrp-interfaces] [wsrp][interfaces] Concall summaries for 7/24
and 8/1


We have been discussing how to account for running in load balanced
[http based] app servers.  The main issue involves establishing the load
balancer key.  In http environments this is the http session represented
in a cookie.  Both primary producer environments we are targeting, j2ee
and .net,  tie http sessions to a notion of a (web) application.  I.e.
an http session is a shared session to entities running in the
application.  We are seeking a way that ensures producers can properly
and safely establish such a shared session though it may be being called
concurrently by the consumer.  The sentiment appears to be:
     a) we continue to support/expose the private entity session model
discussed at the F2F.
     b) we isolate the transport issues outside the protocol by
requiring the producer solve the concurrent create problem internally.

Mike F. has indicated he is skeptical we can describe a reasonable
solution for (b) and has suggested the serialization required to
initialize this environment should be managed by the consumer and
supported via the protocol.  He suggested adding a signature called
either "connect" or "initProducerSession" or "initTransportSession".

Andre K. who originally proposed some mechanisms for supporting (b) will
provide a more detailed explanation as it would work in a J2EE/JSR 168
environment.  This will be used to validate either the feasibility of
the current sentiment or Mike's skepticism.
      -Mike-


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC