wsrp-coord message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp-coord] Issue #6 Discussion - Wouldn't EventDescription[] be abetter type for handledEvents?
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp-coord@lists.oasis-open.org
- Date: Mon, 27 Sep 2004 15:19:19 -0400
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]