Re: A proposal for supporting property binding (SOAP and others) in WSDL

Dear Chris,

Thanks for the quick, detailed, and insightful response.  There are some
bits I can, perhaps, explain, and some bits where I'm hoping you'll
clarify.

On Sun, 2002-10-27 at 20:31, Christopher B Ferris wrote:
> 1) Why have you chosen xs:string for the type of the algorithm/@name
> attribute? I would 

Good points.  I chose it because I thought of it rather late in the day,
and hadn't thought it through.  I think I like the suggested type
attribute best.

> 2) The use of an open-ended enum for the wsdl:*Property/@locationType
> attribute 
> suggests to me that rather than define this as an enum, that it be
> defined as a QName 

Right.  I thought that that might be a solution, but hadn't gotten to
this level of clarity.

> 3) While having such a formal algebra for mapping the unbound abstract
> properties of 
> a feature is IMO, quite useful, it does not seem to me to be appropriate
> that a WSDL description 
> apply these for *each* binding defined in a WSDL description. I think
> 
> In other words, I think that it would be useful to be able to define a
> feature and its associated 
> properties and property references, and then, for each defined protocol
> binding, define the 
> mapping/binding of the abstract features in a manner such as you have
> proposed. This need 
> only be defined once, and then simply referenced. 

I rather like this, but I have a question: is overriding still
possible?  The difficulty I see with using this as the *only* mechanism
is that it does not give the service creator sufficient flexibility.  A
part of the goal in defining it within the binding is to allow this
flexibility, which may be important (for instance) in fitting an adapter
to a legacy service, or in allowing a service to abide by local network
policies of various sorts.

It also allows the protocol binding to defer binding to the service. 
"This is optional.  Do it yourself, if you need it."

But I really like the example set forth, because it can significantly
lower the cost of this proposal, by removing a lot of what would be,
effectively, boiler-plate.  I just don't want to force all services to
use only the boiler plate, I think, so I think I would still want to
preserve the ability to override, per-wsdl:binding and its children, the
various property bindings, as described in the document.

> Comments on the alternate email binding proposal[2]: 
> 
> 4) Why is the message-id property a xs:string?

Umm.  This will get me in trouble, in all likelihood, but it's largely
because I think defining it as a URI would tend to increase the
deplorable confusion surrounding URIs, by creating yet-another sort of
object that might, or might not, be locatable/retrievable.

If it were to be a URI, the question of how it gets compared comes up. 
Namespaces are supposed to be URIs, but aren't compared by URI rules. 
Keeping it as a string allows someone (if they want) to use a URI (well,
W3C XML Schema doesn't think URIs are strings, but most of the world
does), without, in effect, saying "this is a thing that has the type
used as a pointer (or reference) in the XML world."  Because I don't
know if it's possible, in all cases, for it to have pointer/reference
semantics.

> 5) The feature for MIME composite messages should be (IMO) a realization
> of/binding to 
> the SOAP1.2 Attachment Feature[3]. I believe that this (MIME Composite)
> isn't a feature as much 
> as a feature-specific binding. 

Hmm.  Possibly.  I need to look at the attachment feature again.  One of
the goals in producing the set of proposals was to attempt to produce
feature sets which were as small as possible.  Partly, this is to show
that it can be done.  Partly, I think that such well-defined/well-scoped
features may be more easily implemented than larger-scale
specifications.

Partly, mime-composite exists because there was a need for
mime-content.  That is, the mime-content feature represents simple (in
the sense of "not composite," not in any other meaning of the word
"simple") MIME.  A set of headers and encodings; it is easy to imagine a
service that doesn't want the complexity of attachments, but does want
the labelling and codecs of MIME.  Having defined mime-content, it
seemed almost required to define mime-composite as a feature.  It may
not be, though.  And it may be that I can reconcile the (rather
minimalist, and depending upon mime-content) mime-composite feature with
SOAP 1.2 Attachments.  JJM clearly expressed support for such an effort.

> 6) Why have you chosen to separate out the Failure Destination feature
> from the Message Address feature? 

Largely because failure destination isn't "core" to my mind, and I was
attempting to ensure that each feature was defined in as small, and as
clearly bounded, a scope as possible.

Adding failure-destination as a required feature to one-way and
notification MEPs, for instance, has the lovely bonus, without requiring
message addressing, of allowing one to test interoperability.  In their
current definitions, one-way (and implicitly notification) are supposed
to do the same thing for error as for success.  This is awkward, from
the point of view of verification.  On the other hand, it might be
needed for certain production services.  Providing a capability of
supplying failure-destination seems quite useful.

But it isn't, to my mind, associated with message addressing,
necessarily.  Sender, target, and reply-to addresses form a tight core
of what to do when things work as they should.  SOAP in general
separates out fault processing from normal flow; supplying a property
designed to allow more flexible addressing in the case of faults seems
also to require the property to be in a feature separate from those
designed for normal traffic flow.  Further, there are some possibilities
of adding to the property set of failure destination (multiple
notifications, path/routing sorts of things).  So I thought it best to
keep it out.

I'll note, though, that this question has been raised before, in pre-pub
review.

> Message Address has a response-address property. Seems to me 
> that the fdest:failure-destination sh/could be incorporated into the set
> of address properties and that in some cases, the failure-destination would simply be a
> reference to the response-address 
> property (which itself might be a (defaulted) reference to the
> original-source property). 

Absolutely so, but I certainly don't think that this defaulting
mechanism creates any requirement that all participating properties
belong to the same feature set.  I would oppose such a restriction of
the defaulting mechanism.

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

Received on Monday, 28 October 2002 10:28:52 UTC