[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-bp] ebBP question: ComplexBTA
|
Well, let us mark your proposal an issue
for ebBP. (We need to start a jira project for those.) For your modeling purposes, create a
schema that allows collaboration activities within a cBTA. As you point out
that is not much of a change to the model. You could also import ebBP into some
new schema and add new elements as needed with new names. That might be cleaner. As far as your comment (if there )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. you may be correct. It depends on just
what the “states” are that transitioned between in a choreography
that were usually given the informal semantics of “unit of business
interaction” But a specification language (being
somewhat normative) is not necessarily at fault if something (a putative
choreography) is not describable in it (or within some part of it). I do think that there is something useful
missing from ebBP language and it is something like the temporal constraints
found in languages such as PSL. If we had a BTA b and could say of some other
BTA or CA (call it p) that p completes during the interval of b, we could
then specify the relationships of the choreographic components without making
them “substates” or “subcomponents” … In other words, there are other ways to
specify choreographies than that found in BPSS or ebBP and we might want to
draw upon them (integrate them) the next time that ebBP gets revised. * PSL is a project at NIST http://www.mel.nist.gov/psl/ Anyway, we can take up a version 3 of ebBP
when there are resources and interest sufficient to reach a critical mass. From: Pim van der Eijk
[mailto:pvde@sonnenglanz.net] Hello Dale, Thanks a lot for your reply. Two comments
inline below. Pim From: 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"> 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] 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]