Re: A proposal for supporting property binding

Amy,

What, you're not using Lotus Notes? :-)

More below.

Cheers,

Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624

Amelia A Lewis wrote on 10/28/2002 02:29:45 PM:

> 
> (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.

Sounds about right.

> 
> 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).

Okay, I think I see where this is going...

> 
> 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.

I raised a similar ddos attack scenario when reply-to came up in ebXML.
So, you see this as a two way street, interesting. I don't think I caught
that in my read of the proposal. This gets into what is interface and what
is implementation IMO. I think it important to spell out the interface
aspects. e.g. the spec writers of a feature and its binding to a protocol
can stipulate that property X is bound to protocol element Y, always...
How the implementation maps the value to assign to property X is 
implementation
detail.

> 
> 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.

right...

> 
> 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.

The proposal I offered had each feature identifying its own bindings
of properties to protocol elements. The only time this gets tricky is
if for some reason, two features map separate properties to the same
protocol element. Reuse of properties can mitigate against this problem.

> 
> 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.

Agreed, but each feature can map its properties to protocol elements
specific to a bound protocol, no?

> 
> 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.

Sure you can. My proposal is feature-specific, with a mapping of the
feature to one or more protocol bindings. A binding can then be decorated
to indicate which features are in play. As I've mentioned, this may need
some thought, and maybe there need to be some 
collision-detection/avoidance
measures written in as caveats to feature binding authors, but I think 
that
this approach can work.

> 
> 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.

Again, when you design a feature and then map that to a protocol binding,
you are in a sense extending the protocol binding and hence you must be 
aware
of at least that much.

> 
> 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.

Indeed, but again, I don't think that this proposal precludes a 
roll-your-own
approach, the feature and its bindings are just not widely adopted. You 
can
put all of this in your wsdl if you want, but it need not be baked into 
the 
wsdl:binding necessarily.

> 
> 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.

Yes, but I was thinking that the binding would be decorated with just
a list of features supported (or prohibited) and that the binding details
would be derived from the feature/featureBinding for the relevant 
protocol.

> 
> So.  Are any of these convincing cases?  I do need to finish the WSDL

Yes.

> extension document for the email binding, because I think that would
> give a better (more complete) ground for discussion.  In fact, it would

Agreed.

> 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.

Absolutely! That would be quite useful IMO.

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