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

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

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.