Re: [wsrp-interop] Original Emails on event QNames

[Kevin Frender <kevin.frender@oracle.com>]

Hello Nader,

To answer your questions (at least from my point of view):

a) What's the problem aliases are trying to solve? What are the use cases for aliases?

The use-case as I see it is to allow portlets which were not developed by the same team / company to interoperate without having to change the portlet code.  For example, company A could put out a generic map portlet, which would accept an event with QName "{com:a:event}setMapZipcode" for setting the map's location.  Company B might have put out a portlet for finding a restaurant which generates an event "{com:b:restaurant}zipCode".  Now if company C wants to use these two portlets together in their portal, as long as the portlets from company A and company B use simple, well-defined event payloads (like simple strings) company C could just add event aliases to the portlet deployment descriptors and the two portlets would interoperate without having to alter their code.  (The simple, well-defined event payload case is the use-case I brought up this discussion for in the first place, but it is a separate issue).

b) Are aliases a hint as to what other events a given event can be transformed into?

Yes, basicaly.

c) Is it strictly a consumer transformation? A predetermined transformation (e.g. change the name of event, change the root payload element name, etc.)?

Yes, in my opinion this is strictly a consumer transformation.  In my opinion it should be a transformation in name only-- not affecting the payload at all.  I am also of the opinion that the payload root element name should NOT be required to be the name of the event.

d) Is it optional or required to send the event if there is a match on aliases?

So consumers are not required to support WSRP 2.0 events at all; in my opinion if they do support events they SHOULD support aliases, but this is not a MUST.

e) Who's aliases are used? The generating portlet, the handling portlet, both? Note the spec. indicates both generated and handled events need to be described which brings up other inconsistency problems.

The way I interpreted it, aliases apply only to the handling portlet-- so if the generating portlet declares aliases on its generated events, those are ignored (for its generated events, anyhow), but the aliases declared on the event-handling portlet's event descriptions are honored.  This lack of symmetry allows for more flexible configuration (in my opinion) because you can allow each portlet to describe what it wants to receive, including all aliases.  If event alias definitions from portlets other than the event-handling portlet were honored, it would be possible to break an existing portal set-up just by adding a new portlet that happened to carry some new alias definitions.

f) Can an event map to more than one target event via aliases?

In my opinion (and implementation), yes.

g) What effect do aliases have on opaque payloads and wildcard subscribed events if any?

In my opinion, aliases should never have any affect on payloads, whether the payload is opaque or not.  They do have an interesting side-effect with wildcards though, but it is an edge case-- and one I would not expect most consumers to support.

Consider this: when a WSRP 2.0 producer describes events, the event alias lists are stored with the event description rather than the portlet's declared subscription to an event. However, the portlet's declared subscription is where wildcards are allowed. This leads to an interesting edge case involving the combination of aliases and wildcards. For example, consider the following setup (using only local names for events-- the namespace part of the QName is irrelevant in this edge-case):

• Event declaration for event "com.sample.eventOne" has an alias for "com.acme.foo"
• Event declaration for event "com.sample.eventTwo" has an alias for "com.acme.bar"
• Portlet A declares a subscription to the (wildcarded) event name "com.sample."

This setup means that when a "com.acme.foo" event is sent, portlet A should receive this event with the name "com.sample.eventOne", and when a "com.acme.bar" event is sent, portlet A should receive the event with name "com.sample.eventTwo".

Again, this is an edge case that I would not expect to be widely supported, and this isn't something I wanted to bring up as an interop issue, but since you asked...

   Kevin




Nader Oteifa wrote:

005f01ca5671$fdf2a030$f9d7e090$@com" type="cite">

Kevin brought up a very interesting point regarding event aliases during our
WSRP meeting.  Take the following use case:

a) Portlet A published Event A aliased to B
b) And Portlet B generates and subscribes to Event B
 
During the meeting, the following thoughts were offered:

a) Event A should be sent to portlet B as Event A NOT modified
b) Event A is renamed to event B but the payload is NOT modified (most
votes)
c) Event A is renamed to event B and the root element is renamed to event B
d) What does the schema for an event look like with aliases? Is the element
under the payload defined in the schema or just its type?

If you read the spec now regarding aliases:

aliases: An array of the QNames of events known to be semantically
equivalent to this event. While this can provide a hint to the Consumer
concerning potential items that could be correlated with this event, it
remains the Consumer's responsibility do any transformations required to
produce the described event.

To me, this sounds like if portlet A generates Event A, the consumer will
transform the Event A and its payload to Event B and send it to portlet B.
Therefore, portlet B only see Event B and the payload it expects.  This tell
me that aliases are just a "hint" as to what the payload could be
transformed to but the consumer is responsible for the mapping and it's
purely optional; portlet B might never get an event if the consumer does not
care to map these two events even if aliased.  This is just another
interpretation of how aliases affect events based on reading the description
of aliases in the specification. 

Given the varied interpretation on implementations, it appears there is
quite a bit of confusion on how aliases work.  Therefore, I think we need to
agree on the answers to some basic questions first:

a) What's the problem aliases are trying to solve?  What are the use cases
for aliases?  
b) Are aliases a hint as to what other events a given event can be
transformed into?  
c) Is it strictly a consumer transformation? A predetermined transformation
(e.g. change the name of event, change the root payload element name, etc.)?

d) Is it optional or required to send the event if there is a match on
aliases?
e) Who's aliases are used?  The generating portlet, the handling portlet,
both?  Note the spec. indicates both generated and handled events need to be
described which brings up other inconsistency problems.
f) Can an event map to more than one target event via aliases?
g) What effect do aliases have on opaque payloads and wildcard subscribed
events if any?

Can we discuss these questions in one of our next scheduled meetings?

Nader

-----Original Message-----
From: Nathan Lipke [mailto:nathan.lipke@oracle.com] 
Sent: Thursday, October 22, 2009 11:38 AM
To: wsrp-interop@lists.oasis-open.org
Subject: [wsrp-interop] Original Emails on event QNames

http://www.oasis-open.org/apps/org/workgroup/wsrp/wsrp-interop/email/archive
s/200710/msg00002.html

Use the "Thread Next" link to see the follow-ups.

Nate

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 




---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php