Re: [ebxml-iic] RE: IIC 11/2/2005: Starting on ebBPProfile...ComplexBTA and Patt erns

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

> durand: 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)
>
mm1: The UMM + operational semantics (that evidence a template for 
business transactions). Operational semantics found in v2.0.1.

> 2- conventions of representation in ebBP (use of particular signals, 
> doc envelope conventions, relationship with CPA...)
>
mm1: Yes + profile of selections on preferred operational semantics 
selected.  For example, that signals RA and AA will be used for xx 
pattern for request.

> 3- deployment and artifact management aspects (validation, 
> distribution, etc.)
>
mm1: Yes. This touches on aspects that may be outside of the scope of 
ebBP but important nonetheless. For example, the logical business 
documents may be assembled and which Specification (boundary of the 
'document') may be influenced by an external document, such as UBL Small 
Business Subset.

What you don't have here which is very important are the more complex 
compositional aspects of Business Collaboration. That is more than 
business transactions, it is their composition and use geared toward the 
expectation of the parties involved, recognizing the roles and other 
constraints involved (transitions, conditions, semantic relevance, etc).

> -----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/ 
> <http://www.sims.berkeley.edu/%7Eglushko/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.
>