RE: Comment

[Bob Haugen <linkage@interaccess.com>]

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