Re: [wsrp-interop] WSRP event payloads with "simple" types

Hello Richard,

Answers inline...

Richard Jacob wrote:
Hi Kevin,
  

  

  I agree with your observation here.
  

  As far as I understood your problem
description this interop issue arises when portlets start to throw
events
for which they didn't declare any type definition neither in the WSRP
description
nor in the JSR deployment descriptor (which both specs allow).
  

Yes.

Let it try to describe it
in my words
to see if we have a common understanding:
  

  For the JSR case not specifying the
type possible because the container would just pass around the
serializable
object and portlets knowing the type could cast explizitly and they are
done, right?

Yes, or the receiving portlet can examine the event payload object to
determine its type.  For example, a portlet expecting a number as a
payload could accept an Integer object, a String representation of the
number, a Long, etc.  This flexibility becomes much more useful when
the portlet is designed to be reusable with other portlets, and applies
especially in the case where event aliasing may be used to wire portlet
events together.

Now as soon as we go over
the wire we
can serialize the object because it is either a JAXB-annotated complext
type or an implicitly supported simple type.
  

  So serialization just works.

Yes, BUT- there is no "standard" way to turn the implicitly-supported
simple types into XML, which is what I would like to see if there is
interest in defining for interoperability.

Now, when the event is
distributed as
the WSRP payload (with no type annotation), then the producer/consumer
which want to deserialize that payload can not reliably do so, because
the root element qname does not provide any hint of the type. And since
the type in this case is not specified in the deployment descriptor
this
should fail....
  

Right- since the type was not declared in the event descriptor in the
serviceDescription, by WSRP spec the consumer must treat the payload as
opaque.  I would like to change that slightly, to allow for some
standard, universally-recognized simple types, such that when the event
is received and has one of these special standard simple type event
payload types, we all know what it is and how to deserialize it.  In my
opinion, the payload's root element name should not be used for any
sort of type determination (since there can be complications with
aliases); only the event payload type field should be used in the
payload type determination.

I guess this is not only
a problem for
simple types (which could be solved e.g. in a manner you proposed) but
also for complex types.
  

  How would you point JAXB to the
right
annotated class allowing to create the complex bean object?
  

Yes, this is not just a problem for the simple types, but I think it
can be handled for the complex types by configuring the JAXB context
with a classpath pointing to all JAXB-bound event payload objects. 
JAXB then determines which type the XML is and what it should be
unmarshalled as using the schema information.

I think this problem goes
away if portlets
in the JSR case always declare the type definition in the portlet.xml.
  

  Maybe this is also worth mentioning
as a best interop practice, even in the local case.
  

Yes and no...  If I wanted to create a "flexible" portlet that
displayed a map based on location (such as a US postal code / ZIP code)
that is sent in via an event, it is easy to have the portlet code
figure out whether the event payload is a Integer, Long, Short or
String representation of the zip code so that it could accept any of
those types.  But if it is forced to declare a single type (and only a
single type is allowed in the event declaration by both JSR286 and WSRP
2.0) then this cannot be done.

In addition, if we had two portlets (each on a different company's
producer) which wanted to interoperate based on an event containing a
simple String payload, they each declare the event payload type as
java.lang.String in the JSR286 portlet.xml, but unless there is some
standard WSRP 2.0 mechanism for describing the type java.lang.String
(such as "xsd:string"), there might still be interoperability issues
because each producer might marshal the String in its own way that the
other producer doesn't recognize.  This is a problem because you can't
just give JAXB a String and have it marshal it, the String needs to
live inside another JAXB-annotated Java object.

Another option besides
definiting root
element Qnames indicating the type could be to have the event flow with
a type qname, which the spec alread has.
  

  So if you would have a simple string
being serialized, the event would flow as (simplified):
  

  

  <event name="someNS:localPart"
type="xsd:string">
  

  <eventPayload>
  

   
<someRootElementName>StringValue</someRootElementName>
  

  </eventPayload>

</event>
  

  

  This way the wsrp-to-jsr bridge
could
pass the correct type class to the JAXB deserializer and retrieve the
correct
object (provided it has a type to class mapping at hand).
  

Exactly- this is exactly what I am proposing-- a standard set of
"simple" event payload types, like "xsd:string" and "xsd:int" where we
then know that the payload is serialized as some root element which
contains the simple type.  The name of the root element should not
matter, but we could declare a standard set of payload root element
names for the simple types if we wanted, which would make it a bit
easier to configure JAXB for marshalling / unmarshalling these simple
types.

   Kevin 

  
    
      

        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
        
        
        

        
        

        
        

        
      

      

        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:
        
        Kevin Frender
<>
        
      

      

        To:
        
        Nader Oteifa
<>
        
      

      

        Cc:
        
        
        
      

      

        Date:
        
        10/15/2009 05:45 PM
        
      

      

        Subject:
        
        Re: [wsrp-interop] WSRP
event payloads
with "simple" types
      

    
  
  

  

  

  

  

  Hello Nader,

  

I may be misunderstanding your suggestion, but my original statement of
  

the problem wasn't entirely clear either.

  

Yes, I know that JAXB can be set up so that arbitrary objects can be 

marshalled and unmarshalled (as DOM elements), but the problem as I see
  

it is that for the simplest of data types explicitly supported by the 

JSR286 spec as event payloads, there is no obvious, inter-operable way
  

to marshal these event payloads so that they will be guaranteed to show
  

up in the receiving portlet as the same simple type that was sent.

  

For example, if portlet A sends an event:

  

eventResponse.setEvent(new QName("namespace", "localpart"),
"Simple 

String payload");

  

and portlet B receives this event, I would expect portlet B to be able
  

to do this:

  

Event event = eventRequest.getEvent();

String payload = (String)event.getValue();

  

-- and not need to do anything like this:

  

String payload = ((Element)event.getValue()).getTextContent();

  

The problem isn't that I don't know of any way at all to marshal the 

simple String payload into XML, or how to unmarshal that form back into
  

a String, but rather that I don't know how to distinguish between an 

event payload coming from another (third-party) WSRP producer or 

consumer that represents a marshalled simple payload type (like a 

String) versus an event payload that was deliberately configured by the
  

portlet developer to be marshalled into XML.  For example, if I get
an 

event payload in the WSRP event that looks like this:

  

<samplePayload>Simple String payload</samplePayload>

  

I could assume that this means I should return an Event object to the 

portlet developer whose payload is a java.lang.String object, as 

outlined in the sample above.  However, if the portlet developer for
  

event-sending portlet "C" actually created their own event payload
  

object and gave it a valid JAXB binding, such as:

  

@XmlRootElement

public class SamplePayload implements Serializable

{

   String value;

   public SamplePayload(String s)

   {

      value = s;

   }

}

  

eventResponse.setEvent(new QName("namespace", "localpart"),
new 

SamplePayload("Simple String payload"));

  

Then the developer actually intended for a "SamplePayload" object
to be 

sent, not a java.lang.String-- and a receiving portlet should probably
  

get an XML DOM element in the event payload instead of a simple 

java.lang.String object (assuming that the receiving portlet's WSRP 

implementation doesn't have a JAXB SamplePayload object configured). 

  

So my proposal would be a set of extension elements for containing only
  

the simplest of event payload values-- the simple types explicitly 

supported by the JSR286 specification-- so that various WSRP 

implementations could recognize those elements as containing a simple 

payload value (and ONLY a simple payload value).  I would propose
that 

arrays of simple values would not be supported, as they are not 

explicitly supported by the JSR286 spec as payload types, but arrays of
  

simple values can still be handled by JSR286 portlet developers by 

specifying their own JAXB bindings.

  

For example, we might define in the wsrp-extra namespace elements such
as:

  

<element name="stringPayload" type="xsd:string"/>

<element name="intPayload" type="xsd:int"/>

<element name="longPayload" type="xsd:long"/>

...

  

By being in the WSRP namespace (and being well-known elements) it would
  

be easy to distinguish these "simple" event payload types from
"complex" 

marshalled objects.  I can create such schema definitions for sending
  

simple payload types myself and put them in our proprietary namespace,
  

and they would work just fine as long as the events were not delivered
  

to a third-party WSRP producer, which wouldn't recognize them as 

intending to be "naked", simple values. 

  

So that is the point of my post- for at least the simplest of event 

payload types it seems like a WSRP-standard solution for encoding these
  

payload types would be beneficial for interop purposes.

  

  Kevin