[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, 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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC