OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsdm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [wsdm] Clarifying the relationship between WEF(WSDM Event Format) and wsrp:ResourcePropertyValueChangeNotification


Hi, WSDM folks

I confused how to treat the implementation of event in the WSDM
specification using WS-Notification and WS-RF.

So, I'd like to clarify the event format and message(XML) for the
MUWS:OperationalStatus capability
and MUWS:Metric capability.

As description of cd-wsdm-muws-part2-1.0.pdf line #808-809,

808 No specific event is defined, since the notification on property value
change provided by WS
809 ResourceProperties is sufficient, when applied to the
muws-p2-xs:OperationalStatus property.

in this case, what TYPE of event SHOULD the management consumer received?

I think that there are 2 cases.
 Case 1 - Consumer should received the raw
wsrp:ResourcePropertyValueChangeNotification event message.
or
 Case 2 - Consumer should received the muws-p1-xs:ManagementEvent message
which include the
              wsrp:ResourcePropertyValueChangeNotification.

In case 1, the definition of WS-Topic will be as follows,
<wstop:Topic name="muws-p2-xs:OperationalStatus"
  messageTypes="wsrp:ResourcePropertyValueChangeNotification">
</wstop:Topic>

Otherwise, in case 2 the definition of WS-Topic will be as follows,
<wstop:Topic name="muws-p2-xs:OperationalStatus" 
  messageTypes="wsrp:ResourcePropertyValueChangeNotification
muws-p1-xs:ManagementEvent">
</wstop:Topic>

The reason why messageTypes attribute include the
wsrp:ResourcePropertyValueChangeNotification is
according to the description of wsrf-WS-ResourceProperties-1.2-draft-04.pdf
line #1056-1058.

1056 o The value of the Topic element's messageTypes attribute MUST include
1057    wsrp:ResourcePropertyValueChangeNotification (defined later in this
section). In
1058    addition, it MAY include QNames of other message elements.

And the reason why messageTypes attribute must include the
muws-p1-xs:ManagementEvent is
according to the description of wsn-WS-Topics-1.2-draft-01.pdf line
#270-274.

270 /wstop:Topic/@messageTypes
271   An optional list of the QNames of XML elements that define the types
of NotificationMessage
272   that may be used with the Topic. A Publisher using a given Topic MUST
NOT generate a
273   NotificationMessage whose type is not included in this list, although
the special value xsd:any
274   indicates that any NotificationMessage type MAY be used.

(In the description of new version of WS-Topic spec.
wsn-WS-Topics-1.3-draft-01a.doc line #270-275 is much clear.
270 /wstop:Topic/@messageTypes
271   An optional list of the QNames of XML global element declarations
(GEDs) that define the
272   kinds of NotificationMessage that may be used with the Topic. A
Publisher using a given
273   Topic MUST NOT generate a NotificationMessage with root element whose
QName is not
274   included in this list, although the special value xsd:any indicates
that a NotificationMessage
275   may have any XML element as root.
)

MUWS:Metric capability has the same problem according to the description of
cd-wsdm-muws-part2-1.0.pdf line #958-960

958 WS-ResourceProperties specifies the ability to define optional topics
for a resource property that
959 can emit notifications when a value changes. These topics allow a
consumer to request
960 notifications on an update of a metric property.

Because MOWS:Metric inherits the MUWS:Metric capability (Figure 9. of
cd-wsdm-mows-1.0.pdf), 
MOWS:capability is related to this my question. I think.

Our Hitachi's developers in Japan have a concern about how to get the
notification event(message) when
metrics of Manageable Web Services (e.g. NumberOfRequests) has changed.

I think the event message including its format(type) is the one of the
important point to success the
interoperability test held in April. 

So I would like to clarify this item in this mailing list or next conference
call.
----
Mitsunori SATOMI (mailto:Mitsunori.Satomi@hds.com)
  Director, Advanced Software Architect
    Hitachi Data Systems Corporation 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]