JSON as a data binding

In my never ending question for the be-all, end-all cross-language data binding story, I've been thinking lately about JSON.

First, consider that SDO is an important part of IBM's SOA story; it's a or the story for sending data via SCA. Let's compare SDO and JSON, in terms of the Java interfaces.

SDO's DataObject interface looks something like this (see page 23 in the referenced PDF file). Actually, this is just a bit of it.

public interface DataObject extends Serializable { ... boolean getBoolean(String path); byte getByte(String path); char getChar(String path); double getDouble(String path); float getFloat(String path); int getInt(String path); ... }

Now let's compare to JSON's Java interface, and again, just a bit of it.

class JSONObject { java.lang.Object get(java.lang.String key) boolean getBoolean(java.lang.String key) double getDouble(java.lang.String key) int getInt(java.lang.String key) JSONArray getJSONArray(java.lang.String key) JSONObject getJSONObject(java.lang.String key) long getLong(java.lang.String key) java.lang.String getString(java.lang.String key) ... }

Look familiar? Now, sure, SDO has a lot more 'stuff' in it than JSONObject, like change tracking, but, really, I'm not interested in that stuff anyway. In any case, if SDO is good, and JSON smells like SDO, I guess it must be kinda good also.

Next, if I had to implement just one type of 'object' serialization in a server, obvious choices are XML and JSON. JSON is trivial for JavaScript code to eat, and any other language will require some library, but there are plenty available (scroll to the bottom), for free, as long as you don't use them for evil. With XML, everyone needs a library. Not so much of a problem that you need some extra library, because everyone has XML parsers in their language environment, but it's more code you have to write to get the data. If AJAXy web apps are a core piece of what you're doing, JSON may be what you want to make your client-side app code to be a little snappier.

Lastly, one of the things I always think about with data-to-xml bindings is whether fields/properties/etc should be rendered as attributes or child elements. Sometimes, you have no choice; if the field is 'complex', you will likely have to render as a child element. With a string-valued field, you got a tough choice. If the value is small, it feels better usually as an attribute; if it's longer, it feels better as a subelement.

None of this is an issue with JSON. Blissfully choice-challenged.

Sure, there's gotchas with JSON, like the fact that it really just models structs, lists, primitive types. Specifically, it has no way of handling classes. This is an issue when you want to serialize some data in JavaScript, and send it to a typed language, and would like to have that data turned into typed objects; instead of something like SDO's DataObject or JSON's JSONObject. No one wants to deal with that crap. The obvious sort of thing to do is have a magic field in your struct, named maybe "__type__" or something, that provided an indication of the class. This would of course be a pain to have to add manually in the JavaScript object, but if you could provide thin wrappers in JavaScript to poof objects like this up ....

So, I'm thinking it would be interesting to see what a JSON data binding story would look like. On the Java end, I'd want to deal with EMF objects, so the idea would be to serialize EMF objects using it's metadata, and when JSON is deserialized, somehow it gets turned into EMF objects. On the JavaScript end, code that generates these objects would be done with some kind of thin wrapper to add the magic field.