[no subject]

ContextService and ActivityLifecycleService

There are two  distinct "interfaces" to the  context service - the one =
that a user of a context sees (essentially Begin), which  returns a =
context that can then be sent on requests to services, and the one that =
ALS-es use to register with the context service. The intention is that =
the former be mandated, whereas the latter is optional. So, WS-Context =
would mandate how you get a context (that may be transactional, secure, =
replication enhanced, ...) but not how that context was created. =
However, for those application and service developers who wanted to =
standardise on context creation, there'd be the optional ALS. The =
WS-Context specification doesn't make that distinction between optional =
and mandatory, though WS-CF does refer to it. It follows that =
applications are aware of protocol types, but the ALS configuration is =
opaque to users of the Context Service.

WS-Context provides a mechanism for creating activities: the =
ContextService PortType. An ContextService may be used to create =
activities of more than one type. Each type is identified by a protocol =
identifier.[mcl1]

An ContextService may be used to create activities for a protocol in =
assocation with an ActivityLifecycleService.

When a Begin  message is sent to the ContextService, it contacts each =
registered ALS to get it to send back a context element for the ultimate =
SOAP header block. [xxx this is imprecise: does this mean that a new =
context is returned from each ALS, or that a new element is added to the =
single Context for the activity? I'm expecting the latter. And should we =
address how type derivation is supposed to work.[mcl2]] Once all ALS-es =
have been contacted that are mapped into that specific activity type =
(e.g.,transaction and security), the finished context information is =
returned to the original invoker of the ContextService.

When a context for a protocol supported by a ContextService is present =
on the invocation of a Begin operation for the same protocol type on the =
ContextService, a nested activity is created. The new activity is a =
child of the activity identified by the context associated with the =
operation invocation. The ALSes will augment the new context, which is =
returned to the UserContextService (currently, UserActivityService) with =
the Begun message. Derived specifications for specific protocols may =
define the characteristics of the nesting relationship further, =
including failure models, or may disallow nesting altogether.

[mcl1]We need to mention the protocol-type (change the name in the =
context) before begin, since it's a parameter.
[mcl2]It's either a new ALS-specific context, or a new element to go =
into the ALS-specific context that the context service already has. I =
think the former may be more manageable.

------=_NextPart_000_02DE_01C41321.C49A6DC0--