RE: [wsrp-interfaces] Cookies and HTTP

[Andre Kramer <andre.kramer@eu.citrix.com>]

I may have missed some of the session / load balancing discussion fine
points raised on this
thread but I want to also advocate a no cookie approach and attempt a
summary :-)

My understanding is that .NET Web Services, which are inherently stateless,
also provide for
(http level) session support on a per-.NET SOAP http client basis, allowing
client state to be
maintained in the same way as for other ASP.NET Web applications. But I
don't know how
interoperable this HTTP session support is with other SOAP stacks. The
session state must
be kept on a central state server or in a remote database (adding fault
tolerance) if load balancing
is to be used. Distributed locking is done to address concurrent updates to
a client session.
The Web server runtime may time out a session unilaterally, so WRSP calls
may still want to
include a "session ID" in calls to check against one previously stored in
sessions, for example,
to fail calls that are not in the "scope" of the current Web session.
However, since the state
may be serialized and shipped between Web servers (and the db) the state
should be small
and not often accessed concurrently in multiple (load balanced) Web
requests. Load balancing
with server affinity can help, but SSL (and NAT etc) can defeat such load
balancing with memory
schemes. If SSL is used then http cookies can obviously not be seen by the
load balancer
(unless a HTTPS to HTTP reverse proxy or some other SSL terminating network
component
is used). Therefore, I don't think it is reasonable to rely on this approach
to implement a
remote Portlet session or scope that spans two or more Portlets. Instead we
need a scheme
that explicitly keeps related Portlets (that are, say, scoped by a JSR 168
application session)
on the same Web server / same VM.

The SOAP extensions for routing (protocol extensions such as WS-Routing
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/
html/wsroutspecindex.asp
or intermediate components, such as IBM's Web Service Gateway
http://www.alphaworks.ibm.com/tech/wsgw ) that I am aware of are incomplete
or proprietary,
so we are pretty much left with application level (i.e. WSRP protocol)
support.
Here we have some options:

1) A Consumer is told a specific SOAP end-point address to use. For example,
when creating a
WSRP Session using the generic service a 2nd URL can be returned for a
specific service instance
(i.e. Web server) that the consumer should use for further calls that are
scoped in the same way
(group Session or possibly a some other Entity relationship). The
registerConsumer() call could 
be used in this way, with heavy usage consumers "registering" several times.
The disadvantages
are: that the consumer must manage multiple endpoints; failure is not
mask-able;
multiple IP addresses and DNS names must be visible outside the producer's
firewall.

2) A consumer could be re-directed to the right producer side server (e.g.
when the producer
discovers that a scope / session already exists) using a special SOAP reply.
The consumer
needs to handle this case by re-trying the request using the returned
re-direct URL.
Managing multiple endpoints also makes this ugly at the application level
(but a fine candidate
for a new generic protocol layer).

3) The producer service handles load balancing transparently to the consumer
by locally forwarding
requests to the right server. The routing info can be encoded in a (opaque)
sessionID passed back
to the consumer but a mapping needs to be maintained if the consumer
allocates session IDs.
Obviously, here we have an extra cost of call forwarding but this is what
higher level load balancing
solutions have to do anyway and can be made simpler by including session IDs
in SOAP headers
so that the whole SOAP request does not need to be parsed.

4) The producer could use a distributed protocol to maintain the shared
scope / session,
e.g. some form of distributed atomic multicast. This can be more efficient
than a ship via
serialization to and from a database. The state could be partitioned and
fine grained locking 
could be used. As in 3, consumers just invoke the single endpoint and are
not aware of 
producer load balancing.

The above could be combined with Web server HTTP session support (the
application level support
providing locality of reference for a user's Portlets with occasional use of
Web session serialization
to recover from miss-direction or failure) but WSRP consumer would then
still need to keep multiple 
clients open (one per shared session scope - user or application) and http
session timeouts would 
need to be addressed. I think the only reasonable approach here would be to
call registerConsumer()
(or within a consumer registration initiateSession()) using different SOAP
client instances, allowing
the producer to set HTTP cookies or return a URL to use in subsequent calls
(5).

However, I believe WSRP should be secured with SSL and allow load -
balancing without special
(HTTPS) network components or mulitple external SOAP endpoints. I therefore
favour the consumer
transparent approaches (3 or 4) to use with producer allocated (group)
session IDs. The consumer
can still hint which entities are related, if it wishes (by its own unique
"affinity" id), but the producer
should be able to return its own opaque session ID so that it may optimise
the load balancing step.
This identifier can also be redundatly utilized as a HTTP session cookie but
this should be optional 
and only aids request routing, with the producer service implementing some
(SOAP or application 
level) internal logic to route requests.

In summary, our SOAP based protocol should only allow the consumer to
communicate any sharing
requirements it may have (JSR 168 Portlets for a user), and require that the
producer must be able
to pass back a session identifier (even if the consumer has indicated no
explicit relationships) that
the consumer must include in follow on calls, preferably in a SOAP header,
to the producer
service on the generic service interface facade (3,4)? I could be persuaded
that certain calls
(registerConsumer() and initiateSession() return a new endpojnt address (1)
and that HTTP cookies
could be optionally set on these calls (5) to make use of HTTP level load
balancing optimizations
(if present).

What do people think?