RE: Another set of comments

[Bob Haugen <linkage@interaccess.com>]

Karsten Riemer wrote:

>k. This issue has been raised previously. There are too many levels in the
>process definition, or rather one needs to use only a subset of them. Some
>processes might only have a series of business messages, and no way to neatly
>order them into steps or transactions. Some processes might have distinct
>InformationExchanges but no distinct transactions. Some messages exchanges do
>relate to  transactions but not on a many-to-1 basis. I don't know what the
>solution is but we should talk about how to build a little more flexibility
>into the hierarchy, or simplifying the hierarchy.
[...]
>v. This probably goes with 'k' above. We should move the
>BusinessTransactionConstraint up to the StepDefinition level so you can use it
>to sequence any kind of step, not just transactions.

I second Karsten's #k, and add #y, which resolves #k and #v:

y.  Line #114: Redesign the Business Process Definition
hierarchy to be a Composite, using the pattern from _Design 
Patterns_, ISBN 0-201-63361-2.  That would mean the top class
would be BusinessProcessComponent, with subclasses
Step and CompositeStep.  CompositeStep has an aggregation
relationship line going back to BusinessProcessComponent.
BusinessProcessComponent has optional relationships with features 
like TransactionConstraint and OrderingRule.  Using this
design, you can have as many levels of hierarchy as required,
and each level can have as many optional features as it needs.
Here is a crude ASCII art diagram, which requires a font like
Courier to read correctly:

---------------------------      -----------
|BusinessProcessComponent |------| Feature |
---------------------------<---| -----------
   /_\             /_\         |
    |               |          |
--------   -----------------   |
| Step |   | CompositeStep |<>-|
----------------      ----------------------------------

"Feature" is a place-holder which in a real diagram might 
be several feature classes like TransactionConstraint and
OrderingRule.
The names of the classes are not critical.  I just used
simple names to get the ideas across. If this proposal
is accepted, I may have other suggestions for better
names.

This design would solve all the problems I have with
excess complexity, as well as using the design pattern
that has become a defacto standard for this kind of
problem.  It can also be elaborated with more specialized
subclasses of BusinessProcessComponent as needed,
without adding unecessary hierarchy levels for simple
situations.

Respectfully,
Bob Haugen
=======================================================================
= This is ebxml-bp, the general mailing list for the ebXML            =
= Business Process project team. The owner of this list is            =
= owner-ebxml-bp@oasis-open.org                                       =
=                                                                     =
= To unsubscribe, send mail to majordomo@lists.oasis-open.org with    =
= the following in the body of the message:                           =
=      unsubscribe ebxml-bp                                           =
= If you are subscribed using a different email address, put the      =
= address you subscribed with at the end of the line; e.g.            =
=      unsubscribe ebxml-bp myname@company.com                        =
=======================================================================