Thanks for the response. More commentary inline
Steve Graham wrote:
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.
This seems a bit unclear. To me one important question is "what can
you do with it". In other words, it's all well and good to provide
something called a "producer reference", but do we guarantee that that
endpoint implements any particular port type?
Some of this has to do with the question of how notification streams
are associated with topics, which I mean to get into Real Soon Now.
>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.
I thought the idea was that the EPR in question referred to exactly one
subscription. I realize that different SM EPRs might share the same
physical address, meaning that the physical server at that address is
managing multiple subscriptions -- indeed, that's expected to be a
common scenario. In that case, you might call the server a
"subscription manager", but this doesn't seem relevant. The EPR as a
whole refers to the subscription, not the server.
Am I missing something?
However, I would not
be totally against renaming SubscriptionManager
to Subscription.
Thanks.
> 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.
So would I. If it's just me, I'll learn to live with it.
>
> 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.
Right . . . so the point is not what's behind it, but what does it look
like externally, and we know that only through port types and
operations. I think again the key is the GetCurrentMessage operation.
GCM gives NP its "NotificationProducer" flavor. But GCM is effectively
an optional operation, inessential to the core business of
subscribing, while Subscribe is an essential operation.
>
> 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.
See above.
>
> 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.
Fair enough. The point is that it's a resource, not a resource manager.
>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.
Again, the question is whether the intermediation is visible. In this
case, at least, that boils down to whether I send an explicit ID in the
control message -- I'm asking one entity to control another -- or
whether I send a control message directly to a dedicated endpoint --
I'm asking the entity to control itself.
>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.
My intuition is still that there is less going on there than meets the
eye.
sgg
|