Re: [ebxml-bp] Document Envelope

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

John,

I think I can cover all this - *including* limited support of startsWhen,
endsWhen...

I'd pretty much got all this in the example model - but let me call out the
details of how and where in the schema it all plugs into - and write a quick
implementers notes on it all.

And here was I thinking this was all how it was supposed to work in the
first place!  Seems like we may already have all we 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 3:54 PM
Subject: RE: [ebxml-bp] Document Envelope


JJ, I agree of both the requirement for, and usefulness of the remapping of
document type to support industry standards.  What I objected to was your
proposal that I use document type as the means of communicating
content-driven-context to the constraints-on-transistion-guards.  ("we
already have that")

Driving transitions based upon content-driven-context has been a requirement
since day one (I've spoken about this since before v1.0).  Meeting that
requirement has always been put off.

What I am proposing is that we put a formal context-mapping-method into the
spec (BusinessContext), and make it consistent in its implementation with
the document-mapping-method (BusinessDocument), and also make this element
usable in the transition constraints.  Make CAM a supported
expressionLanguage, as well as supporting XPATH consistent with
BusinessDocument.

(This still doesn't address my continuing requests for computable startsWhen
and endsWhen, but then the context is more important - walk before we run,
v3.0, etc)

John

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


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-