[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?] > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]