tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Sebastien Delfino <jsdelf...@apache.org>
Subject Re: Remotable interfaces and pass by value, was: Data transformation from/to POJO
Date Thu, 06 Dec 2007 16:45:44 GMT
Simon Nash wrote:
> This approach sounds good to me.  I'd like to suggest one small
> addition to the final "else" clause, based on the following spec quote:
>  Java SCA Annotations and APIs spec: 1531
>  Complex data types exchanged via remotable service interfaces must be
>  compatible with the marshalling technology used by the service binding.
> If the binding uses XML serialization, then the proposed final "else"
> will do the right thing.  (For Tuscany, this includes the default
> binding.sca.)  However, if the binding uses some other serialization
> such as JSON, then it might be more compatible to use this same
> serialization in the local pass-by-value case.  There are libraries
> (e.g., [1]) that provide this functionality.
> So the final "else" would become:
>  else // if we have a simple JavaBean and an XML binding
>    symbol is copied using JAXB XML serialization
>  else
>  else // if we have a simple JavaBean and a JSON binding
>    symbol is copied using JSON serialization
>  else
>  // I'm not going to list all possible bindings but you get
>  // the picture...
> Thoughts?
>   Simon
> [1] http://json-lib.sourceforge.net/usage.html

I agree that we need to take JSON into account (that was my next thought 
too I just didn't want to pile too many aspects in this discussion).

I think it would be useful to put a table together comparing the JSON 
mapping and the JAXB mapping. Wouldn't it be nice if we could tell 
application developers "if you use these patterns and types, your 
business object will work unchanged with XML and JSON"?

Concrete use case in hand, the store scenario flows the Item bean over 
XML, JSON and in-VM pass-by-value interactions. I'd hate to have to 
write 3 different Item beans and mediation code to cover these 3 cases.


To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

View raw message