[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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. 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. (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] 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]