Questions for f2f concerning BPSS choreography constructs, schema and implementation requirements

["Dale Moberg" <dmoberg@cyclonecommerce.com>]

Here is one list of questions I have been compiling on 2.x
implementation issues and refactorings to discuss at the f2f. The
following questions are mainly about our current choreography syntax,
and mainly concern underspecified syntax, rather than basic concepts or
business semantics. I hope those with an interest in specifying
implementations that can "read" instances the same way will. Others have
been cautioned that the following deals with "mechanics"!
======================

Assumptions: we will be using IDs and IDREFs and that reference will be
by IDREF to simplify implementations; this appears to be the consensus
view at present. [It at least is my view!] 
Role association syntax will be more uniform so that a syntactically
definite way of knowing how roles in one context map to roles in another
is available.

The following questions are clustered around key constructs found in
Figure 14 UML Diagram of a Choreography, that is attached. I recommend
just looking over the attached figure before starting.


1. Will BinaryCollaboration and MultipartyCollaboration be
specializations of an underlying type?

a. If not, why not? [Currently they have separate types. I recall
discussing combining them at one point.]

b. (1) If so, (refer to UML Diagram of Choreography), will
MultipartyCollaborations have 0..* BusinessStates? 
    (2) Shouldn't a [Multiparty|Binary]Collaboration always have at
least several states, such as Start and Success or Failure? If not, why
not? [The schema says exactly one Start, one or more Success, one or
more Failure, and one or more BTAs or CA_s.)  If so, can the text on
choreography include specific language on what states MUST be present
that is congruent with the schema and UML model.
    (3) In a MultipartyCollaboration, should there be an
initiatingRoleIDREF? Can there be several Roles that each initiate
(possible example, types of bidders on an auction exchange)? Should
initiators be generalized to a list of elements? 
    (4) Will MultipartyCollaborations be referencable from other
constructs that now reference BinaryCollaboration (such as
CollaborationActivity)? If not, why not?

c. Each [Multiparty|Binary]Collaboration has Roles [2 or more]. Each
BusinessActivity (whether BTA or CA), refers to these roles using 4
attributes, fromRole, fromRoleIDREF, toRole, toRoleIDREF. Implementers
want reference by IDREFs only. So,
   (1) Can the toRole and fromRole attributes be removed from BTA? [CPPA
only references the @name attribute of the Role element in the
BinaryCollaboration content. This may, of course eventually need
updating in CPPA 2.1.]
   (2) Can we consider replacing the attributes fromRoleIDREF and
toRoleIDREF by a content model using a Performs element that declares in
a BTA what RoleId is associated with the RequestingBA and what with the
RespondingBA? [This requires some fixed pseudo roles ...] Illustrative
xml:

<BusinessTransactionActivity bunchesofattributeshere>
<Performs  current="buyerIDRef23"
final="#BusinessTransactionRequester"/> <!--@final has an enumeration
type TBD--> <Performs  current="sellerIDRef24"
final="#BusinessTransactionResponder"/>
</BusinessTransactionActivity>

   (3) Can a content model using Performs elements be added to the
CollaborationActivity to declare Role bindings? 
<CollaborationActivity bunchesofattributeshere>
 <Performs  current="buyerIDRef1"  next="sellerIDRef"/>  <Performs
current="sellerIDRef"  next="buyerIDRef1"/> 
</CollaborationActivity>

   (4) In general, can constructs where references to Roles are made all
be refactored to always allow use of a single uniform Performs
construct? In addition, some places need to have Performs elements added
to track what role goes with what. In the realm of containers for
states, MultipartyCollaboration, BinaryCollaboration, and
CollaborationActivity can use these constructs. In the realm of States,
the Transition element needs this construct added somehow. I doubt that
very many other BusinessState constructs need to involve Role maps.
Start, CompletionStates (Success, Failure) don't involve any need to
rebind Roles. Fork and Join may involve Role mappings but I do not
understand how the syntax for these elements works at present. The
Decision state probably would need Role Bindings but it is too
underspecified to know how it works and is not documented.

2. Transition element, syntax and semantics.

Current text begins:

"Transitions can originate from Business Transaction Activities or
Collaboration Activities within a Binary Collaboration, or from Binary
Collaborations within a Multiparty Collaboration."

The UML shows that Transitions are a specialization of BusinessState.
Because there are transitions between states, there can be I guess
transitions between Transitions. The schema for Transition contains a
number of attributes, one of which is a reference to an "incoming" state
and the other a reference to an "outgoing" state. [As I will suggest
later, forks, joins and transitions should all be specializations of a
class differing in cardinality of "incoming" and "outgoing" state
references. Transitions have exactly one of each, forks have exactly one
incoming and 2 or more outgoing, joins have 2 or more incoming, and one
outgoing... We currently neglect declaring what joins or forks join or
fork! We should make the syntax uniform for these linkage constructs if
we are to have a decent graph notation supporting traversal procedures.]

The opening sentence above is a little confusing to me. Transitions are
states that at least occur as part of BinaryCollaborations. Is this
sentence providing semantics for the "toBusinessState" and
"fromBusinessState" references in the Transition? That seems to apply to
the BTAs or CA_s, which are business states. But can they also refer to
BCs? That is somehow suggested by the end of the sentence.

I think the point of the sentence is not clear enough to explain to an
implementation team and get an interoperable result. We should explain
explicitly what can be referred to using the "to..." and "from..."
attributes. [Also, if we are to view transitions, forks, and joins
uniformly, we should shift from "to.../from..." attributes to elements,
which can be repeated when we come to forks and joins.

@onInitiation is listed as a boolean attribute and here is what we have
for its semantics;

A Transition can also be used to create nested
BusinessTransactionActivities. A nested  BusinessTransactionActivity is
enabled when a transition flows from a parent BTA to the nested BTA and
this transition is marked onInitiation = 'true'. [So only between BTAs,
apparently. Lexically where do/can the referenced BTAs appear? Anywhere,
in the same "container", etc. Can they jump packages? Need more
constraints somehow to implement.)

In this case, the transition is enabled after the receipt of the request
in the parent transaction but after the request has been acknowledged
appropriately if applicable. 
[These are signals, not business level acks right?]

At this point, the second activity is performed before returning sending
the response to the original requestor. No "return" transition is
specified. 
[Can different responses be returned based on the outcome? Unclear about
this.]

If more than one transaction ought to be executed they must be specified
within a collaboration activity.
[Does this mean put the Transition into a CA, as a constituent? Not too
clear about what syntax is specified here.]

There are no possible outgoing transitions fom a nested activity unless
it is associated to an exception. [This is an exception in the nested or
nesting BT? Too brief to be certain what is meant.]

If the activity terminates normally, the thread of control is handed
back to the parent activity. The flag 'onInitiation' in Transition is
used for this purpose. [Is this a different purpose from indicating
nesting? Not sure I understand this.]

Nested Business Transaction Activity are often found within a multiparty
collaboration.

In essence a Role in one Binary Collaboration receives a request, then
turns around and becomes the requestor in other Binary Collaboration
before coming back and sending the response in the first Binary
Collaboration. [Is this statement apply only to multiparty context?
Negotiation in CPA is not multiparty.]

I believe this discussion is too dense to be easily and interoperably
translated by implementers. Examples of usage, with full syntax, should
be provided. Also, I am not certain why this functionality is added to
Transition, rather than to BTA itself. But that may be too hard to
change at this point.]


3. Forks, Joins

Forks, joins and transitions should all be specializations of a class
differing in cardinality of "incoming" and "outgoing" state references
IMO. Transitions have exactly one of each, forks have exactly one
incoming and 2 or more outgoing, joins have 2 or more incoming, and one
outgoing... We currently neglect declaring what joins or forks join or
fork! We should make the syntax uniform for these linkage constructs if
we are to have a decent graph notation supporting traversal procedures.


4. Decision

There is no indication of what attributes are on Decision and I cannot
find text that documents this element.This underspecification needs to
be fixed, or else its introduction deferred. 
Not implementable at present.


General remarks. 
Because we are using a system of IDs and IDREFs, which are like untyped
pointers,
we really need to devote explicit attention to specifying which
element's IDs are eligible to be referred to when we use an IDREF
somewhere. We are far too casual in leaving this to the implementer's
discretion.

Also, using IDREFs to track flow control means that we have a large
potential for arbitrary
jumps into disconnected "blocks."  What kind of constraints, if any, are
we interested in
specifying in this area?

BPSS Choreography UML model.doc