RE: [ebxml-bp] ebBP question: ComplexBTA

The current cBTA is not defined in complete generality, partly because it was difficult to gain both clarity and consensus about what the cBTA was supposed to support.

The major function was to allow a choreography to allow “interpolating” activities between two parts of a business transaction. The recursive feature extended what was available from earlier BPSS options. Visibility was added to permit documentation of “who” had what information available about status or of events of documents being exchanged (between remote parties). So the extensions were an attempt to come to grips with multiparty transactions, while recognizing that completely global views of what was going on were not in general available to all parties.

I think it is fair to say that this material was “experimental” and would be subject to change and elaboration as use was made of the newly introduced constructs and expressivity.

<Pim> For a customer project, I am trying to use the ebBP to define the interactions between a business intermediary (not an MSH intermediary), its clients and its suppliers. As a result of the limitations of the current ebBP cBTA, I can only express one of the seven business collaborations I am working on right now. That is a very disappointing score, since these collaborations are not very complex at all. Replacing the definition of CBTA with the following definition provides the generality I need:

<xsd:element name="ComplexBusinessTransactionActivity">
  <xsd:complexType>
   <xsd:complexContent>
    <xsd:extension base="BusinessTransactionActivityType">
     <xsd:sequence>
      <xsd:element ref="Start"/>
      <xsd:group ref="collaborationGroup" maxOccurs="unbounded"/>
     </xsd:sequence>
    </xsd:extension>
   </xsd:complexContent>
  </xsd:complexType>
</xsd:element>

The StatusVisibility element (which I am still trying to understand) is missing from this. (To the extent that I understand what it is intended to do,) I think it could be added to collaborationGroup. </Pim>

I think that updates to cBTA are probably part of a project in which we revisit patterns of visibility, how event reports (documents, statuses, etc.) are to be connected with process descriptions, how choreography descriptions are to be merged with orchestration descriptions, and whether we might be better off introduction more one-action BTs to avoid a need to interpolate process descriptions in the middle of a BTA.

<Pim> If each logically related pair of business documents (like Order and Order Response, Request for Quote and Quote etc.) has to be split into separate transactions just because the choreography language is not expressive enough, there is an issue with the choreograph language, not the choreography. When using ebBP with CPA and ebMS, "two way" versus "one way" transactions also control whether messages are correlated using RefToMessageId in the message header. It is not just a modelling issue. In an messaging environment (especially if it has high-volume, low-latency requirements, or if the payload is encrypted using a key that the MSH has no access to) you want to be able to process messages asynchronously using the message header only (dispatch to the appropriate handlers registered for the (RefTo)MessageId) without having to look at other correlation information in the business document. </Pim>

(I think you can see that a cBTA is a hybrid notion in that it represents aspects of the Receiver’s orchestration (constrained to descriptions of (nearly) public subprocesses involved in that orchestration.)

So whether to extend cBTA to be more general, as you suggest, or to tinker with BT patterns, and how to handle visibility of events (and its relation what is being _specified_ about state alignment) are all part of the same tangle.

There was also a desire to allow ebBP choreography descriptions to fit in with the emerging BPMN 2 descriptions. BPMN 2 is undergoing some final changes and some of the new complications that appeared (conversations, choreographies, collaborations) are in a process of being smoothed out. I would prefer to see the dust settled over in OMG so we can align with their notations. And presumably we will obtain a means for placing both choreographic descriptions and orchestration descriptions into one model (but possibly separable views).

In addition, RosettaNet MCC is working on updating their choreographies to make use of ebBP and to apply to the new MMS approach, so that there are potentially use cases coming from that consumer that will help us see what needs to be done to improve ebBP for its concern with a specification language for public processes.

From: Pim van der Eijk [mailto:pvde@sonnenglanz.net]
Sent: Monday, January 04, 2010 12:06 PM
To: ebcore@lists.oasis-open.org
Cc: ebxml-bp@lists.oasis-open.org
Subject: [ebxml-bp] ebBP question: ComplexBTA

Since this TC is taking over maintenance of ebBP, here is a question related to the ebBP 2.0.4 OASIS Standard.

Suppose we have a Business Collaboration involving a "Quote Request" and a "Quote Confirmation". In RosettaNet these two document exchanges relate to the same PIP 3A1, "Request Quote". In ebBP it makes sense to model this as a Business Transaction (or one of the UN/CEFACT pattern-specialized types of Business Transaction). From the point of view of the business collaboration that this exchange is part of, the interaction is atomic. The ebBP business transaction is a representation for a PIP.

Now suppose there is a need to enhance the Request Quote transaction to also cover the interactions that support it. Perhaps the Seller needs to contact one or multiple suppliers or sub-contractors to obtain the information needed to generate the Quote Confirmation, and we want to model this.

The ebBP standard does have a construct for this purpose: ComplexBusinessTransaction. If the Seller needs to invoke another business transaction, or even a complex business transaction (recursively involving other transactions), the current standard supports this. It is also possible to define the complex transaction as a series of two transactions, and to associate "visibility" information to them.

Now suppose the embedded transactions are not taking place sequentially, but in parallel. The ebBP standard has a way of expressing nested business flows, and they are available in the content model of the Collaboration elements. However, they are not available in the Complex Business Transaction. I would like to see the content model of Complex Business Transaction Activity to include

<xsd:group ref="collaborationGroup" maxOccurs="unbounded"/>

like the other ebBP elements. It would mean: the nested flow of activities (perhaps including third parties, parallelism, decisions, forks, joins ..) takes place between the incoming request and response. Why is this not the supported in ebBP 2.0.4? I can't see why a simple linear series of transactions is "atomic", but a parallel execution of those transactions is not. Or why a single recursively nested structure is, but some other structure is not.

A difference between the CBTA content model and the Collaboration content model is the presence of the StatusVisibility element. This element could be included in the collaborationGroup too, leaving the access to the visibility information (using status request type of messages) up to further profiles.

The above generalization is so .. general .. that I'm probably missing something basic.

Any comments welcome ..

Pim

ebcore message