[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Overview of CPP formantion and Implementation concerns on BPSS Role.
Implementation Assumptions in this Message: There are three use cases for BPSS instances: 1. A Business Processing modelling tool creates, changes, and imports/exports BPSS instances. [None of the following pertains to the modelling tool use case.] 2. A CPP, CPA, or Negotiation tool accesses BPSS instances as one of the inputs for the creation of CPPs. Likewise the BPSS instance may be referenced during the process of forming or negotiating a CPA for various reasons. 3. A BP monitoring tool that can verify that actual executed message flows conform to a path "through" the BPSS instance. The first half of the second use case is the basis for the requirements and constraints discussed in this message. Here is a working list of implementation concerns from Cyclone: [CPP formation and Role] A CPP creator needs to be able to identify all the actions (and signals relevant to) a party entering into a collaboration. For example, a CPP creation tool can offer both a choice of BPSS instance, and once that is known, a choice of roles to play during CPP creation. The tool must then associate all the actions this role might undertake with configuration information in delivery channels and other binding declarations. The CPP obtains values for ebXML Message header values for Service, Action, Role from the BPSS instance. It also assembles its internal mapping construct, ActionContext, the ProcessSpecification attributes, such as uuid and href values The CPP construction process needs clear conventions (with syntactical tokens that realize these conventions) for: a. Entry points (toplevel) process constructs (such as, Binary Collaboration, OperationActivity or MultipartyCollaboration), with explicit declaration of Role values participating in the business process within the start construct. b. Referring conventions: the current use of both names and IDs (GUIDs) to implement reference means that BPSS traversal is ambiguous as to which referring mechanism should be followed. In each referring context, at most one mechanism should be actually operative and therefore only one that needs to be chased. [This reduces both the implementation burdens and removes the possibility of references being ambiguous by pointing to different objects.] c. When a subprocess is referred to, a clear indication of what Role value in the referring context "goes with" which value in the referred-to process segment. Without this, the notation is ambiguous with respect to CPP creation. When finally reaching the BusinessTransactions, the mapping of Role to requesting or responding role should also be unambiguous. d. Using Performs in all cases would be the most explicit way to indicate the Role mappin s, but when the number of Roles and the values of Roles don't change, the "identity" mapping may be regarded as the default when Performs is omitted. (That is, "buyer" maps to "buyer", "seller" to "seller".)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]