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:41:54 -0400
Agreed ... your proposal tightens up
the discovery metadata specifying the payload type.
Rich
"Goldstein, Scott"
<Scott.Goldstein@vignette.com>
09/27/2004 03:31 PM
|
To
| Rich Thompson/Watson/IBM@IBMUS,
<wsrp-coord@lists.oasis-open.org>
|
cc
|
|
Subject
| RE: [wsrp-coord] Issue #6
Discussion - Wouldn't EventDescription[] be a better type for handledEvents? |
|
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]