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

["Tamari, Yossi" <yossi.tamari@sap.com>]

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>