As to your first point, it is available at
discovery currently for events which are sent, since these are of type
EventDescripiton. But not those that are received, which are only of type
QName (the name of an event, not the data type).
Scott
From: Rich
Thompson [mailto:richt2@us.ibm.com]
Sent: Monday, September 27, 2004
12:19 PM
To:
wsrp-coord@lists.oasis-open.org
Subject: Re: [wsrp-coord] Issue #6
Discussion - Wouldn't EventDescription[] be a better type for handledEvents?
As to the downsides you mention, EventDescription
already carries the type of the payload as does the Event structure so that it
is available both at discovery and runtime.
As
to the wildcard issues you mention, we would need some straightforward means to
indicate a willingness to process all event types under some level of a
hierarchy.
One
point that we do need to explore is whether moving to leveraging TopicSpaces
rather than defining our own types provides a clean solution to this issue.
Rich
"Goldstein, Scott"
<Scott.Goldstein@vignette.com>
09/27/2004 02:41 PM
|
To
|
<wsrp-interfaces@lists.oasis-open.org>
|
cc
|
|
Subject
|
[wsrp-interfaces] Issue #6 Discussion -
Wouldn't EventDescription[] be a better type for handledEvents?
|
|
In the current draft of the 2.0 specification, the portlet declares,
through the PortletDescription, which events it can receive. This
information is currently passed as an array of QName elements representing the
array of names of the events that it understands. The problem with this
choice of data type, is that it doesn’t handle the following use case
very well:
Suppose
that there are three portlets on separate producers that have the following
event characteristics:
1.
Portlet A – Sends an event
with name, “ns1:CurrentZipCode”, with the event data type,
xsd:string.
2.
Portlet B1 – Receives an event
with name, “ns2:MyZipCode”, with the event data type, xsd:string.
3.
Portlet B2 – Recieves an event
with name, “ns3:TheZip”, with event data type, ns3:ZipType
The
Consumer provides the admin a screen to map sent events to received events.
The admin maps the sent event from Portlet A to be received by both
portlet B1 and B2. He/She does this, because all that a portlet provides
when stating which events it receives is the name of the event. Because
the names look similar, he/she assumes it’s okay. When the event is
sent, however, an error occurs because there’s a data type mismatch
between what Portlet A sends and what Portlet B1 receives.
Another
aspect of this problem, is that two events may have the same datatype and
similar names, but may have different purposes. In this case, it would be
useful to have a description in the handleEvents structure to provide a better
idea of what the portlet is expecting.
The
proposal is to change the handledEvents field to an array of
EventDescription’s:
Advnatages:
1.
Facilitates event mapping on the
consumer side
Disadvantages:
1.
This would introduce an additonal
QName within the handleEvents element for the event payload datatype. If
it’s a standard xsd type, this won’t be a concern. However,
if it’s not a standard xsd type, it will require the producer to include
the schema for the data type.
2.
The added data type information
causes wildcards to be a bit awkward. Some possible solutions would be:
1.
Accepting it
2.
Making the Data Type field of
EventDescription optional
In my
opinion, I think the disadvantages are worth the enhanced consumer application
functionality.
Any
other opinions/comments?
Scott