RE: Revised property binding extensions proposal

I'll go ahead and offer several, based on the protocol binding
description (the WSDL extension for email) that I posted earlier.

1. I am a service using the email binding.  I do not want to accept any
composite MIME messages.  I want to prohibit that feature.

2. I am a service using the email binding.  I want to add explicit
fault-handling.
   a. I want to make failure destination a required feature (which makes
the failure destination property required)
   b. same as a, except that I don't want faults to be sent back; I want
them to be logged, using X-Errors-To (see the commented-out definition
in the binding).

3. I want to explicitly state, in request/response or solicit/response
operations, that addr:response-address is required.

4. I have an S/MIME or PGPMail feature available.  What's in the binding
is fine, I just want to add to it the properties and semantics in this
additional feature.  The developers of the feature kindly supplied me
with a featureBinding that includes a compatible protocolBinding for
email.

The assumption behind all of these is that the protocol binding defines
a set of locationTypes that the processor will have to support.  So long
as the processor is able to understand the locationTypes (that is,
retrieval from/store to a named protocol header is supported, retrieval
from/store to an offset in a protocol is supported, property references
are supported, SOAP headers are supported, and in the case of email,
possibly MIME part headers are supported), then it can easily use the
protocol binding document, a supplemental document for an experimental
feature, or an override in the WSDL itself to specialize the association
of a particular property with a particular location.

The code needs to be touched again only with the addition of new
locationTypes.  This should be relatively rare, on the whole.  Each
protocol may define something new (for instance, JMS properties
correspond, if roughly, to protocol headers, but clearly need a
different code block), but many protocols will share characteristics,
and may not need a new location type at all.  Services can still respond
to local network administration requirements, or service requirements,
to change the targeting for storage of a particular property.

Amy!

On Thu, 2002-10-31 at 14:25, Don Mullen wrote:
> 
> Glen:
> 
> I think I understand your objections regarding added complexity to WSDL.
> From what I understand of what you said in today's call, you feel that
> binding specifications will be defined and that implementations will
> hard-code support of these bindings.  If someone needs to teak a
> binding, they would need to either change the specification (and
> therefore also affect change in all the implementations), or write a new
> binding with the tweaks and encourage implementors to support the new
> binding.  Is that fair, or am I missing something?   If that's the case,
> then I would think only a small set of bindings will be supported, and
> the new, tweaked bindings will not be interoperable.  I would challenge
> Amy to come up with a sufficient use-case that would require minor
> binding changes that need to be interoperable.
> 
> Don
> 
> -----Original Message-----
> From: Amelia A Lewis [mailto:alewis@tibco.com]
> Sent: Wednesday, October 30, 2002 1:47 PM
> To: www-ws-desc@w3.org
> Subject: Revised property binding extensions proposal
> 
> 
> Umm, well.  Here's the *revised* revised property binding proposal, this
> time printed in *visible* ink.  Sometimes one can take confidentiality
> too far ....
> 
> Oh, and I suppose I should warn the timid that the formality level in
> the document is dropping as well, to some degree.  We can fix that by
> reading many stories by Ernest Bramah and applying the principles of
> locution demonstrated therein.
> 
> Heyas,
> 
> Here's the property binding proposal, revised per comments.  This
> removes the "open value" stuff, changes the values of some attributes
> (from string or boolean to QName or enumeration), adds an issues
> section.  Most importantly, it tries to pick up the idea of defining
> property binding information externally to the WSDL, and supply syntax
> both for the definitions, and for the references.  The reference
> mechanism includes a means of combining external definitions, which is
> deliberately kept simple (on the grounds that the per-service overrides
> can supply needed complexity).  The referenced definitions now join in
> the scoping rules for property bindings as well.
> 
> Feedback, of course, is most welcome.
> 
> An example usage is (still!) in progress, illustrating the mechanism by
> using the alternative email binding proposals.  Added to the list of
> useful items to produce is a similar example for the http binding.
> 
> Amy!
> -- 
> Amelia A. Lewis
> Architect, TIBCO/Extensibility, Inc.
> alewis@tibco.com
-- 
Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Thursday, 31 October 2002 14:42:45 UTC