wsdm message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsdm] Events metadata; Object now or comment after its in MUWS
- From: Steve Graham <sggraham@us.ibm.com>
- To: Heather Kreger <kreger@us.ibm.com>
- Date: Fri, 19 Nov 2004 07:59:52 -0500
>
<xs:element name=’messagePattern’ type=’xs:QName’
> minOccurs=’0’/>
>/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.
A couple of qustions/points. What
is the namespace associated with the mrp: prefix?
If the value of the messagePattern
component is a QName, then it is not likely to end up in the messagePattern
within a wst:Topic, because the messagePattern component is a QueryExpression,
not a QName. Does this suggest that WSDM needs to register an issue
with WSN to "modify" the way WS-Topics models messagePattern?
sgg
++++++++
Steve Graham
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
Member, IBM Academy of Technology
<Soli Deo Gloria/>
++++++++
Heather Kreger/Raleigh/IBM@IBMUS
11/18/2004 05:42 PM
|
To
| wsdm@lists.oasis-open.org
|
cc
| Steve Graham/Raleigh/IBM@IBMUS
|
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]