Hi Wolfgang,
> OK, there is many an occasion where a light-weight data representation
> that's not bound by and to an XML Schema is the right choice. (I've
> been serialzing data as Perl hashes or, more generally, as Data::Dumper
> text, which is similar in spirit to JSON.)
I see your point. But Perl is of course much closer to JSON in its approach
than Java.
See below for my example.
> But,as I understand it, JSON is simply a text with a specific syntax, to
> be
> understood by communication peers.
Do not underestimate JSON's role on the Web. JSON is used nowadays in many
situations, where (schemaless) XML would earlier be used. This of course has
to do with the popularity of JavaScript in client-side browser based
applications. And I'd say that JSON usage will only increase for this kind
of apps. XML is getting used more and more only on the server-side.
Additionally, JSON has some advantages over (schemaless) XML. It is more
light-weight, can be parsed faster and more easily and is supported by
almost any client-side Web framework. It is native for JavaScript. Plus,
JSON is just shorter than XML. It is important for speedy communication
between (browser)clients and server-side. And it saves badwidth and
latencies over cellular links, which is also important nowadays.
> So, what's the point in forcing this format into an XML corset?
I'll try to elaborate here on this topic.
After the generic introduction about JSON, let me explain better our
application architecture.
We have a set of >40 Java classes representing a model of our domain area.
These are proper classes with a regular structure, setters/getters and not
just a bunch of free-form multi-level, nested maps, like it would be the
case in JavaScript or Perl.
Client apps should be able to talk to the front-end of our system using SOAP
or REST approaches (using XML payload). Therefore, we decided to use JAX-WS
and annotated our classes using JAXB annotations.
At the same time, we need to persist our domain model objects represented by
these classes in the backend. We used to use an RDBMS as a backstore, but
mapping was a bit too complex. So, we decided to try out one of the
document-oriented databases. We have choosen MongoDB, as it is modern,
supports Web friendly JSON format and such things like sharding, map/reduce,
etc, which are important in today's systems. We also considered using XML
DBs, but we were not quite convinced, as they seem to loose the momentum to
NoSQL databases and do not support many of the features related to
replication, synchronization, parallel processing and cloud-readyness.
So, after having taken the decision to go for MongoDB and JSON storage
format, we needed a method to produce JSON from our object graphs. Just to
remind, these are the same classes that are already annotated using
JAXB-annotations. Of course, there are dedicated JSON libraries like Jackson
or Jettison with their own annotations and the like. But, we thought, we
already annotated all our classes with JAXB. Why do (again) almost the same
using additional annotations? We saw that Jersey supports almost all of JAXB
annotations and can produce "equivalent" JSON instead of XML. (It seems to
achieve that by reusing of JAXB run-time to a very big extent). So, we tried
it out and it worked out nicely for 90%-95% of our model classes. But for a
small amount of fields, e.g. some (not all) maps, mapping produced by Jersey
results in a very unnatural JSON as described in previous messages.
Therefore, we thought let's provide JAXB with some custom handlers/callbacks
that would allow us to have more control over marshalling for those corner
cases. And this was the reason for starting the whole discussion.
> To embed it in an XML document, I'd senda JSON text as a single element of
> type xs:string.
The big question is how you produce this JSON string, first of all. As
described above, we have quite a complex model. Producing JSON from it by
hands is out of question. It should happen automatically.
> Also, you always have the option to pass XML data through a
> (presumably *very* simple) XSLT transformation, to expand or collapse
> data as necessary.
Yes. You are right. But is it really the easiest possible solution? Is it
really light-weight? What if you also want to serve 10000 requests per sec?
AFAIK, XSLT performance in JDK is not so good to handle this.
>Re your "...should be improved?":
>Please understand that JAXB is an implementation of the specification
>"Java Architecture for XML Binding" (by Sun), and other XML serializers
>are based on this, too.
On the one hand-side, I do understand it. I was also involved in
standardization of some other things and I know how it works.
On the other hand side, I hear this "Even if it has some problems,
drawbacks, this is still an implementation of (eventually not so perfect)
JSR XYZ" quite often recently from JavaEE people. This is a correct answer,
but it is sort of a rather "defensive" one. JavaEE seems to loose its
position recently due to many different factors (Oracle-Sun takeover, Spring
factor, rise of JavaScript on client-side, etc). Many consider it to be too
complex, too heavy-weight, too inconvenient in some situations. So, to gain
its positions again (if it is possible), JavaEE should be probably more open
towards new trends. May be more proactive thinking could be beneficial here?
E.g. if there is such a new emerging popular technology like JSON/JavaScript
(the new "king of the block"), one should probably stop thinking "it is not
well thought through, lacks many advantages of static typing and XML schemas
and is not required by the JSR XYZ", and start thinking "JSR XYZ seems to be
very related to the new technology. We have all the tooling and runtimes we
developed during last years. They still lack it to a big extent. So, what
can be done in JSR XYZ to support this new technology and gain more
developers, more application and more publicity?". May be first some
vendor-specific extensions should be done, to check the feasibility. Should
it work, it can be then proposed as JSR extension/update. Do you see my
point? I think this way of thinking is more benefical for everyone and more
constructive.
> Vendor specific extensions aren't good for interoperability, and changing
> the spec in any way beyond
> the limits of XML Schema is definitely out of scope.
For one, see the previous paragraph.
Also, nobody proposes changing the XML Schema standard. This is not required
and is not realistic.
I'm trying to be more pragmatic regarding JSRs in question. I'm just saying
that JAXB/JAXWS/JAXRS are very good JSRs. Initially, most of them were
developed to support XML-based processing and messaging. A lot of time was
invested into them. Good tooling and good run-time were created and it took
years to come up with those efficient implementations. And the main purpose
of those run-times and tooling, to my understanding, is not to fullfill the
standard as such, but to serve developers and make development easier and
cleaner. Now, JavaScript based frameworks are already impressive, but are
still at their early stages. A lot of functionality that they need also
includes e.g. SOAP, REST support in form of run-times and tooling (both
client-side and server-side). And a lot of this is still lacking. Therefore,
it would make a lot of sense to reuse the gained JavaEE experience and the
results from the mentioned JSRs and extend/adapt them to support
JavaScript/JSON next to JavaEE/XML.
That's it. I hope I managed to communicate my view on this issue.
Best,
Leo
--
View this message in context: http://old.nabble.com/Custom-mapping-for-Maps-in-JAXB-tp28779221p28934163.html
Sent from the java.net - jaxb users mailing list archive at Nabble.com.