Re: [ebxml-bp] #0036 Monitoring for ebBP-Provide Boundaries

["Monica J. Martin" <Monica.Martin@Sun.COM>]

>Moberg: Description: Monitoring for ebBP-Provide Boundaries
>Owner: Dale Moberg (dmoberg@cyclonecommerce.com)
>Due: 15 May 2004
>......
>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. 
>  
>
mm1: In the future, we will need to accommodate more than 
request-response such as visibility of composed activities particularly 
with binary and multiparty collaboration in a larger collaborative activity.

>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? 
>
mm1: Can you explain that more?

> 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.]
>
mm1: We discussed that multi-party collaboration has different levels of 
visibility given the participants (completion then is relative). Have to 
understand more about compositional aspects of state (and impact of pre- 
and post-conditions, if applicable).

>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.
>  
>
mm1: Are you saying that if an activity is not used, that indicates 
non-completion?

>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?]
>  
>
mm1: I believe some users are actually making these computable in 
practice. Perhaps John Yunker can add to this discussion.

>
>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. ]
>
>
>
>
>
>
>
>
>
> 
>  
>