RE: [ebxml-bp] Document Envelope

["Jean-Jacques Dubray" <jeanjadu@Attachmate.com>]

Again, the requirement here was for different industry standards to
share the same collaboration definition independent as much as possible
from document formats (I am a requirement guy). If there is a better way
to support this requirement I am all for it. This was what we came up
with our limited vision and understanding.

JJ- 

-----Original Message-----
From: Yunker, John [mailto:yunker@amazon.com] 
Sent: Monday, June 07, 2004 11:49 AM
To: Jean-Jacques Dubray; David RR Webber; Monica J. Martin; ebXML BP
Subject: RE: [ebxml-bp] Document Envelope

So, what you are saying is that we should use the "BusinessDocument" as
the contextual link, in essence forcing all context differences to
result in different business document types (I could see document types
"InventoryUnavailableOrderReject" and "DiscontinuedItemOrderReject" and
....)

This was OK short term, but long term this really doesn't address
context drivers.  How about adding a "BusinessContext" element that has
the same structure, and can be referenced in the same manner as the
existing "BusinessDocument" element.  Then one of the
"expressionLanguage" could be CAM, and everything is tied up in a nice
little bow.

John

-----Original Message-----
From: Jean-Jacques Dubray [mailto:jeanjadu@Attachmate.com] 
Sent: Monday, June 07, 2004 10:24 AM
To: Yunker, John; David RR Webber; Monica J. Martin; ebXML BP
Subject: RE: [ebxml-bp] Document Envelope


Do you account for "logical" document specifications? In other words
BPSS 1.1 (like I think 1.0) allows for specifying a business document as
a physical document + a guard. Since BPSS allows for multiple possible
positive responses (but not WSDL), this allows you to "move" the
complexity into the document definition rather than in the collaboration
definition. Therefore making the collaboration (artificially I grant it)
definition independent of the schema of the business document.

Note that guards in the collaboration definition can have explicit
XPaths on business document contents. Originally, this was designed like
this such that collaboration definition could be re-used across vertical
standards (the choreography is the same but the document format is
different). All people would have to do in this case is change the
document definition not the collaboration definition. But again nobody
forces you into that model.

>> We should provide a mechanism for a transition to reference a
business 
>> contextual value other than the envelope.
This is already in BPSS. Do we have a disconnect? Or am I not
understanding your point?

JJ-

-----Original Message-----
From: Yunker, John [mailto:yunker@amazon.com] 
Sent: Monday, June 07, 2004 10:09 AM
To: Jean-Jacques Dubray; David RR Webber; Monica J. Martin; ebXML BP
Subject: RE: [ebxml-bp] Document Envelope

The discussion didn't revolve around these attributes, instead it was
the "isPositiveResponse" and "businessDocument" attributes.  In one
example cited inside the BPSS 1.1 the "isPositiveResponse" is linked to
the "businessDocument" as a way to control behavior ("acceptOrder"
business Document and "rejectOrder" businessDocument map to "true" and
"false" respectively)

However most of the order document exchanges I am involved in have the
"orderRequest" followed by the "orderResponse", and the order response
can have success, failure, and partial success as a result.  The
orderRequest and orderResponse constitute the transaction that results
in the commitment.

JJ, I agree that the attributes you list are the key metadata provided
by the "b2b messaging infrastructure".  

We cannot be as simplistic about the "isPositiveResponse" being the key
driver of choreography, because that requires simplifying business
requests to an "all or nothing" result.  I am VERY nervous about
assigning business success / failure to the envelope.  While this
greatly simplifies implementation, it is simply moving the complexity
around, instead of meeting it head on and working through the proper
mechanisms for communicating the context driving business execution.

We should provide a mechanism for a transition to reference a business
contextual value other than the envelope.  I have long argued for an
expression on transition guards, startsWhen, and endsWhen.  That
expression should have "syntax" and "expression" atttributes, so the
appropriate syntax for the expression may be used.  One of those syntax
could be "CAM", but in any case the result would be either "true" or
"false" and the transition, startsWhen, and endsWhen would use that
result.  Otherwise the sender of the message not only always has control
of the process, they also MUST have access to all information.

John

-----Original Message-----
From: Jean-Jacques Dubray [mailto:jeanjadu@Attachmate.com] 
Sent: Monday, June 07, 2004 9:37 AM
To: David RR Webber; Monica J. Martin; ebXML BP
Subject: [ebxml-bp] Document Envelope


I must admit that I did not follow too well the arguments about document
envelope in the call today.

For me Document Envelope has a series of attributes 

isPositiveResponse 	: maps easily to web service operations
isAuthenticated  		: maps easily to WS-Security
isConfidential  		: requires encryption
isTamperDetectable  	: requires digital signature

All these attributes can be mapped easily to existing WS technologies. 

So I can easily define a binding for these attributes if this document
envelope were to be exchanged in the context of an operation activity,
but I don't have to change their meaning like I would need to do to map
an operation to a business transaction. This actually illustrates my
point is that we can make the ebXML and WS stacks co-exist, but I don't
think we are ready to merge them until ebXML layers itself on top
of/with the WS stack.

Am I missing something?

JJ-