OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: Comment

I understand your desire to align to the Composite in order to generically
make available
consistent recursion. I might be a little concerned on loosing a lower
level of detail like
outlined in your narrative. Upon looking at this further, I would think
that by nature
the StepDefinitions are in fact a sequence within the BPD, so perhaps add
<<ordered sequence>> to the by-value aggregation from BPD to
From what I gather from the narrative,some Steps would be
(by definition are B2B message-based) and some may not be "Buyer wants to
products". So, when we define a BPD is appears we are also implicitly, via
another not-obvious-specialization of Step at the level of
BusinessTransaction, taking into account
business economic events that are not realized within the B2B space through
This is what motivated me to say StepDefinition should not have a
as I viewed the BusinessTransactionConstraint conditions for the in-B2B
message space Step
specialization. My thought is that at the most gross level you do A, and if
it worked you do B, and if it
worked, you do C (A,B,C may or may not all be realized in the B2B message
space), and this is the
intention for BPD aggregating Steps.

Further thinking: perhaps a Contract actually results at the Step level on
(don't I have a non-B2B-message-based Contract for say "Buyer wants to
recieve Products" ? Hmmmm

I see the BusinessTransaction as the specialialization of a Step in the B2B
space intended to be
a unit of electronic business. I get all of the narrative about
PartnerRole, Initiator, etc.
It appears there could be value in specializing PartnerRole with Initiator
and Responder................

The whole thing then overlaps with TRP at Information Exchange. To TRP,
this is called
a MessageSet. [Side note is that by my suggestion, TRP dropped the entire
"transaction". It is terribly overloaded with drastically different
meanings depending on
people backgrounds like EDI vrs RDB.] There are/will be multiple
defined at the TRP level which define transport-level ordering rules for
the messages
needed to support a BusinessTransaction (don't like that term of course),
and this is where
TRP integration is required. A closer integration here may shed light on
Karsten's K. comments...

Last I understood TRP included ServiceType and Intention to support the TRP
level code
identifying the dispatch to the correct Service (say
CustomerProfileService) and the correct
Intention (say Update).

Scott Hinkelman
Senior Software Engineer, SWG IBM Austin
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074

Bob Haugen <linkage@interaccess.com> on 07/12/2000 06:16:21 AM

To:   Scott Hinkelman/Austin/IBM@IBMUS
cc:   "'ebxml-bp@lists.ebxml.org'" <ebxml-bp@lists.ebxml.org>
Subject:  RE: Comment

Bob Haugen:
>|In my recent proposal to simplify the BusinessProcessDefinition
>|hierarchy, in response to Karsten Riemer's issue #k, any level
>|of the hierarchy could have OrderingRules and TransactionConstraints
>|that could manage sequences of Transactions.   I think this would
>|handle your issue.

Scott Hinkelman:
>It seems then that the StepDefinition should be associated to
>in order to provide it at the Step level and also BusinessTransaction.
>But it does not seem a StepDefinition should have

My proposal was to use the Composite pattern, from the
GOF _Design Patterns_ book, to make the number of
levels in the hierarchy flexible from 1 to N.  Then to make
all the features such as BusinessTransactionConstraint
and OrderingRule optional relationships of the top-level
and abstract BusinessProcessComponent class.
That way, all features would be freely composable
as required. There would not need to be special
BusinessTransaction and InformationExchange
classes, unless they had some special behavior
beyond having composable features.

The problems with the current design include:
1) Karstens #k: the number of levels in the hierarchy are too
    many for simple info exchanges; and
2) Karsten's #v: in complex transactions, optional features
    like OrderingRules may be needed at more levels than one.

That appears to be similar to what the TR&P group
proposes with Services and SubServices which
can be nested to many levels.


Bob Haugen

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC