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

[Richard Jacob <richard.jacob@de.ibm.com>]

Hi,
See inline <rj></rj>

@ aliasing questions:
a) What's the problem aliases are trying to solve?
 What are the use cases
for aliases?  
<rj>Aliases are merely a hint
to event wiring which can help administrators or automated systems to bring
two different events together.
This works pretty nicely if the eventType
is the same for both events.
Thinks get complecated if the types
don't match, then we would need payload transformation.
Famous example:
EventA:
eventName: Address.Set
eventType:com.ibm.address

EventB:
eventName MyAddress.stored
eventType: com.netunity.address

Semantically both events may be equal,
which would qualify them for wiring.
Hower the eventType might be syntactically
different, e.g. different field types, named differently, etc.
This is where you enter the world of
payload transformation with all the issues we see across the world.
My favourite here: PIM synchronisation
with different products.... Don't know how many years this didn't work
reliably for me.
So to be honest: I don's believe that
we will see systems doing automatic payload transformation very well in
the near future.</rj> 

b) Are aliases a hint as to what other events a given event can be
transformed into?  
<rj>yes, see above. Note that
aliases merely are located at the semantic level.</rj>

c) Is it strictly a consumer transformation? A predetermined
transformation
(e.g. change the name of event, change the root payload element name, etc.)?
<rj>
see above. Per spec(s) this is a consumer/portal
driven transformation.
As said easy with events carrying the
same payload or at least easy convertible payload (this is were Kevin targets
at with the simple types).
</rj>

d) Is it optional or required to send the event if there is a match on
aliases?
<rj>event distribution is always
optional. I guess most Consumers howevere would try to do an alias matching
to expand the interoperabiliy.
...and keep their fingers crossed when
it comes to different payload :)</rj>

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.
<rj>I'd say both. I would expect
consumers to build a transitive cloud here and have "meta event or
classes" kept here.
I.e. be greedy when it comes to wiring.</rj>

f) Can an event map to more than one target event via aliases?
<rj>not sure exactly what you
mean here (maybe an example would help).
... but in anticipation of what you
mean, I would say yes :)</rj>

g) What effect do aliases have on opaque payloads and wildcard subscribed
events if any?
<rj>as said above, aliases are
at the semantic level, not at the syntax payload level.
There I'd say none.</rj>

Mit freundlichen Grüßen / Kind regards
Richard Jacob
Team Lead Portal Standards & WCM development WSRP Standardization Lead
IBM Software Group, WPLC
WSS Websphere Portal Foundation Development 1
Phone:	+49-7031-16-3469	IBM Deutschland Research & Development
E-Mail:	richard.jacob@de.ibm.com	Schoenaicher Str. 220
		71032 Boeblingen
		Germany
IBM Deutschland Research & Development GmbH / Vorsitzender des Aufsichtsrats: Martin Jetter Geschäftsführung: Erich Baier Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294

 

From:	"Nader Oteifa" <nader2@netunitysoftware.com>
To:	<wsrp-interop@lists.oasis-open.org>
Date:	10/26/2009 08:24 PM
Subject:	RE: [wsrp-interop] Original Emails on event QNames

---

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