Hello Dale,
Thanks a lot for your reply. Two comments inline
below.
Pim
From: Moberg Dale [mailto:]
Sent: 11 January 2010 17:39
To: Pim van der Eijk;
Cc:
Subject: 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:]
Sent: Monday, January 04, 2010 12:06
PM
To:
Cc:
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
