Ok, I'll re-re-start the thread, you can disregard the previous two tries,
apologies for the inconvenience.
I'd like 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:From source
endpoint reference header, given that wsa:To is only a URI.
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)
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
start - @reference
conv injected
continue - hold on to ref
conv - get ref as parm
end - @EndConversation
conv - @EndSession on
calback
- timeout (maxIdleTime
or maxAge, hardwired)
later
start - CompositeContext.newSession
conv
continue - load persistent ref
conv - CompositeContext.lookupServRef
end - ServiceReference.endSession
conv - timeouts specified in @Session
Needless to say, I most probably have missed something so by all means, let
me know.
