RE: Example RN PIP 3A4 in BPSS

[Jean-Jacques Dubray <jjdubray@exceloncorp.com>]

Kurt:

I don't intend to define the correct usage. At best I have expressed a
reasonable design guideline that people are free to follow or ignore. I am
sure that "packages" can avoid the cut and past business. It would not be
able to be decoupled if the document format was referenced directly inside
the Business Transaction. So I could edit my package of document definitions
without touching the collaboration definitions.

I did not know it was decided to use XPath in the from/toBusinessState
attributes:
<Start
toBusinessState='../BusinessTransactionActivity[@name="CreatePurchaseOrder"]
'/>

I though one could just reference the name "CreatePurchaseOrder" as the
attribute value. What does it buy you to use an XPath on the collaboration
definition itself?

I found this in the spec that might suggest the two proposals are not
equivalent:

toBusinessState 	The value for this parameter supplied for a
DocumentEnvelope is an assertion by the sender of the DocumentEnvelope
regarding its intent for the transaction to which it relates, but does not
bind the recipient, or override the computation of transactional success or
failure using the transaction's guard expressions

guardExpression 	An expression whose evaluation results in TRUE or FALSE to
determine if this transition should happen or not. The expression can refer
to the name or content of the document in the most recent DocumentEnvelope.

I am assuming guardExpression binds the recipient. Otherwise they look
equivalent to me. It features the advantage to dissociate the sequencing
rules from the document format so I like the former proposition (3a4_A.xml).

JJ-

-----Original Message-----
From: Kanaskie, Kurt A (Kurt) [mailto:kkanaskie@lucent.com]
Sent: Monday, May 07, 2001 3:48 PM
To: 'jj@exceloncorp.com'; Bob Haugen; ebxml-bp@lists.ebxml.org
Cc: 'ebxml-ccbp-analysis (E-mail)'; 'ebXML-PoC'
Subject: RE: Example RN PIP 3A4 in BPSS

JJ,

Warning, strong coffee recommended :)

I agree with your statements in principle. I'm all for reuse and
standardization. Clearly evaluating document contents is not needed when
there is a one to one relationship between the intent and the message. But
when a single message is used to convey both positive and negative responses
something is needed. This is the case for both RosettaNet and OAG.

Therefore, considering the fact that two of the more popular standards
(RosettaNet, OAG) do not follow your "good design principle" the use of
XPath is (IMHO) the best recommendation. Without it, how would we use the
BPSS with these standards?

The real question/issue I see is how to specify this using the BPSS. I've
struggled with this concept before. What is the relationship between
"isPositiveResponse" in the DocumentEnvelope and  "guardExpression" in
BinaryCollaboration/Success and BinaryCollaboration/Failure? And what are
real world examples. Initially I used two DocumentEnvelopes with an XPath in
isPositiveResponse to indicate positive and negative. Then after some
discussion with the BP team, it was expressed that this should be in the
guardExpression. I thought the RosettaNet example was the correct usage.
Again, I am struggling.

Since a BinaryCollaboration references a BusinessTransaction, and since a
BusinessTransaction defines Activities which in turn reference
BusinessDocuments and potentially XPath expressions, a BinaryCollaboration
will never be able to be completely decoupled. So the best case scenario is
that the same BinaryCollaboration is reused (copy/pasted) with reference to
a different BusinessTransaction (one change). Worst case is the same
BinaryCollaboration is reused (copy/pasted) with reference to a different
BusinessTransaction and changes to each guardExpression (three changes).

To help work through this issue and to come to a standard resolution and
recommendation, consider the two instances of the RosettaNet 3A4 PIP
attached.
* RNPIP_3A4_A.xml uses a single DocumentEnvelope with an XPath expression in
isPositiveResponse. In this example what goes in guardExpression? Does a
guardExpression of "true" imply the result of the isPositiveResponse
expression. If so, I would like this to be explicitly stated in the spec.
* RNPIP_3A4_B.xml uses a single DocumentEnvelope with XPath expressions in
each guardExpression. Although it does not follow the "good design
principle" it is explicit and deterministic.
 <<RN_PIP_3A4_A.xml>>  <<RN_PIP_3A4_B.xml>>
Lets decide which is the correct usage or propose "the" correct usage.
Best Regards,


________________________________________________________________
Kurt Kanaskie
IT Architecture Strategy Group
Lucent Technologies
kkanaskie@lucent.com
(610) 778-1069

 -----Original Message-----
From:   Jean-Jacques Dubray [mailto:jjdubray@exceloncorp.com]
Sent:   Monday, May 07, 2001 12:46 PM
To:     Bob Haugen; jj@exceloncorp.com; Kanaskie, Kurt A (Kurt);
ebxml-bp@lists.ebxml.org
Cc:     'ebxml-ccbp-analysis (E-mail)'; 'ebXML-PoC'
Subject:        RE: Example RN PIP 3A4 in BPSS

Yes, this is what I meant. This is the benefit of decoupling sequencing
rules from document format. I am sure that most people would agree that they
want to keep their collaboration definition identical when B2B standards
come up with new and improved releases.

For instance, the OAG, which is one of the oldest and most respectable of
these standard bodies, has now published 182 document schemas, that are
supporting about 60 different collaborations in 7 major releases (not to
count the minor releases). I can't imagine people tweaking their business
processes because a format has changed.

Of course this is a design guideline, it is good that the specification is
open enough to support the case where one has no other choice but to write
an XPath on the content on the message like in the case of RN.

Not to mention that since this collaboration definition is designed to
provide a view agreeable by two or more parties, we will not avoid writing
XPath predicates that may start discussions such as "I meant this element
not this one"...

JJ-



-----Original Message-----
From: Bob Haugen [mailto:linkage@interaccess.com]
Sent: Monday, May 07, 2001 12:16 PM
To: 'jj@exceloncorp.com'; 'Kanaskie, Kurt A (Kurt)';
'ebxml-bp@lists.ebxml.org'
Cc: 'ebxml-ccbp-analysis (E-mail)'; 'ebXML-PoC'
Subject: RE: Example RN PIP 3A4 in BPSS

Jean-Jacques,

Would this be an accurate paraphrase of the idea you expressed below:
keep collaboration logic in the collaboration model - don't make it
dependent
on the document contents - so you can use the same collaboration
logic with different document formats?

(I'm not trying to rewrite your message, just to confirm that I understand
the idea, which I think I support...)

Thanks,
Bob Haugen


-----Original Message-----
From:   Jean-Jacques Dubray [SMTP:jjdubray@exceloncorp.com]
Sent:   Monday, May 07, 2001 9:56 AM
To:     Kanaskie, Kurt A (Kurt); ebxml-bp@lists.ebxml.org
Cc:     'ebxml-ccbp-analysis (E-mail)'; 'ebXML-PoC'
Subject:        RE: Example RN PIP 3A4 in BPSS

Kurt:

Thanks for this great work.

I would like to emphasize one point: we should avoid using XPath expression
on the message document because this makes collaborations much less reusable
across standards. I understand that this is not feasible in the case of RN
but moving forward, a good design principle would be to use distinct
document formats to express different intend. The binding at the format
level would happen in the DocumentSpecification.

This might look like a little step one way or the other, however, converging
at the "business collaboration" level is even more important than converging
at the format level. Formats can most often be mapped to each other, it can
quickly become un-manageable to map and adapt business processes to a slew
of nearly identical collaborations. Once a collaboration is in place an
agreed upon by an industry or an eco-system, it is relatively simple to
manage N different document formats flowing through the same infrastructure
as they are nicely decoupled from each other.

Jean-Jacques Dubray, Chief Architect
eXcelon Corp.

-----Original Message-----
From: Kanaskie, Kurt A (Kurt) [mailto:kkanaskie@lucent.com]
Sent: Friday, May 04, 2001 12:51 PM
To: 'ebxml-bp@lists.ebxml.org'
Cc: 'ebxml-ccbp-analysis (E-mail)'; 'ebXML-PoC'
Subject: Example RN PIP 3A4 in BPSS

All,

Attached is an ebXML Business Process Specification XML document for
RosettaNet PIP 3A4 version 1.4 that I did as a personal POC. I think it is
correct, but if someone finds a mistake or I left something out, please let
me know. Some interesting points:
* Use of Packages to represent Cluster, Segment and PIP
* Use of guardExpression and XPath to determine the response type, since
RosettaNet uses the same message for both positive and negative responses.
* Use of XPath to reference other elements.
* Only 74 lines of XML for the entire PIP!
 <<BPSS_RN_PIP3A4_example.zip>>
Best regards,

P.S. I will not be able to attend the Vienna meeting, hope it is a great
one!

________________________________________________________________
Kurt Kanaskie
IT Architecture Strategy Group
Lucent Technologies
kkanaskie@lucent.com
(610) 778-1069



------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-bp-request@lists.ebxml.org


------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-ccbp-analysis-request@lists.ebxml.org