Re: Can someone recap the differences between @serviceGroup vs. definitions-targetNamespace ?

On Wed, 16 Jul 2003 21:17:43 +0600
"Sanjiva Weerawarana" <sanjiva@watson.ibm.com> wrote:
> "Jim Webber" <jim.webber@arjuna.com> writes:
> > 
> > Can we just not go back to allowing mulitiple interfaces per service
> > and declare victory?
> 
> Hmm. As was discussed in Rennes, WSDL 1.1's <service> element had
> no meaningful semantics and we wanted to provide some valuable 
> semantics. 

I agree with this principle, but not with the means used to attempt to
achieve it.  I don't believe that the single interface per service
modification *does* achieve the goal of providing valuable semantics.  I
can understand why it is interesting to folks needing to retrieve
WSDL-defined services from registries, but I am increasingly of the
opinion that this is a flaw that the registries ought to address, not a
flaw that WSDL ought to "dumb down" for.

I think that the goal of adding semantics to service is most
parsimoniously achieved by stating that "all endPoint elements in a
service element represent endpoints exposing interfaces bound to the
same web service.  If the bindings of the endpoints implement identical
interfaces, the endpoints may be regarded as equivalent.  If they
implement different interfaces, they represent different interfaces
accessing the same web service."

This has the great advantage of requiring description of the concepts
which appear in the WSDL as tags: parsimony.  "What is a web service"
remains a question, but one that we can dump on WS Arch ("whatever they
define it as, that's what goes in the wsdl:service element").

I don't much like the printer example, so I'll provide another.  Suppose
I want to enable a business to business marketplace for quite small
businesses--mom and pop shops, in the vernacular.  These folks have
email, but only appear on the web as clients, not as servers.  Suppose
I've got an email binding that supports at least request/response,
one-way, solicit/response, and notification (to use WSDL 1.1 pattern
names).

<interface name="ma-pa-market-admin">
  <operation name="subscribe" pattern="request-response" />
  <operation name="unsubscribe" pattern="request-response" />
  <operation name="options" pattern="request-response" />
  <operation name="set-signature" pattern="request-response" />
  <operation name="get-information" pattern="request-response" />
  <operation name="submit-offer" pattern="one-way" />
</interface>

<interface name="ma-pa-market">
  <operation name="offer" pattern="solicit-response" />
  <operation name="end-offer" pattern="notification" />
</interface>

<binding name="ma-pa-market-admin-binding"
interface="ma-pa-market-admin">
  <defaultBinding extension="soap"><!-- more here --></defaultBinding>
</binding>

<binding name="ma-pa-market-admin-web-binding"
interface="ma-pa-market-admin">
  <defaultBinding extension="soap"><!-- more here --></defaultBinding>
</binding>

<binding name="ma-pa-market-binding">
  <defaultBinding extension="soap"><!-- ditto --></defaultBinding>
</binding>

<service name="ma-pa-market-service">
  <endPoint name="ma-pa-market-admin-port"
binding="ma-pa-market-admin-binding">
    <soap:address location="soaperdomo@mail.ma-pa.org" />
  </endPoint>
  <endPoint name="ma-pa-market-admin-web-port"
binding="ma-pa-market-admin-web-binding">
    <soap:address location="https://www.ma-pa.org/marketplace/admin" />
  </endPoint>
  <endPoint name="ma-pa-market-port" binding="ma-pa-market-binding">
    <soap:address location="marketplace@ma-pa.org" />
  </endPoint>
</service>

I *want* these bound to different endpoints, because I definitely don't
want administrative traffic (subscription, unsubscription, signature
registry, setting options) on the list itself.  The "submit-offer" bit
might, btw, be either administrative interface or market interface;
depends on the situation (might not even exist, potentially).  All of
the operations in the admin interface can be run over http or email; the
ones in the market interface can't be run, in the given use case, over
http, because mom and pop shops can't afford to set up web servers at
static ip addresses and keep them reasonably secure.

In any event, I hope that this example provides some reason for the
multiple interfaces per service preference, by showing how it can be
used (in a way that may be a little less tendentious than the printer
example?).

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

Received on Wednesday, 16 July 2003 13:53:33 UTC