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



Andre - if I understood the scenario correctly there might be a problem in
the approach have in a session bean (as the sync point) issue a SOAP
request. If the server is under heavy load it might happen that the request
queue is full when the bean issues the request. This is a deadlock
situation. Would this be possible or am I missing an important point in
your description?


Best regards
Carsten Leue

-------
Dr. Carsten Leue
Dept.8288, IBM Laboratory Böblingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401



|---------+---------------------------->
|         |           Andre Kramer     |
|         |           <andre.kramer@eu.|
|         |           citrix.com>      |
|         |                            |
|         |           08/05/2002 10:21 |
|         |           AM               |
|---------+---------------------------->
  >-------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                               |
  |       To:       "'Gil Tayar'" <Gil.Tayar@webcollage.com>, interfaces <wsrp-interfaces@lists.oasis-open.org>, wsrp-wsia        |
  |        <wsrp-wsia@lists.oasis-open.org>                                                                                       |
  |       cc:                                                                                                                     |
  |       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