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

Amy

Please see my comments/responses 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 10:28:24 AM:

> 
> Dear Chris,
> 
<snip/>
> 
> > 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.

overriding of what? maybe I'm missing something. If a feature is described
in terms of its properties and the state transitions, what's to override?
If I map those abstract properties to a specific protocol, the values may
change, but the properties do not. I would like to see a use case where
there might be case-by-case modification as to where the properties are 
bound
for a given protocol binding that would necessitate the need to be able to
specify unique bindings based on the type of service.

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

hmmm... that's not how I would see it. I could see association of
a feature with a given binding or not, but the mapping between the
feature's properties and the underlying protocol (when the feature is
in scope) should be consistent for all usages IMO. Thus, it is one
thing to associate a feature and another to map a feature's properties
to an underlying protocol(s). IMO, you shouldn't need to specify the
mapping every time you associate a feature. The mapping is canonical,
the association is variable. Should keep them separate.

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

Again, think that we need to understand what specific use cases there
might be to warrant this overriding on a per-portType basis. 

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

yeah, we don't need to open up that can of worms. However, I still feel
that URI is preferable in this circumstance, even if they are only
relative to some xml:base URI that might be (ex|im)plicit to the 
message/conversation, etc.

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

yeah, I know (sigh)...
 
> 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.

Understood. Still think that string is too ambiguous. At least with a
URI, it has well defined 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

I still feel that these are both bindings.

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

Think it would be a worthwhile exercize.

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

I don't disagree that failure-destination is useful, just think that
it belongs with addressing. Even for one-way and notification MEPs, the
origin-source applies. Maybe if the failure-destination extended the
message-address feature... Still, I don't think of this as a separate
feature.

If you wanted to build up from a core... then it would seem to me
that original-source + failure-destination would be core (and 
failure-destination
could be null). taking oneway and turning that into req/resp would add
in response-address.

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

only for req/resp. not all things are req/resp:)

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

I wasn't imposing such a restriction... just pointing out that in this 
case,
I thought they belonged together:)

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