#0036 Monitoring for ebBP-Provide Boundaries

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

This meesage is an initial high-level response to 
Description: Monitoring for ebBP-Provide Boundaries
Owner: Dale Moberg (dmoberg@cyclonecommerce.com)
Due: 15 May 2004

Comments:
Monica Martin  2004-05-02 21:57 GMT
Action item for Cyclone Commerce developers to provide inputs
on what could be required of ebBP in order to support monitoring usage
of BPSS. 

Provide gap analysis.


Let me begin by mentioning the following text that is in a working draft
for 2.0:

>> The ebXML collaboration semantics contain a number of relationships 
>> between multiparty collaborations and binary collaborations, between 
>> recursive layers of binary collaborations, and choreographies among 
>> transactions in binary collaborations. It is anticipated that over 
>> time BSI software will evolve to the point of monitoring and managing

>> the state of a collaboration, similar to the way a BSI today is 
>> expected to manage the state of a transaction. For the immediate 
>> future, such capabilities are not expected and not required.


I understand the task of "monitoring a business process" to involve the
following very high level subtasks:

1. To be able to correlate many distinct acts of document transmission
to a single business process session. For BPSS, these document
transmissions are requests, responses, and signals and possibly wsdl
defined service invocations. 
2. To associate the session phases identified in subtask 1 with a BP
description.
3. To establish either that the session conformed with the associated BP
description or that it failed to conform in some specifiable way( a
timeout occurred without an associated exception signal, for example).
4. The information used to establish the acts of document transmission
may be insufficient or unavailable, especially with multiparty
collaborations. Nevertheless, a participant can establish conformance of
the process in so far as it is "visible".

Of these tasks, the most important is that BPSS provide documentation of
the business process sufficiently precise and detailed so that
conformance or nonconformance is recognizable. For ebXML there are a
couple of aspects to the detail/precision level.

1. Roles enable a monitoring POV to establish its responsibilities in
the business process. (That is, will it send or receive a request? What
timeouts govern its responses? What signals is it expected to send? Is
there an order in which signals and responses must occur? And so on. A
large number of these matters are already specified. We have done
considerable work ensuring that Roles can be mapped to Parties within a
CPA, and that provides details about what documents will flow under what
conditions. The CPA permits associating sessions with BPSS defined
processes, we will asssume. 

2. As the initial excerpt indicates, the BSI today is expected to manage
the state of the BusinessTransactions. What is not yet sufficiently
clear are some details connected with managing several choreography
level transitions:
a. The transition element when it involves the "onInitiation" attribute
as true. How does the outcome of the subordinate BT's "return" relate to
status of the superordinate BT?  There doesn't need to be a fixed
semantic here, but there does need to be a place that specifies a range
of policies IMO.
b. The CollaborationActivity element has completion states. How does
entering these states relate to the completion state of the BC that
contains the CollaborationActivity? This is somewhat similar to point a.
c. MultipartyCollaboration involving CollaborationActivity. Do we define
a completion state for these? [It might not be always "knowable" by one
party if that party is restricted just to information that passes
through its document flows, but there may be auxiliary sources of info
that allow this information to be acquired.]

There are also Choreography "gaps" that are puzzling. Part of these gaps
may just reflect the fact that we allow a schema valid BPSS to have
unreachable states and to have noncompletion states not having any
transition defined. Some of this may be sorted out and become clear by
adding warnings (in the form of well-formedness constraints) that
document unreachable or hung conditions.

But other features may reflect a need for more information being
supplied to the designer.
For example, if I use a transition for subordination, how do I
choreograph the next state(s) reachable? Do I need additional
Transitions (or something with an incoming link) to link to the
onInitiation=true transition? That seems like a funny notation
implication. Also, as I mentioned at the f2f, the Decision, Fork, and
Join constructs (assuming we continue to use them) can be clarified by
adding explicit descriptions of Links to the incoming and/or outgoing
states. Otherwise their use in choreography is underspecified IMO.

So the gaps seem to me to be mainly ones of underspecification and
incompleteness rather than having something there that is wrong. There
does seem, on occasion, to be stuff that is not being used that confuses
the current picture. These are attributes like "preCondition"
"postCondition" "beginsWhen" and "endsWhen" that just add clutter. They
should be moved to a "future directions" section because we already have
a documentation element for documentation. [The spec currently says
these attributes are not defined but can be used for documentation and
may be given a semantic later. That means that transforms for converting
BPSS instances > 3.x should delete these attributes when up versioning.
Why bother even putting all this clutter in at the 2.0 level?]


So here are some of the high-level gaps relevant to defining how a
process should go for the monitoring task to utilize: 

Specify how onInitiation and CA "compose" (how their "return"
values/status (completion states and their guard conditions) or pertains
to subsequent state transition, most critically.)

Clean up the activity-diagram-like constructs with respect to linkage
and ConditionExpressions (what I was starting in 

Add the role binding "Performs" construct as needed (where jumps to new
role contexts possible) and explain the default semantics and cases
where a new Role "pops up")

Add WF constraints explaining about unreachable BTA states or writing
flows ending up stuck in a non-completion state. [This will help people
build a BPSS parser/interpreter that knows when a "bad" instance is
encountered. I take the BPSS interpreter to be building up some internal
labeled state transition diagram that can be used in monitoring. ]