On Nov 8, 2006, at 11:18 AM, Ignacio Silva-Lepe wrote:
I'd like to re-start this thread to get started on implementing
conversational services according to the assembly and c+i for Java
specs.
The following items need to be addressed:
SessionScopeContainer - A new class that needs to be created, in
addition to
HttpSessionScopeContainer, since this latter class seems to be aimed
specifically at http sessions. Perhaps the two could be combined
into a more
general class but I'd like to hear first whether people think this
makes
sense (or was even the initial intent). If a separate class is
created, we
may need to use a similar technique of passing a session id in the
work
context to retrieve the corresponding correlated component
instance, unless
this technique was not intended to be further used.
I think it may be easier to keep a separate class. For the session
scope container, we may later want to swap it for an app server
specific hook that persists instances in the Servlet context so they
can be failed over.
Session id in message - A new field would be added to a
o.a.t.spi.wire.Message to convey the session id within the local
confines of
a composite. This session id would then be turned into and retrieved
from whatever represenation it takes in any given binding (more on
that
below). It may be useful to provide common session id function for
bindings
in o.a.t.spi.extension.ReferenceExtension and
o.a.t.spi.extension.ServiceExtension as appropriate.
I would call this "conversation id". Having it in the message may be
alright but thinking about it, this may be problematic. In the SCA
specs, the boundaries of a conversation are defined by the last
remotable service a request went through (I think this may be a bit
confusing and we may want to change it in the spec so it is the first
remotable service a request entered in a composite). Also,
conversational id needs to be available from the context. Do you
think it would be better to propagate the id within the WorkContext
and only flow it in the message when the latter leaves the confines
of a composite? I think at some point we are going to need to place
the id in the WorkContext, specifically when an invocation is
dispatched to user code (i.e. a component implementation). In this
case, the binding would still be responsible for retrieving the id
and propagating it as it sees fit.
The scope container will also need to retrieve the current id and
having it on the WorkContext is how we do it with HTTP sessions. I
think this may be easier than trying to propagate the id directly
through to the scope container.
If we do this, the non-blocking bridging interceptor will need to
know to propagate this or we will need to insert another interceptor
to do so.
However, the one drawback to this is that conversational services
Bindings and session id - Each specific binding would define its
own way of
representing the session id and conveying it across the wire.
Specifically,
for binding.ws, an initial approach would be to use WS-Addressing,
with
other approaches (such as WS-RM) coming later. Since WS-Addressing
does not
provide explicit support for session ids, we could use the
convention of
adding it as a reference property or parameter in the wsa:To source
endpoint
reference header.
I believe Microsoft has a convention for doing this with WS-
Addressing...I'll ask around. It may give us interop with .NET.
Using the conversation lifetime summary in sec 1.5.2.5 of the c+i
spec as a
template, here's an attempt at outlining the specific features of
conversations we can tackle and when:
initially later
start - @reference -
CompositeContext.newSession
conv injected
continue - hold on to ref - load
persistent ref
conv - get ref as parm -
CompositeContext.lookupServRef
end - @EndConversation -
ServiceReference.endSession
conv - @EndSession on - timeouts
specified in
@Session
calback
- timeout (maxIdleTime
or maxAge, hardwired)
Needless to say, I most probably have missed something so by all
means, let
me know.
I'll continue on the persistence stuff related to durable
conversations and let's iterate through this. I think we may also
have some spec feedback related to being able to specify whether a
conversation is durable. This seems like a QoS. For example, some
conversations I may not want to persist in a durable fashion, instead
just holding them in memory. This will probably be the case for
conversations that never cross a remote boundary or those that do not
need to survive a system crash. Others I may want to make durable
because they are application-critical. It would be nice if we could
specify this as an intent or QoS, which would allow the runtime to
make this optimization.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
