RE: Comment

[srh@us.ibm.com]

Bob,
Sorry for the delay.

|Scott Hinkelman wrote:
|>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.
|
|I don't understand. The level of detail in the narrative can
|remain the same, by composing the optional features
|as required - or so I think.  What am I missing?

I'm just mostly concerned with the terms in the narrative turning into the
Composit Participants like "Composite" and "Leaf", but this could be
avoided.

|>Upon looking at this further, I would think that by nature
|>the StepDefinitions are in fact a sequence within the BPD,

|If  they had OrderingRules, they could be sequenced.
|But I am proposing to move the OrderingRules, so that any
|Composite could have sequenced members.

I understand. I'm just making some assumptions that at the top it is not
needed and there is an implied sequence. Perhaps this is insufficient,
but I'm striving for complexity onlt when needed. I'm assuming you are
thinking
to add the ordering rules at the Composite.

|>so perhaps add <<ordered sequence>> to the by-value aggregation
|>from BPD to StepDefinition.

|Sequence rules are not always the best way to transition from
|one step to another (using step in a generic sense).

|>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".

|Correct.

|>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.

|You lost me there.  As far as I know, ebXML is only considering
|economic events that are realized thru B2B messages.  (Of course
|lots of other economic events may occur, but they are beyond the
|scope of ebXML as far as I know...)

Of course. Don't disagree on the scope. This is just an expansion of what
you answered 'correct' to above.

|>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.

|If you are considering the current V2.0 metamodel, I would agree.
|I was referring to a much-simplified BusinessProcessDefinition
|hierarchy which did not have a BusinessTransaction class, where
|business transaction logic was invoked by adding a
|BusinessTransactionConstraint feature to whatever
|BusinessProcessComponent needed it.

I'm only looking V2 and intention to understand how to integrate tpaML.
The TRP group has concensous that some form of tpaML will act as
configuration information for the Transport runtime.

|>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.

|That is one possibility.  But then how do you handle optional
|steps like product returns?  And that is only one example
|where a straight sequence may not be the best model -
|maybe a state transition model would be better in some cases.
|("OrderingRule" was kept deliberately abstract to accomodate
|any notion of transitioning.)

Perhaps its another BPD? I think it depends on the BP granularity.
I amy be off on this but still striving for simplicity where possible.

|>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 missed your point again, sorry...

Again an extension of before. I'm picking on an issue without doubt
outside ebXML, which I will stop.
(I have have trucking Contract for physical delivery of the product.
I that was included in the BP, and a Step may be outside ebXML,
you need a Contract at the Step.) Enough said on issues ouside, but
it may be unhealthy to limit conversation only within scope.

|>I see the BusinessTransaction as the specialialization of a Step
|>in the B2B space intended to be a unit of electronic business.

|That is certainly the intention of the current metamodel, which
|has the flaws noted by Karsten and others.  But, the Composite
|pattern could be used and still have a specialized BusinessTransaction
|class instead of the optional BusinessTransactionConstraint feature
|at the top abstract class level - in other words, the Composite
|pattern and the optional feature idea are separable proposals.

|>I get all of the narrative about PartnerRole, Initiator, etc.
|>It appears there could be value in specializing PartnerRole with
|>Initiator and Responder................

|Something like that would make sense. I'm not sure PartnerRole
|specialization is the way to do it. The Edifecs/RosettaNet metamodel
|designates Requesting and Responding Business Activity stereotypes,
|and Request/Response as a Business Collaboration Pattern.

Yes some other composition may make sense.

|>The whole thing then overlaps with TRP at Information Exchange.
|>To TRP, this is called a MessageSet. [Side note is that by my

I think you agree on the rest that was chopped.
Scott Hinkelman