Manageability capability topics

["Murray, Bryan P." <bryan.murray@hp.com>]

On the call today we clarified that all MUWS properties and operations
are in one XML namespace (actually one for schema, one for WSDL, and one
for events). This means that all MUWS topics will be in a single
TopicSpace and thus one namespace. For the purposes of describing topics
we will list only the topics (not the TopicSpace) in each capability
description. In an appendix we will list the entire MUWS TopicSpace
including all topics from all manageability capabilities defined for
MUWS.

A proposal from today's call is to have a first-level topic for each
capability, with all other capability topics being sub-topics of this
first-level topic. Thus, the topics for the relationships manageability
capability might be:

<wstop:Topic name="RelationshipCapability">
  <wstop:Topic name="RelationshipCreated"
               messageTypes="muws-xs:RelationshipCreatedNotification"/>
  <wstop:Topic name="RelationshipDeleted"
               messageTypes="muws-xs:RelationshipDeletedNotification"/>
  <wstop:Topic name=RelationshipCapabilityPropertyValueChange"
 
messageTypes="wsrf-rp:ResourcePropertyValueChangeNotification"/>
</wstop:Topic>

The RelationshipCreated and RelationshipDeleted topics are defined in
the MUWS spec. RelationshipCapabilityPropertyValueChange topic has the
semantics such that if any property defined in the Relationship
manageability capability is modified or updated, this topic would fire
sending a notification with the format of all property value change
notifications as defined in WSRF-RP.

The semantics for the RelationshipCapability topic are up in the air.
One of the reasons is because no one has experience with the best way to
define and use topics.
1. One proposal is to make this topic a catch-all for all notifications
which do not fit under any other topic. This means that a subscriber to
only this topic would not receive the relationship created and deleted
notifications and would not receive the relationship property change
events. Other events that might be generated for the relationships
capability that are not covered by other topics would be received by the
subscriber.
2. Another proposal is to make the RelationshipCapability topic be the
sum total of all of its sub-topics and all other notifications that
might be generated for the relationship manageability capability. This
semantic would allow a management application to subscribe to the
RelationshipCapability topic and receive all notifications associated
with relationships.


It was pointed out that the AliasRef mechanism provided by
WS-BaseNotification can only be used to bring someone else's topics into
your TopicSpace, not for you to bring your topics into someone else's
TopicSpace. This means that MUWS cannot define a FirehoseTopic which we
expect all others to alias their topics to - it won't work.


Something that needs to be understood is how the topics from different
capabilities compose with each other. For instance, consider the
following

MyResourceManageabilityCapabilities =
	MuwsIdentity + MuwsMetrics + DiskDriveMetrics

These capabilities are exposed in a single WSDL portType with a single
WSRF-RP document cut-and-pasted from the three capability interfaces.
Each of the capabilities will define their own topics with sub-topics as
described above. So when a property in the DiskDriveMetrics capability
is updated, which topics are available to receive this notification on?
It seems obvious that the following topics would be available:
	<property name> - from WSRF-RP
	DiskDriveMetricsCapabilityPropertyValueChange
	DiskDriveCapability - maybe, depending how above issues are
resolved

I would be surprised if a DiskDriveMetrics property would have anything
to do with a topic defined in a different interface such as the
following:
	MuwsMetricsCapabilityPropertyValueChange
	MuwsMetricsCapability

I think that if a manager wants to subscribe for a capability it needs
to query the capabilities property and decide which of the supported
capabilities it wants to receive notifications for and subscribe to each
one individually. The DiskDriveMetrics capability is a different
capability from the MuwsMetrics capability.

Bryan