Re: A proposal for supporting property binding

(meant to send this to the whole list ...).

Christopher,

I'm going to avoid quoting, since my mailer seems to hate your mailer,
and introduces all sorts of line break ugliness.  I want to address the
question of: why override if a protocol binding document exists to map
abstract properties to storage locations?

I'm working on the binding (WSDL extension) document for the email
proposal.  *sigh*  It isn't done yet, though, and it's certain to
contain something in the format that you suggested earlier, now.  Let's
take some of those properties, though.

For a general-purpose email binding for WSDL, the following property
bindings seem to me to be the most likely to be generally agreed:

address:original-source is bound to protocolHeader From.

address:final-destination is bound to protocolHeader To.

address:response-address is bound to a sequence: first to protocolHeader
Reply-To, and in its absense to address:original-source.

faildest:failure-destination is bound to address:response-address.

Now, I'm working in an enterprise, and I'm concerned with a
solicit/response pattern over email.  After initial production, we
discover that handling normal stuff is okay, because only a few of the
solicited nodes respond.  A failure provokes a blizzard that clogs the
server temporarily, because everybody detects the error and sends a
response.  For a variety of reasons, we can't move the server.  My
service wants to override faildest:failure-destination.  We want to
supply a binding to X-Errors-To (we're going to point it at a different
server, and have that different server process all the failures and
aggregate results before forwarding, substantially reducing load on the
main server).

Second case, same basic scenario.  I'm using the published email
binding, with response-address bound to Reply-To.  Someone has
discovered that my service can be used to harass people; they send email
with Reply-To set and these strangers send me irate complaints.  I want
to change settings.  My first reaction is to forbid the use of Reply-To,
by rebinding, in my service, response-address to original-source.  That
stops the skiddies for a week or two, and then they learn how to forge
SMTP.  For whatever reason, I can't filter the cruft.  I examine specs,
and decide on a more-or-less built-in solution (this is breakable too,
but it's harder, for a variety of reasons).  I keep my response-address
binding, but now I rebind original-source to protocolHeader Return-Path.

There are some examples of *override*, which might require the use of
binding in the WSDL.  I note, with continuing approval, that the
technique of pointing at the binding document means that the only things
that I have to put in my WSDL are the ones that I want to change from
default, and if the defaults are well-chosen, then the amount in the
WSDL should be minimal.

Another scenario for "overriding" is not overriding at all, but
enhancing.  Let's say that SOAP 1.2 is published, with certain features,
and a note is published with several more, and MEPs, and the like. 
There are protocol bindings for HTTP and email, which address the
features known at the time of the publication.

Now, two new features, by unrelated enthusiasts, are published.  Let's
say "security" and "transactions."  Both are reasonable things to have
features and properties about.  How do I add support in my service?  The
features should not establish bindings; they should concern themselves
with properties and state transitions.

Well, each team could publish supplements to the current protocol
binding documents, adding their own features.  That's enough, if I only
want to use one, but what if I want to use both?  Oops.  I can't point
at two bindings at once.

So, if the primary binding document is defined in such a way that the
universe of storage locations is defined, and I am allowed to express
those directly in my WSDL, then I can pick up an experimental feature
and provide support, and I can provide support for two such experimental
(or merely leading edge) features, without requiring a new draft of the
protocol binding document.  Even if the protocol binding has not
established defaults for the properties, I can establish them in my
WSDL, and anyone who understands the semantics of the features can make
use of the bound properties.

Finally, and perhaps more dangerously politically, what happens when
folks can't agree on appropriate bindings?  It shouldn't stop the
service developers from specifying their own, and creating
interoperability outside the working group.  In fact, it's a robust
means of moving forward, I think.

One more scenario, a little less convincing because the mime-composite
feature is itself somewhat questionable, at the moment.

Suppose that the WSDL extension for the email protocol binding specifies
optional support for composite MIME (SOAP with attachments).  I'm
building a service, and I have limited resources.  Attachments, in my
crotchety old opinion, are worthless eye candy at best, *my* service
doesn't need anything more advanced than ASCII^H^H^H^HUnicode.  Ahem.  I
want to forbid the use of the mime-composite feature.  I ought to be
able to specify, in my service, that although the public binding says
optional, for this service in particular it is prohibited.

So.  Are any of these convincing cases?  I do need to finish the WSDL
extension document for the email binding, because I think that would
give a better (more complete) ground for discussion.  In fact, it would
be useful to have such a document for HTTP, that addresses some of the
features included in the various proposals.  Hmmm.  Just a shortage of
tuits, I'm afraid, round or otherwise.

Amy!
-- 
Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Monday, 28 October 2002 14:30:11 UTC