Re: proposal for restricting a service to a single interface

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 UTC