Since we are doing it with MessagePattern anyways I suggest that
expressiveness there is enough to convey this what is needed. e.g.
<wst:topic name="MyEvent"
messageType="muws-xs:ManagementEvent">
<wst:MessagePattern Dialect="...XPath 1.0...">
//ManagementEvent[namespace-uri="..." and
Situation/Category//ReportSituation and
Severity="3"]/Event[namespace-uri="..."]
</wst:topic>
I have no idea where the <event> elements will appear and how are
they attached to events... The above is very clear, on the other hand.
Once we step on the path, let's just go all the way :)...
-----Original Message----- From: Heather Kreger
[mailto:kreger@us.ibm.com] Sent: Thu 11/18/2004 5:42 PM
To: wsdm@lists.oasis-open.org Cc: Steve Graham
Subject: [wsdm] Events metadata; Object now or comment after its in
MUWS
I had an
outstanding action item to look into using topics and message patterns to
convey information that managers would need to know about expected events
ahead of time. Here are our conclusions:
While it is possible to advertise the values of
this information in messagePattern of a topic, the XPath would be very
complicated and Igor's complaints about the amount of processing and reverse
engineering to infer the category and severity would be valid. We are
really trying to advertise information ABOUT the event, not a broad shape or
signature of the message. Instead it seems much cleaner to advertise with the
resource, who is already advertising events to be issued, some of the
important values to be expected by the manager in the event. This enables
managers to find all events that will be emitted in a particular
situationCategry or severity. It also makes it very clear what
additional elements are being added into the WEF's open content. I think
this ties to the topics work today very neatly without makeing very complex
messagePatterns.
Therefore,
I'd like to propose the following metadata for events emitted from manageable
resources:
Events are
emitted from manageable resources in the form of WSDM Event Format
[WSDMEventFormat]. The event metadata element describes the types of
events that can be emitted and hints on how the WSDM Event Format will be
constructed.
The
form of the event element is extended as shown here.
<xs:element
name=’event’>
<xs:complexType>
<xs:sequence> <xs:element name=’situationCategory’
type=’ws-muws:category’
minOccurs=’0’/>
<xs:element name=’severity’ type=’xs:short’
minOccurs=’0’/> <xs:element name=’messagePattern’
type=’xs:QName’
minOccurs=’0’/>
<xs:any namespace=’##other’
minOccurs=’0’ maxOccurs=’unbounded’/> </xs:sequence>
</xs:complexType>
</xs:element>
<event>
<situationCategory> ws-muws:category</situationCategory>
?
<severity>xs:short<severity> ? <messagePattern>xs:QName</messagePattern>
? {any} *
</event>
/mrp:event/situationCategory The value that will appear in the situationCategory element of the
situation element of WSDM Event Format events of this type, with
potential values as defined in [WSDMBaseEvent].
/mrp:event/severity The value that will appear in the severity
element of the WSDM Event Format events of this type, with potential values as
defined in [WSDMBaseEvent].
/mrp:event/messagePattern The value that will be the QName of the schema element expected in the
open content model for the WSDM base event. This value will also appear in the
messagePattern for the Topic for the event.
This is an open content model, so additional, domain
specific, relevant information in the events could be advertised.
Given the timeframe,
I propose that if there are not
objections on Friday by COB EST, that this be added to MUWS. Of course, you
can still comment during the comment period.
Heather Kreger STSM, Web Services Lead Architect for SWG
Emerging Technologies Author of "Java and JMX: Building Manageable
Systems" kreger@us.ibm.com 919-543-3211 (t/l 441)
cell:919-496-9572
|