Re: A proposal for supporting property binding

Christopher (and other interested parties),

On Mon, 2002-10-28 at 19:16, Christopher B Ferris wrote:
> What, you're not using Lotus Notes? :-) 

*laugh*  Well, for some reason IBM doesn't support my platforms for the
client.

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

Yes and no.  In the case of email, for instance, this is a property that
has to be communicated back and forth.  Both sides need to be aware of
where the storage location is that will be used for the property.  This
location may not be modifiable (for instance, if it's the IP address
plus port number (yes, I know how to forge IP, too, but at the
application level it's much more difficult than forging SMTP headers)),
but it must be known.  The sender, realizing that the bound location
isn't supportable in his/her environment, might choose to use a
different service, for instance.

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

Hmm.  Interesting problem; I'll add it to my list.

I see it as more likely that the protocol binding will establish the
required/supported feature set, and set up default bindings.  This also
means that the WSDL can have 'minimal reference', referring to the
protocolBinding (if we can call it so) rather than to a collection of
featureBinding and mepBinding.

This breaks down when features are defined after the protocol binding is
published.  Still, the feature (or MEP) ought to be defining only
abstract properties (or exchange patterns), not binding information.  An
annex/appendix to a feature/mep publication might establish such a
binding for protocols known to the feature/mep developers, but a
mechanism for others to establish bindings should also be in place.

Or, in other words, we should probably strive to permit the publication
of featureBinding, mepBinding, and protocolBinding in any order, and
establish rules for the union of multiple references, rather than
striving to establish an unenforceable order of publication.

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

For known protocols, certainly, and so long as doing so doesn't, to the
reader, imply that these are the only protocol which can be bound.  As a
feature writer, I'm likely to want to see what I've worked on broadly
adopted.

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

I'll provide an update to the property binding document incorporating my
take on this, if that's acceptable.

On reviewing the proposed outline (in your original response, which set
forth a schema-pattern for these things), so that the email binding
could use that model, I discovered the property definition section.  I
think that these are not necessary; only bindings of properties are
necessary, their characterization in XML is not.  I can expound on that
if you wish (it took more senior architects here a couple of days to
convince me that an XML description of a feature, while possible, is
either superfluous or insufficient, but that seems to be the case).

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

But when you design a feature, you may not bind it to a protocol. 
Someone else may do so.  I think that the service ought to be able to do
this, if necessary.

> put all of this in your wsdl if you want, but it need not be baked into
> the 
> wsdl:binding necessarily. 

Okay.  Revised proposal to be supplied.

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

*laugh*  I'm gonna tell my bosses that I've forgotten how to write
English, and from now on can only communicate in code ....

System.exit(Amy!);
-- 
Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Wednesday, 30 October 2002 10:14:53 UTC