OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-caf-editors message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Fw: CAF model thoughts


I've brought this to the editors list, since it's probably more appropriate.

Mark.

----- Original Message -----
From: "Greg Pavlik" <greg.pavlik@oracle.com>
To: "Mark Little" <mark.little@arjuna.com>
Cc: "Newcomer, Eric" <Eric.Newcomer@iona.com>
Sent: Monday, March 08, 2004 12:40 AM
Subject: Re: CAF model thoughts


> Guys, I've been laid up with a high fever since last we spoke. However,
> since this is due tomorrow, I'm going to take a crack at folding in
> Mark's comments.
>
> What concerns me, however, is that we've restated the points that have
> been flagged as problematic at the F2F (for example, a context may be
> augmented by multiple services) without explaining precisely how or why.
> Unfortunately due to time constraints on Thursday we weren't able to
> discuss this in depth. Are some of the underlying assumptions fully
> supported by the WSDL/schema?
>
> I apologize for the brevity of effort in this pass, but I'm dancing on
> the edge of delirium. It's unlikely that I will be well early this week;
> I may need to go in for surgery to have my tonsels removed if things
> don't clear up, so it is safe to assume that I will be unreliable this
> week. I  may not make it to the call tomorrow. Hope this is of some help
> anyway.
>
> One other thought: should we use the editors list for these kinds of
> discussions moving forward?
>
> Greg
>
> PS. I agree with Mark's comments about the nested activity model in his
> last email. This is an important feature if for no other reason than it
> mirrors how existing systems work; anyway, new text follows:
>
> Activities and Contexts
>
> An activity is defined as a collection of web service operations
> performed within a valid context. The expected semantics of a web
> service within an activity are defined by specifications derived from
> WS-Context. These semantics are identified by a protocol identifier
> representing the type of the activity.
>
> A context is a data-structure defined in XML namespace [context
> namespace]. The context may contain information from an arbitrary number
of
> augmenter services.
> [sticking point: do multiple ALSs register for a single protocol? How
> does the context service know how many ALSs must be registered for a
> particular protocol? What does it mean to augment, precisely?]
>
> A context is determined to be valid by it's issuing authority. The
> WS-Context specification defines an issuing authority called the
> ContextService (the WSDL specifies an ActivityService).
>
> An Activity is uniquely identified by an activity-identifier.
>
> A context may contain one activity-identifier, which serves to associate
> the context with an activity. An activity-identifier will have
> additional semantic implications defined by specifications derived from
> WS-Context. For example, an activity-identifier in a system using WS-TXM
> may be a transaction id.
>
> In a system, there may exist a set of contexts C associated with an
> activity. There will typically be multiple contexts because context data
> structures are copied by value from service to service and may be
> augmented to include data that is valid to the local execution
> environment. The contexts in C are not equivalent: each may reflect one
> service's view of the activity at a point in time.
> The initial context for a specific activity is the base from which all
> other contexts may be derived.
>
> A web service that performs an operation within an invalid context
> creates an invalid activity. It is up to the specification derived from
> WS-Context to determine the implications of invalid activities (which
> may be insignificant or severe) and provide structuring mechanisms that
> avoid invalid activities if necessary.
> [mark had a comment about specifying failure-related behavior. I was
> trying here to suggest that the use of a context that is invalid, eg,
> say for an activity that has expired, may mean something bad.]
>
>  From the above, we may observe that a context is associated with one
> and only one activity; "compound" contexts do not exist. The set of
> operations represented by A may be used to define more than one
> activity; for example, the operations in A may include a context for a
> security protocol and a context for a transaction protocol, each
> representing a separate activity.
>
>
>
> [mark says: This is where we differ. The current model has these as the
> same activity
> that (in the example you've given) is transactional and security enhanced.
> What advantages/disadvantages do you see to the separate activity model?
The
> immediate disadvantage is that is removes the composite aspect of the
> specification, something which many people/companies have stated they find
> useful: being able to go to a single service (the Context Service) and say
> "create me a transactional/security context" and binding that to a
specific
> activity, is a useful structuring mechanism. Now there's nothing in the
> specification as it currently stands that precludes the useage pattern
> you've described in any case - that's more a deployment issue than
anything
> else, i.e., I could have separate Context Services for each grouping of
> ALS-es. In the "default" model, there'd be one service with a transaction
> ALS and a security ALS enlisted and a single Begin would get the context,
> whereas in the other case there'd be a Context Service with a transaction
> ALS and a Context Service with a security ALS, and two Begin operations
> would be required, with two activities.]
>
> [greg says: while I think there's some ambiguity in the specs here that
> we really need to resolve, my point wasn't to say an activity couldn't
> represent two protocols. Just that for a given context, say,
> security+tx, just tx, or just security, there's one activity. Anyway, we
> need to clarify exactly how composite protocols are defined and
> provisioned. Then this falls out naturally.]
>
>
>
> Typically, this is a partial intersection for at least one activity in a
> system: the normal mechanism for creating an activity is via the Begin
> operation on the ActivityService PortType. If Begin is used to initiate
> the creation of the first operation of an activity a, the first use of
> Begin in a system will normally not be contextualized. The Begin
> operation is not part of an activity and the subsequent Begun message
> will be the first operation in a, but no other activity. Currently, the
> only context information that is supposed to be associated
> with Begin is the ALS-configuration identifier, which is intended to
> indentify which configurations of ALS-es are to be mapped into a
> specific activity.
>
> [greg: mark, I added this text about the config identifier. I must say
> that I'm at a loss as to how we can request a context for a particular
> protocol (type) and then also say that it should use these ALSs. Isn't
> that somehow implicit in the type information? The ALSs register by
> protocol with the registrar (another reason why we're confused how
> multiple ALSs can be used to augment a context, mechanically speaking.]
>
>
>
> ActivityService 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 one requests to services, andthe 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.
>
> [Greg: my original statement was too broad; what we have here is the
> only statement I need to make me happy with this area of the spec; note
> that I have not addressed the CompletionStatus question. If it goes away
> as a property of the low level services, that should simplify things in
> a number of areas]
>
>
> WS-Context provides a mechanism for creating activities: the
> ActivityService (of course, this should be changed to ContextService)
> PortType. An ActivityService may be used to create activities of more
> than one type. Each type is identified by a protocol identifier.
>
> An ActivityService may be used to create activities for a protocol in
> assocation with an ActivityLifecycleService.
>
> [greg: need definition of ALS; and again, lacking the ability to explain
> precisely how multiple ALSs collaborate to support a protocol (from
> registration forward), we have a hole]
>
>
> When a Begin message is sent to the ContextService (or ActivityService),
> it contacts each registered ALS to get it to send back a context element
> for the ultimate SOAP header block. 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 ActivityService.
>
> [greg: simple question: how does the ContextService (registrar
> interface) know when the complete set of ALSs for a protocol has
> registered?]
>
>
>
>
>

CAF model



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]