W3C home > Mailing lists > Public > www-ws-desc@w3.org > April 2003

Re: proposal for restricting a service to a single interface

From: Kenneth Chiu <chiuk@cs.indiana.edu>
Date: Wed, 30 Apr 2003 18:31:55 -0500 (EST)
To: "Amelia A. Lewis" <alewis@tibco.com>
cc: www-ws-desc@w3.org
Message-ID: <Pine.GSO.4.53.0304301822370.24778@rainier.extreme.indiana.edu>

On Wed, 30 Apr 2003, Amelia A. Lewis wrote:
> On Wed, 30 Apr 2003 14:34:14 -0400
> Glen Daniels <gdaniels@macromedia.com> wrote:
> > - We should give some guidance as to how to deal with
> >   extension-specific (i.e. bindings or modules) ways of
> >   achieving patterns like asynchrony, pub/sub.  I think this
> >   should be a separate conversation.  As you say, it isn't
> >   solved now, so we need to solve it.  I'd prefer to do so
> >   as a modular entity instead of mixed up with <service>
> >   definitions.
>
> What?  I don't understand at all, I'm afraid.
>
> Is this going back to the whole application-level subscription stuff?
> Most pub/sub protocols don't expose subscription at the application
> level.  It is enough to describe the publication destination; the client
> already knows how to handle subscription, and subscription doesn't use
> XML messages (as a rule).
>
> It looks like someone *really* wants to make this stuff hard.  Why?

Couldn't you make the binding elements more flexible so that
a single interface binding can have different operations
bound to different MEPs/protocols?  It seems that this would not
necessarily make things more complex:

    <binding name="Binding1" type="tns:Interface">
        <operation name="ReqResp">
            <soap:operation location="http://example.com/" ...>
                ...
            </soap:operation>
        </operation>
        <operation name="Notification">
            <multicast_proto:operation ip="..." ...>
                ...
            </multicast_proto:operation>
        </operation>
    </binding>

    <service name="MyService">
        <port name="Port1" binding="tns:Binding1"/>
    </service>

I know this is incomplete and flawed, but perhaps the
general approach might be workable.
Received on Wednesday, 30 April 2003 19:32:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:23 GMT