[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: ActionItem 26 Nested Collaboration Logic Gap, first draft
Discussion: OASIS.ebBP.WI26-NestedCollaborationsAndRoles; Topic|Referring,Roles,Reusability; Point|LinkageOrBindingShouldMainlyOccurWithinContentModelofElementWhereR Point|eferenceOccurs; dwm@ In the following I assume we accept Martin Robert's proposals concerning specializations of BusinessTransaction, and also some form of JJ Dubray's proposal that the main containers (elements) for complex flow control include BinaryCollaboration, MultipartyCollaboration, and possibly CollaborationActivity. BinaryCollaborations and MultipartyCollaborations can basically have very similar content models in JJ's view, except that the number of "locally declared Roles" will differ. I will be discussing "references" made to the above items [the complex flow containers] and also references to the specialization siblings of BusinessTransaction made in BTAs. One of the difficulties that CPPA has had with aligning with BPSS is that CPPA needs to pick out of BPSS the BusinessTransactions that a given party will support, and also select from the global view of BPSS the Role perspective of one participant (party) (for a CPP). The problem is like finding a projection of 1-dimensional curves out of some n-dimensional model, and is a little tricky. What CPPA intends to do is, starting with some complex flow's entry point, trace a toplevel Role's trajectory through all the referenced complex flows to the baseline specializations of business transasction. What CPPA needs to do is to be able to track the Role in one flow container/businesstransaction down to the primitive collaboration patterns (Notification, RequestResponse, and so forth). Ideally explicit (and _uniform_) syntactical constructs, rather than implicit semantic conventions in the BPSS text, will mark out the "connections" through the flow constructs so that implementers can have a reasonably simple task to trace trajectories. BPSS, on the other hand, rightly demands that the containers it defines be reusable, and that different complex flows can refer to (and thereby reuse) the same syntactical units (possibly flow containers themselves but in the simple case, the specializations of BusinessTransaction). So reusability and reference rightly go together. Now the problem has so far been that if we put Role trajectory connections "in" a container, the container becomes far less reusable. Hence there has been a tension between the design requirement from CPPA for Role trajectories, and the design requirement from BPSS for reusability. I think there is a resolution for these apparently conflicting requirements that applies to all flow containers, and that is _uniform_. Here are the features of the proposed resolution: 1. There can be both "local" and "global" Role declarations. That is, Role elements can occur at the toplevel and can also occur within complex flow containers (current). The global Role elements are really BusinessPartyType declarations that can get associated with a toplevel flow starting container by being bound to its (local) Role values. For uniformity, all bindings use Performs elements, so the content models at various points will need to be expanded to allow sequences of Performs elements. [Adding global Roles to indicate BusinessPartyTypes is indicated by Anders recent model. It is actually an optional feature, but one I like.) 2. The connection between Roles currently visible and those in a referred to construct occurs where the reference is made using either IDs or names. I think this design is, more or less, the way we currently do it. But our current syntax is neither uniform nor does it generalize to the MC case. Let me take some time to expand this with some unusual, but possible use cases. a. Suppose we want to reuse a JJ-style MC flow involving a credit-approver, a seller, and a buyer. Suppose we want to reuse it from a BC with a buyer and seller Role defined locally. We want the localseller to bind to the MC seller, the local seller to the MC credit-approver, and the local buyer to the referenced buyer. Three Performs constructs within the BC's Transition element's content model would accomplish assoiating local Roles with referenced Roles. Reusability supported. If we need to indicate which is the initiating Role, an attribute on Performs could mark that. [That allows the reused MC container to not have a fixed initiating Role-- it always picks that up from the Referencing context.] b. Suppose we want to loop around a choice (XOR) over BTAs. Let the Referencing context have two local roles, A and B, and the Referenced BTA be in a context with two roles, counterProposer, proposalResponder. To alternate A with B for the Role of counterProposer, we would just alternate the Performs associations, viz., <Performs><Local>A</Local><Remote initiating="true">counterProposer</Remote></Performs><Performs><Local>B< /Local><Remote>proposalResponder</Remote></Performs> with <Performs><Local>B</Local><Remote initiating="true">counterProposer</Remote></Performs><Performs><Local>A< /Local><Remote>proposalResponder</Remote></Performs>. c. As these examples illustrate, the formal analogy here is that of actual parameters and formal parameters that are used to hook up a function invocation with a function declaration. The locally "visible" Roles are analogous to the actual parameters in the call, and the declared Role values in a flow container declaration are analogous to the formal parameters. IMO, it would be nice to have an attribute on Performs called "bindingBy" with two values, "name" or "ID" That way we would not need to have the repetitive attributes such as "fromRoleId" and "fromRoleName" all the time. Also, the whole "fromRole" "toRole" attribute apparatus would disappear in 2.0. These distinctions are inherently limited to a "BinaryFlow" perspective, and don't generalize well to Multiparty flow control. Also while initiating is an important property, I would like to see it placed within the content-model of Performs. d. Different initiator flag (to accomodate Martin's different "entry" mode use case) e. Distributor (Haugen/Fletcher style) cases. f. Yunker multiparty cases [I will try to do these other use cases if I get more time this weekend.] One implication of the above approach is that, for example, constructs containing a forward reference (such as, BusinessTransactionActivity, (OperationActivity if it is added), Transition, Start, CollaborationActivity) will have content-models expressing Role associations, which I have assumed to be provided by sequences of Performs, the uniform Role connection construct. The Success and Failure states also have references pointing back. I think we could probably use Performs here also. I think it is a separate small point that needs investigation though. How to mark the toplevel flow constructs (use a Start state?) is another pending item. A final issue is whether we should dispense with CollaborationActivity in Referencing BinaryCollaborations. Minimally, I think CollaborationActivities should allow me to feference either a MultipartyCollaboration or BinaryCollaboration. I am not certain what is allowed at present. @dwm
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]