RE: IIC 11/2/2005: Starting on ebBP Profile...ComplexBTA and Patterns

[Jacques Durand <JDurand@us.fujitsu.com>]

Title: RE: IIC 11/2/2005: Starting on ebBP Profile...ComplexBTA and Patterns

So we'll try to isolate and abstract the different aspects of a profiling of bus transactions - the material below will help, but there are certainly aspects that are more related to ebBP itself.

Is that fair to say that a deployment profile of ebBP by a user community might have three major parts:
1- the type and parameters of bus transactions (UMM level)
2- conventions of representation in ebBP (use of particular signals, doc envelope conventions, relationship with CPA...)

3- deployment and artifact management aspects (validation, distribution, etc.)

Thanks,
Jacques

-----Original Message-----
From: Monica J Martin [mailto:Monica.Martin@Sun.COM]
Sent: Wednesday, November 02, 2005 2:39 PM
To: iic
Cc: Jacques Durand
Subject: IIC 11/2/2005: Starting on ebBP Profile...ComplexBTA and Patterns

As we discussed on Monday (31 October 2005), there are several important
parts to the profile. One key component is the scope, use and decisions
between parties about the BT patterns. I mentioned that originally and
even since that time, templates have been created. These are available
for reference. One of the more salient examples is included in Robert
Glushko's [1]. Chapter 9 shows some high level starting templates to
define business transactions (we can add/expand these).  It helps
communities start to see the business process, its name, the involved
parties, the conditions whereby the process proceeds, the documents
used, etc. In Chapter 9 [1], there is also a good description of the
relevance, context and use of business documents in a business process.

In addition, Chapter 10 also talks about defining your own patterns (and
is related to ebBP Data Exchange element for partner-specific pattern
definition), compose different patterns (collaboration), apply context
(restrictions, selections) and use a checklist sort of definition
paradigm. Similarly, the updated UMM user guide (not N090, R10 but R12)
uses a template model. [2] Both references are indicative of the pattern
matrices we developed that are found in ebBP v2.0.1.

Secondly, on the question regarding ComplexBTA, see Section 3.4.10.1 in
the v2.0.1 Committee Draft.  See [3]. The use case was to identify in a
business collaboration and associated BTA that one party may have
visibility to another party that supports them, although the latter
partner not a part of the defined activities. For example, a distributor
is queried by a seller before the seller responds to a buyer. The
parties of seller and distributor and their activities may actually be
specified in another process definition. However, the seller wishes
visibility to this serial occurrence in the current process definition. 
This shows that the seller has visibility to other sub-parties and has
the responsibility for the performance of the sub-parties (who are not
first class citizens of the business collaboration), who are not
specifically constrained by the business collaboration. Sub-parties are
identified in the ComplexBTA but are not parties to the binary
collaboration.
The original requirements stemmed from financial services domain.
Meeting minutes from editor's F2F where more information is available is
located at:
http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/document.php?document_id=7691.
This differs from multiparty collaboration. It may also be seen as a
partitioning mechanism that may support multiparty collaboration in some
way (with more to be determined).

Let me know if you have more questions or need more details. Thanks.

[1] Reference (shameless plug for Bob et al):
http://www.sims.berkeley.edu/~glushko/DocumentEngineeringBookDraft/

    Chapter 9:
    http://www.sims.berkeley.edu/%7Eglushko/DocumentEngineeringBookDraft/DEBook/ch9_FINAL.pdf
    Chapter 10:
    http://www.sims.berkeley.edu/%7Eglushko/DocumentEngineeringBookDraft/DEBook/ch10_FINAL.pdf
    If we use these, I'd suggest some attribution.

[2] Reference:
http://www.ifs.univie.ac.at/untmg/artifacts/UMM_User_Guide_2003-09-22.pdf.
See for starters, page 39, 96.

[3] Extracted from Section 3.4.10.1.

A Complex Business Transaction Activity (ComplexBTA) allows for nested
BTAs to happen in a recursive manner. This concept is a pure sequencing
concept and does not affect the atomicity of the Business Transaction.
The choreography mechanisms for the Business Collaboration allow for
Business Transaction Activities to happen in parallel, however there MAY
be a need to express that a BTA can happen only after the request of the
other BTA has been entirely processed (including the return of
acknowledgements). This is precisely the purpose of Complex Business
Transaction Activity. When multiple activities are nested within
ComplexBTA, these activities MUST be executed in series.  The model
supports for any number of nesting levels. Each activity element is
associated with a StatusVisibility element that specifies which state
(Success, Failure and document exchanged) are visible at the level of
the parent ComplexBTA.

The ComplexBTA provides a mechanism to implement and communicate the
dependencies between an actual business process (semantic process) and
systems implementation of business processes (service choreography).  An
actual business process may subscribe to events happening in the
services layer, and update the actual state when the event is received. 
This functionality allows a complete decoupling of the implementation,
as well as clear view of the required information at the actual (real
world) business layer.  This mechanism allows the status to be known and
published in a Business Collaboration with the default being no status
visibility.  When status visibility is desired for a ComplexBTA, a
simple scenario is provided: Assume a Buyer and Seller are parties to
the Business Collaboration.  The Seller may have visibility to other
sub-parties, such as Suppliers, and is responsible for the performance
of the sub-parties.  In this sense, the sub-parties neither are not
first class citizens to this particular Business Collaboration nor
constrained by it.  Another Business Collaboration may exist elsewhere
that defines the interaction of the parties that are sub-parties visible
in this Business Collaboration.  Conversely, in a Multiparty (Business)
Collaboration, the parties are responsible in that Business
Collaboration. For example, the Supplier would be responsible for the
performance of the sub-parties. A brief example of a ComplexBTA is shown
in Figure 10.

Figure 10: Status Visibility

Status Visibility is included in order to specify which status values of
the embedded processes are considered, if any, when returning the status
value to the context in which the parent ComplexBTA was included.

Condition expressions and guards govern the incoming transitions on
links (FromLink from a parent ComplexBTA for example). Each of the
FromLinks can be specified to transition to the CompletionState (Success
or Failure) as a result of the satisfying condition guard. This allows,
for example, exposing technical failures. If expected, failures can also
be modeled. The parties specify how it is handled. Condition expressions
and variables are described in Section 3.4.11. Expected (choreographed)
and unplanned (General Exceptions) are described further in Section 3.6.2.3.

As described later in Section 3.5.8.1, these linking constructs, or
movements between states (which were previously called pseudo-states),
would be Start, CompletionState (and sub-specializations of that,
Success and Failure), Fork, Join, Decision (or Choice), and Transition.
They correspond to bundles of labeled edges of a directed possibly
cyclic graph. At their core, they are collections of pairs of nodes, and
describe the potential paths of a ebBP definition.

In the ComplexBTA, this nesting and the associated constraints allow
monitoring of the state model of the collaboration and specifies event
visibility of the service layer model.  The ebBP state model and
expression enumerate semantic business events and the complexities of
service events are mapped at a technical layer onto business events
(semantic business occurrences).  This decoupling is extremely powerful
as incremental improvements in both service and business layer evolve.
If a business process designer specifies the Document Flow from another
sub-party, it becomes visible. This allows incremental progress in order
to anticipate and accommodate future development needs by enabling
status visibility in a nested process.  Other capabilities evolving in
the messaging layer (such as in future versions of ebXML Messaging
Service) may also support this projected status requirement.

Such capabilities allow more effective monitoring of the activities
defined. The process designer may choose to use the status visibility
details as input to make decisions on other business logic used in this
enclosing BTA. Industry sectors such as logistics processes
(particularly for international trade) may make use of this mechanism to
allow migration to global, potentially fully visible, collaborations
between many parties.

In the v2.0 and v2.0.1 technical specification, the nesting for status
visibility and transitions in a ComplexBTA is unbounded. More business
requirements are being gathered to determine the need and use of status
visibility in other activities such a Business Collaboration
(Multiparty) and the utility of administrative monitoring.  In the
future, it is also anticipated that managing coordinated, complex
activities and visibility will be expanded for Business Collaboration of
more than two abstract partner roles and for ComplexBTA.  Such
coordination may expand the relationship of the ebBP technical
specification to other emerging specifications and technologies, in
order to support specialized status visibility, particularly to further
enhance monitoring capabilities.