Re: Describing which blobs are to be optimized.

On Mon, 14 Jun 2004 09:48:19 -0700
Ugo Corda <UCorda@SeeBeyond.com> wrote:
> > > > In a pub/sub world, an out-only pattern (or any out-initial
> > > > pattern) is a nice fit, and we expect to see these widely 
> > > > used.  This is because, in pub/sub, the service is talking, 
> > > > not listening; publishing, not serving. 
> > > > The other nodes interacting with the service are not 
> > > > requesters/clients, but listeners/subscribers.
> > > >
> > > 
> > > That's exactly my point. In that kind of scenario, it should more 
> > > important to focus on the endpoint of the 
> > listener/subscriber than on 
> > > the endpoint of the service itself.
> > 
> > No, no, no!  Absolutely not!  The *publisher* defines what it 
> > publishes. 
> > It publishes en masse.  It is not controlled by the 
> > subscriber.  It just spews.  It's up to the subscriber to 
> > separate wheat from chaff.
> > 
> 
> If you are in a situation of brokered notification, the server only
> talks directly to the broker, and the only endpoint of relevance is the
> endpoint of the broker node.

So what?  It's not the scenario I'm concerned with, or that I presented
above, which you claimed supported your original position.

If you're playing at pub/sub over client/server-oriented protocols, you
end up with something like "brokered notification", where each message is
ultimately unicast to a receiver by the broker.  *shrug*  That Does Not
Scale[tm].

I responded to this originally because you asked what the point of
out-only was.  I suggested that it is quite useful in a pub/sub world
(that is, in one in which messages are, at least at a conceptual level,
multicast: the subscriber announces *what* it is publishing (the schema)
and the "endpoint" (JMS Topic, Rendezvous subject, IP multicast address)
that it is publishing on ... any number of subscribers can then listen,
without the publisher having the least knowledge of who, how many, where,
or why they are).  As it happens, This Scales[tm].  Your followup was that
of course I'd need to describe it from the point of view of the listener. 
I objected, vehemently.  You are now pointing out that there are pub/sub
variants that are subscriber oriented.  I don't care; I think that in that
case each subscriber would probably call itself a server and call the
publisher/broker its client.

There is a genuine purpose served by defining WSDL *from the point of view
of the service*, and not: a) from the point of view of the listener; b)
from the point of view of the responder; c) from the combined point of
view of both participants, and more.  All of these possibilities have been
discussed, and the result was that the formula adopted was "from the point
of view of the service" and this is made clear very early in part one. 
"Service" may mean "server" in one context, "publisher" in another, and
"peer" in yet a third, but it is always the focus of WSDL.  The WSDL is
written from its point of view; it follows that a strong guarantee may be
made that it *will* conform to its WSDL.  There is no such guarantee for
the node interacting with the service, whether it is as client,
subscriber, or peer.  That node is supposed to be able to determine what
its requirements are from reading and processing the WSDL; for that to be
true, the service should be as nearly as possible fully described with
respect to how it interacts with other nodes.

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

Received on Monday, 14 June 2004 13:05:40 UTC