Alan's clarification of use cases contains the following statement:
"Note that in my view, the Subscription Manager and Subscriber
are actually the same entity."
I'm not entirely sure what this means, but from the use cases itself I
believe the point is that whatever is sending subscribe requests,
control and query messages is effectively managing the subscription and
should be regarded as the subscription manager.
This does not accord with the port types as we define them. What the
port types currently say is
- Something can send a SubscribeRequest to a NotificationProducer.
The request contains an endpoint which MAY implement
NotificationConsumer. This produces (a fault or) a SubscribeResponse
containing an endpoint that MUST implement SubscriptionManager.
- The consumer endpoint gets notifications, whether raw or cooked.
- Anything at all (subject to any security measures in place) can
control the and query the properties of a particular subscription via
this SubscriptionManager interface.
And that's it. There is no Subscriber port type. We call the client
end of the SubscribeRequest/SubscribeResponse exchange the Subscriber,
but that's a non-normative convention. We don't dictate that
Pause/Resume/GetCurrentMessage/Destroy come from any particular place.
We don't dictate that any particular entity send notifications (or even
that all notifications to a given consumer come from the same place).
As I've said, I believe the current port names NotificationProducer and
SubscriptionManager are quite confusing (by contrast, I think
NotificationConsumer is fine, and much better than "Subscriber" would
be). I don't believe this is just an incidental item, either, as we
use these terms daily in discussing the architecture.
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. Personally I would prefer
- SubscriptionFactory for the current
"NotificationProducer". I realize that the name SubscriptionFactory
does not comport well with the GetCurrentMessage operation. This
requires further discussion, but to a first approximation the solution
is to remove GetCurrentMessage from SubscriptionFactory.
- Subscription for the current "SubscriptionManager". As
I've said, this implies that the endpoint is associated with a single
subscription entity, which it is.
This allows us to say things like "The [your role here] sends a
SubscriptionRequest to a SubscriptionFactory and gets a Subscription.
It may then Pause, Resume, Destroy or otherwise manipulate the
Subscription." as opposed to "The Subscriber sends a
SubscriptionRequest to a
NotificationProducer and gets a SubscriptionManager. It may then
Pause,
Resume, Destroy or otherwise manipulate the subscription via the
SubscriptionManager."
In Alan's case, the [your role here] is Subscriber/SubscriptionManger,
as in "the SubscriptionManager sends a Pause message for the
Subscription."
Would this help?
|