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

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:

 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" <>

To:
<>

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:]

Sent: Thursday, October 22, 2009 11:38 AM

To: 

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