This issue was discussed during this
morning’s conference call. The points discussed were:
- It
was agreed that the use case presented is valid and should be supported
- It
was agreed that the use case presented is only applicable in cases in
which the portlet sending an event and the portlet receiving an event come
from two different environments. In other words, no mapping would be
necessary in the situation that both portlets were aware of each other and
they understood the same events by name. Therefore, having the
portlets provide data type and description information for every event
that they both send and receive would be superfluous.
Based on
these points, Mike proposed separating the declaration of what events that a
portlet can receive/send and the description of a particular understood event. This
might be achieved through the following:
[O]
QName
publishedEvents[]
[O]
QName handledEvents[]
[O] EventDescription knownEvents[]
In
addition to addressing the points discussed in the call, this proposal also
alleviates the disadvantanges previously mentioned for this issue.
If you
have any comments on moving in this direction, please post them to the
discussion list or bring them up during the next coordination/interfaces call.
Scott
From: Rich
Thompson [mailto:richt2@us.ibm.com]
Sent: Monday, September 27, 2004
12:42 PM
To:
wsrp-coord@lists.oasis-open.org
Subject: RE: [wsrp-coord] Issue #6
Discussion - Wouldn't EventDescription[] be a better type for handledEvents?
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