Fw: proposal for simplified/reusable binding

I was going to make slides with this, but Kevin's note is pretty
self explnatory. Kevin, my apologies for forwarding without
your permission! HOpe that's ok .. just for this one time :).

Kevin's list below doesn't have the default binding stuff, but
I'm pretty sure he's not against that. So the proposal is to
do the set of things listed below as well as the default bindings
as we discussed in Rennes.

Sanjiva.

----- Original Message -----
From: "Liu, Kevin" <kevin.liu@sap.com>
To: "'Sanjiva Weerawarana'" <sanjiva@watson.ibm.com>
Sent: Tuesday, July 01, 2003 8:10 PM
Subject: proposal for simplified/reusable binding


> Hi Sanjiva,
>
> In summary, to my understanding, our current proposal is
>
> 1.  remove binding@interface attribute
> - allow one to define a binding that applicable to multiple interfaces
>
> 2. make everything under <binding> optional and make interface operation
Qname referenceable (need fixes to current draft)
> - allow one to define bindings for different levels, eg interface-scope,
operation-scope,  or full-scope (just like in 1.1)
>
> 3. add a service@interface attribute
> - limit a service to provide endpoints for a single interface
> - Note: if 1.2 still allows a services to reference multiple interfaces,
the interface attribute can be added to the endpoint level
>
> 4. add endpoint@bindings attribute
> - allow one to compose interface (specified in <service>) and
bindings(list of qnames specified here). For example, One can define an
interface-wide <binding>, a few operation-wide <binding>s and then tie them
together with a single <interface>.
> - will clearly specify that operation "subsetting" in binding is
disallowed (as the result of the composition, there should be a one to one
mapping for operations defined in the interface and that for the bindings)
>
> 5. Allow inlined binding definition under <service> and <endpoint>
> - will clearly specify rules for conflicts resolution when multiple
bindings present in endpoint@bindings and/or inline (the closest/latest one
wins)
>
> Depends on the group's decision about if we want to keep message, the
proposal maybe extended to define some "message level" binding. But I agree,
it's not necessary to go there now.
>
> If we are in the same page now, can you please add some examples (from
your original slides) and send a message to the WSD list? I could have done
that, but I think you are more qualified to make sure everything is working.
>
> BTW, Sorry for the late reply. I was a little concerned about backward
compatibility and was inclined to make binding@interface optional instead of
just remove it, but after thought more about it, I found my concern was not
necessary. Basically, if my summary above is correct, the only challenge for
migrating from 1.1 to 1.2 is to remove the binding@interface attribute and
add it to service@interface. (or maybe multiple services if 1.2 finalize the
decision to limit a service to a single interface). Such transformation is
easily doable with xslt and I don't concern it as a backward compatibility
issue.
>
> Best Regards,
> Kevin

Received on Thursday, 3 July 2003 10:57:07 UTC