Re: [wsn] Roles vs. Port Names

[Steve Graham <sggraham@us.ibm.com>]

intersting.

++++++++
Steve Graham
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
Member, IBM Academy of Technology
<Soli Deo Gloria/>
++++++++


David Hull <dmh@tibco.com> wrote on 08/09/2004
02:56:59 PM:

>  
> > I've been thinking for a while about what
might be better, but given that different
> > people process information differently, there is no objectively
clear choice.   
> Indeed. No objectively clear choice on a different naming convention,
so lets stick 
> with the convention we have, warts and all. 
> I don't think that follows at all.  The
current NotificationProducer does not 
> produce notifications 
Well, some component associated with the NP does produce
the notifications, essentially
this is what the ProducerReference component of the
Notify message is supposed to refer to.

>and the current SubscriptionManager does not manage
> subscriptions, at least not in the common sense of managing a collection
of 
> subscriptions.  
Indeed, well, The SM does manage a collection of Subscription
WS-Resources, at least
it manages their access.  However, I would not
be totally against renaming
SubscriptionManager to Subscription.

> There may be no objective best name, but that
doesn't mean that the
> current names can't be improved.
> 
> The current names have been a stumbling block for several people,
myself included, 
> trying to understand the architecture.  This may not seem to
be such an issue since
> everyone here is presumably now familiar with the architecture, but
I believe they 
> are continuing to be a stumbling block in discussing the architecture.
 In any 
> case, it is liable to be an issue again when the documents are published
to a wideraudience.
Maybe, I would appreciate others indicating whether
the naming convention is confusing to them.

> 
> FWIW, I've manage to re-align my mental image of "producer"
more along the lines of
> a movie or music producer, in the sense of "party who makes things
happen but 
> doesn't necessarily have a direct hand in proceedings," but that's
clearly a 
> crutch.  No such luck on "SubscriptionManager" (maybe
it should get 10% of every 
> Notification? :-)
Not a crutch at all.  A Web service interface
may be the facade to a large network of
collaborating implementation objects.

> 
> In any case, "SubscriptionFactory" and "Subscription"
are not just a little clearer
> to me, they're night-and-day clearer.  Part of this is surely
subjective, but there
> is also a well established convention of calling "thing you use
to create X" an 
> XFactory, and calling the entity you use to access notification streams
a "Subscription."
And if Subscription creation was ALL that NP did,
then I would buy your rename argument.
Unfortunately NP does more than just create subscriptions.

> 
> Indeed, operation names such as "ResumeSubscription" and
text such as "if the 
> Subscription is not in the paused state" suggest that the standards
authors see the
> object as a subscription.  
More precisely, the Ws-REsource created as a result
of processing a subscribe request
is a WS-Resource.  Object is too loaded a term
in certain circles.

>If I understand correctly, the whole point of
using the 
> IRP is that you're addressing messages to the managed resource directly,
and not to
> some intermediate object.  
Well, sort of.  IRP does clarify the relationship
between a Web service and a stateful resource.
However, we don't preclude the message being manipulated
by intermediaries.

>One does not send "GetResouceProperty"
to a 
> "NotificationProducerManager" to find out about a NotificationProducer.
 Why is 
> SubscriptionManager different?
Because an NP doesn't necessarily manage Notification
Producers, whereas an SM does
manage Subscription WS-Resources. FWIW, the NP was
one of the original cases that suggested
the (now infamous) singleton resource pattern.

sgg