wsn message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsn] Roles vs. Port Names
- From: Steve Graham <sggraham@us.ibm.com>
- To: David Hull <dmh@tibco.com>
- Date: Mon, 9 Aug 2004 17:02:47 -0400
David:
Interesting discussion, thanks. Too
much inlining and >>>>> so I will pull out areas that I
want to further comment on.
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.
<sgg>the Producer EPR
is guaranteed to have NP operations, and maybe others. Something
like WS-MetaDataExchange may be useful to retrieve the WSDL of the service
and the consumer can go from there to do further message exchanges to "follow
up" on the notification.</sgg>
<sgg>re: notification
streams, I look forward to reviewing what you write up in this space. I
am intrigued by the snippet of your thinking that you discussed at the
F2F.</sgg>
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?
<sgg>Subscription manager
refers to the name of a portType, so it is the "Web service"
part of the WS-Resource. This is relevant in certain cases where it is
important to know what messages I can send to the Web service referenced
by the EPR. That being said, I am not against calling this portType
a subscription, making the name of the portType and the name commonly used
to refer to the entire WS-Resource has some pros and cons, but I am not
against the namechange. </sgg>
++++++++
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>
08/09/2004 04:19 PM
|
To
|
|
cc
| wsn@lists.oasis-open.org
|
Subject
| Re: [wsn] Roles vs. Port
Names |
|
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]