RE: Comment

[srh@us.ibm.com]

Bob,
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
StepDefinition.
From what I gather from the narrative,some Steps would be
BusinessTransactions
(by definition are B2B message-based) and some may not be "Buyer wants to
recieve
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
messages.
This is what motivated me to say StepDefinition should not have a
BusinessTransactionConstraint,
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
BusinessTransaction.........
(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
term
"transaction". It is terribly overloaded with drastically different
meanings depending on
people backgrounds like EDI vrs RDB.] There are/will be multiple
cooreographies
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).

Thanks,
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
OrderingRule,
>in order to provide it at the Step level and also BusinessTransaction.
>But it does not seem a StepDefinition should have
>BusinessTransactionContraint.
>Correct?

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.

Ok?

Regards,
Bob Haugen