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: "Sedukhin, Igor S" <Igor.Sedukhin@ca.com>
- To: "Steve Graham" <sggraham@us.ibm.com>
- Date: Fri, 19 Nov 2004 14:44:59 -0500
<ElementWithSomeInformation> does not define a
maningful event, it is just some information about something. It has to be
qualified as to what occasion it is emmited on in order to become a meaningful
event. So 1) define different elements for every occasion or 2) define topics
for every occasion
For example, say, I have an element
<RequestMessageInformation>
Now, I emit events on a) request completed b) request
failed
so I can declare
approach 1) two elements <RequestCompleted> and <RequestFailed> which
contain <RequestMessageInformation> to identify particular
events
In answer to [No requirement to define
N variants of the "ElementWithSomeInformation". What am I
missing?], if I did not declare these two elements in this approach, then
there is no such thing as <RequestMessageInformation> event. It has to be
associated with a particular occasion to be a meaningful
event.
or
approach 2) two topics named RequestCompleted and
RequestFailed which both emit <RequestMessageInformation> which
also encodes the reasion sich as completed or failed, but in a way specific
to the request message.
The latter is now used in MOWS and did not rase any
concerns so far. Having miriads of elements declared for every occasion seems
unreasonable.
-- Igor
Sedukhin
..
(igor.sedukhin@ca.com)
-- (631)
342-4325
..
1 CA Plaza, Islandia, NY 11749
hmmm....
The mapping of event types to topics is
potentially many to many. If you have different 'situations' that are
detected, then model them with different element artifacts (ie different
events) and then post each to one or more topics. However, you should
allow for the case where a given event can be posted to n different topics, no
difference at all in the event (type or instance), but simply different channels
for different audiences.
>Would I then have to
declare <ElementWithSomeInformationForTheOccasionA> and
<ElementWithSomeInformationForTheOccasionB> event though the >contents
is the same? This is what 1) would make me do.
I don't see why this is so. The way I understood William's proposal
is that an event is defined by its content "GED". An event of that type
could appear on Topic T1, T2... TN. No requirement to define N variants of
the "ElementWithSomeInformation". What am I missing?
sgg
++++++++
Steve Graham
(919)254-0615 (T/L 444)
STSM, On
Demand Architecture
Member, IBM Academy of Technology
<Soli Deo
Gloria/>
++++++++
"Sedukhin, Igor S"
<Igor.Sedukhin@ca.com>
11/19/2004 01:19 PM
|
To
| Steve
Graham/Raleigh/IBM@IBMUS, "Vambenepe, William N"
<vbp@hp.com>
|
cc
| Heather
Kreger/Raleigh/IBM@IBMUS, <wsdm@lists.oasis-open.org>
|
Subject
| RE: [wsdm] Events
metadata; Object now or comment after its in
MUWS |
|
Why is it not the best approach?
If I have
<ElementWithSomeInformation> and I emit
<ManagementEvent>...<ElementWithSomeInformation>... on different
occasions then are you saying there is only one event identified by the
<ElementWithSomeInformation>? I would think that I'd declare topics which
will indicate which occasions the conglomerate of <ManagementEvent> and
<ElementWithSomeInformation> is emitted. And those topics would actually
identify events (occasions when the conglomerate is emitted).
Would I then have to
declare <ElementWithSomeInformationForTheOccasionA> and
<ElementWithSomeInformationForTheOccasionB> event though the contents is
the same? This is what 1) would make me do.
-- Igor Sedukhin ..
(igor.sedukhin@ca.com)
--
(631) 342-4325 ..
1 CA Plaza, Islandia, NY
11749
From: Steve Graham [mailto:sggraham@us.ibm.com]
Sent: Friday, November 19, 2004 1:08 PM
To: Vambenepe,
William N
Cc: Heather Kreger;
wsdm@lists.oasis-open.org
Subject: RE: [wsdm] Events metadata; Object
now or comment after its in MUWS
3 topics, 3 different events does not sound like the
best approach to me. Therefore I would prefer (1)
++++++++
Steve
Graham
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
Member, IBM
Academy of Technology
<Soli Deo Gloria/>
++++++++
"Vambenepe, William N"
<vbp@hp.com> wrote on 11/19/2004 12:15:24 PM:
> They don't have
to be. As long as we pick on definition and are clear about it.
>
> 1) One definition is to say that an event is
defined by a "content" GED period. The
> fact that that event can be
associated with multiple topics doesn't change the fact
> that it's the
same event.
>
> 2) Another
definition is to say that an event is defined by the association of a
>
topic and a "content" GED. That's the one I proposed below. In this definition,
if
> the same content GED is associated with 3 different topics that
makes 3 different events.
>
> Either is fine by me, but we need to clearly state what an
event is.
>
> In the spec
right now I have version (2) but I can easily switch to (1) if this is
>
what the group prefers.
>
> We need to decide on that first (what is an "event") before
we decide on what
> metadata an event has.
>
> William
>
> From: Steve Graham [mailto:sggraham@us.ibm.com]
> Sent: Friday, November 19, 2004 5:02 AM
> To: Vambenepe, William
N
> Cc: Heather Kreger; wsdm@lists.oasis-open.org
> Subject: RE:
[wsdm] Events metadata; Object now or comment after its in MUWS
>
> are events strictly
associated with at most one topic?
>
> should the @topic be
a list?
> <event topic="list of any URI"
>
++++++++
> Steve Graham
> (919)254-0615 (T/L 444)
> STSM, On
Demand Architecture
> Member, IBM Academy of Technology
> <Soli
Deo Gloria/>
> ++++++++
>
>
>
> "Vambenepe, William N"
<vbp@hp.com>
> 11/18/2004 06:44 PM
>
>
To
>
> Heather
Kreger/Raleigh/IBM@IBMUS, <wsdm@lists.oasis-open.org>
>
>
cc
>
> Steve
Graham/Raleigh/IBM@IBMUS
>
> Subject
>
> RE: [wsdm] Events metadata; Object now
or comment after its in MUWS
>
>
>
>
> Heather,
>
> I am trying to picture a metadata document with a bunch of these
<event> elements
> in it. How do I tell what event each of these
elements relate to? Which begs the
> larger question: what is an event.
>
> In our spec, whenever we define an event we do so by
selecting a topic and a GED to
> represent the content of this event. So
it seems to me that our definition of an
> event is something uniquely
identified by a URI (topic), a GED (content) and a
> description of the
semantics in human-readable (at least geek-readable) form.
>
> Based on this, I think the event metadata element you propose would
look better like this:
>
> <event topic="any URI"
content="xs:QName">
> <situationCategory>
ws-muws:category</situationCategory> ?
>
<severity>xs:short<severity> ?
> {any} *
> </event>
> With @topic and @content being required
so I know what event this metadata is about.
>
> Also, if
we go with this proposal can you show us what the topic document would
>
look like? Like would be in topic/@messageType?
>
> William
>
>
> From: Heather Kreger
[mailto:kreger@us.ibm.com]
> Sent: Thursday, November 18, 2004 2: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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]