Re: [ebxml-bp] Document Envelope

["David RR Webber" <david@drrw.info>]

John and JJ.

These are all excellent points!

I'm going to try and craft something from the
work I've done so far on the model and
context.

I'm not seeing any issues here - it will just
come down to how best to piece this
together so we achieve all the desired
results.

Anyway - I won't get a chance till tomorrow
at earliest on this - but the input is a great
help in defining the boundaries needed.

Thanks, DW

----- Original Message ----- 
From: "Yunker, John" <yunker@amazon.com>
To: "Jean-Jacques Dubray" <jeanjadu@Attachmate.com>; "David RR Webber"
<david@drrw.info>; "Monica J. Martin" <Monica.Martin@Sun.COM>; "ebXML BP"
<ebxml-bp@lists.oasis-open.org>
Sent: Monday, June 07, 2004 1:08 PM
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-