Hmm, seems like my attempt at table building below did not work well, how
about now.
Also, in 'Bindings and session id', wsa:To is obviously not the source epr.
For some reason I thought the destination address was supposed to be an epr
but as you know, it is only a URI. So I guess we could try the convention of
using a reference prop or parm in the source epr (wsa:From).
On 11/8/06, Ignacio Silva-Lepe <[EMAIL PROTECTED]> 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.
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.
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.
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.
conv - @EndSession on
endSession
calback - timeouts
specified in
- timeout (maxIdleTime
@Session
or maxAge, hardwired)
Needless to say, I most probably have missed something so by all means,
let me know.
