BlazeDS, AMF and read only properties
Posted by cornel | Filed under Java, LCDS/Blaze DS
A common scenario when building domain objects is to have read only objects properties. The serialization algorithm from BlazeDS/LCDS does not know how to serialize the read only properties – it needs both get and set methods (with one exception – the java.lang.Throwable class). So you have two options in this scenario if you do not want to build adapters over your domain object:
a)Build your own serialization/deserialization mechanism
In order to do that you need to implement the java.lang.Externalizable interface for the Java classes and flash.utils.IExternalizable for the ActionScript ones. The Java example is here and the AS here.
When using this approach you have the following advantages/disadvantages:
Advantages: the serialization/deserialization is much faster
Disadvantages: greater development time, and you lose some optimizations related to data compression (like string references and writing numbers in fewer bytes). Of course, you can build your own optimizations but again this means more development time
b)Patch the code from BlazeDS. You either add the includeReadOnly = true line in the BeanProxy constructor (this flag is used for Throwable serialization), or, better yet, take the modifications from the current BlazeDS branch where this feature was implemented.
September 21st, 2009 at 10:46 pm
We were working with BlazeDS and ran into some serialization issues. Some having to do with AS Number NaN being converted to a Double as 0. I dug into the code and found that it was easy to fix going into blazeDS but nearly impossible to fix on the reverse serialization.
In order to not have to go through our some odd 40 VO classes and implement our own custom serialization we actually took a look at GrantiteDS. GraniteDS actually has the ability to add an annotation to your class and it will implement the custom serialization pieces on your class at compile time. Then as an added feature you can actually generate the ActionScript VO’s from those java classes using their tool. Which allowed us to implement custom serialization without spending a week writing the code.
Another pleasant surprise was that we found granite to work much faster than Blaze. That was not something we had planned for but was a nice bonus after the switch.
Just tossing out an item for consideration.
September 21st, 2009 at 10:54 pm
Hi Simeon,
Thanks for your comment. When I’ll have time i will dig on GraniteDS.
Related to performance, do you have some quick number?
Another thing: hessian (caucho implementation) is also much faster than amf3 serialization (from blazeds) however I discovered some edge cases where hessian were not able to serialize efficient at all. It would be nice to do a comparison with GraniteDS also in terms of robustness.
November 24th, 2009 at 10:07 pm
Hello i got a question, if i have two instance of the same dataservices, pointing to the same destination, why if i change the collection asocciated to one ds, the flag commitrequired is set to true in both dataservices?
best regards
December 16th, 2009 at 11:26 am
Acnesiac,
The dataservice object should have one instance per destination. It’s not ok to have two of them.