RE: Proposal for LC73/LC75n (multiple interfaces for a service)

Hi Roberto!

> Although it would be possible to define a new component in 
> WSDL with the desired
> semantics (a "service group" maybe?), we believe that the 
> common case is one
> where a service is exposing different interfaces to different 
> classes of users.
> Consequently, it is desirable to use the term "service" to 
> denote such an entity.

See, this right here is pretty much a religious issue.  From my POV, a
"service" is intimately wrapped up with the particular context/view that
the outside world is using to communicate with said service.  In other
words, the MailMan "service" on my Solaris machine which allows users to
control their accounts is in my view a different "service" than the
administrative interface I use to monitor/control mailing lists, even
though they both relate to the same back-end "thingies" (trying not to
use arguable terms like "object" or even "resource").  So for me (and
apparently lots of others), our current "service" is exactly right.

We argued long and hard about the one-interface-per-service issue, and I
think we made the right decision to have a construct in WSDL that means
precisely "a collection of zero or more <endpoints> all making the same
<interface> available, plus arbitrary extension metadata".  This makes
tooling much easier for both tool authors and users to deal with; in
particular I can point to this construct and say "generate me a stub
that can call that thing" without needing checkboxes on the UI or
complicated code to select which interface(s) to utilize.  This
construct is currently called "service", and we decided that if there
was going to be another construct (like "serviceGroup") it would be
defined elsewhere.

One more comment, then my wrapup:

> WSDL authors shouldn't be forced to bind all the operations 
> in a giant "Foo+ServiceManager"
> interface for every endpoint that they expose, especially 
> considering that
> management operations are likely to require different 
> protocols/features/modules
> than ordinary ones. Also, this complexity might well leak 
> onto the client,
> affecting client developers even if they are not in the least 
> interested in
> using the management functionality.

And putting multiple interfaces into a <service> won't??

Don't get me wrong here - I am a proponent of being able to associate
multiple interfaces with a given "thingy", and have smart
(management-aware, say) tooling able to take advantage of such metadata.
I am not, however, a fan of doing this by simply flattening all the
endpoints into one <service>.  When we discussed this last year [1], I
didn't feel like the group had a good enough handle on things to fully
specify what <serviceGroup>/targetResource meant, and therefore if we
put it in the spec we'd be doing a half-baked job.  We were on a
simplification tear at that point, so I proposed pulling both.

I am still *strongly* against the idea of allowing multiple interfaces
per <service>, which I think was/is a nightmare for tooling with WSDL
1.1.  But if this is a serious desire from enough parties, I would
propose that we go back and re-consider one of last year's proposals,
and just deal with defining it better.  In particular, I'd probably
prefer targetResource="" come back since it's easier to add new
<services> out-of-band which refer to the same targetResource.

Thanks,
--Glen

[1] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jul/0121.html

Received on Monday, 29 November 2004 17:33:08 UTC