As I sit here on the last day of my summer vacation overlooking nature and holding a Jack on the rocks, determined to write this article, I can’t help but think: “wow times goes by fast.” I was going to write this article the first day, no wait the second... well you know the story. But that did get me started on how fast time goes, and with it, technology. I’ll spare you the non data base technology that came to mind, but it also crossed my mind how powerful and flexible DB2 (both on LUW and on z/OS) has become. Remember when we only had SQL to access our data and for more than two decades having SQL was enough to handle your database requests? In the last few years we were introduced first to XML and later to JSON. Both are valid ways of accessing and exchanging data both growing from a need to be more flexible, and both are supported within DB2.
The early adopters of the XML features probably don’t like to hear the “mighty JSON” song, but does that mean that they will have to redesign, rewrite all of their XML using applications and transform them to JSON? Probably not, and in some cases, certainly not. As I said before, the two most common heard benefits of JSON are faster/easier development and great for mobile applications (less overhead).
First of all, the fastest development is the one that you have already done. If you just finished (re)writing your applications using XML data exchange and the exchange between you and your customers or business partners goes smoothly, why change? It could be useful to look into JSON for future projects, but rewriting might not be on the agenda. This is especially true if your current application doesn’t need the mobile device smaller bandwidth aspect. I can imagine that two banks exchanging data among one another aren’t really bothered with the entire mobile device problems. Does that mean JSON isn’t important to them? Not at all. When those same banks offer a mobile banking application to their customers JSON might be a way to faster introduce new features and lower the overhead for the data transfer.
One reason to stay with XML is the schema-validation possibility. This allows users to apply “business logic/rules” to the data that is exchanged. This is not possible with JSON as it has no validator, with a challenge then being that every application is responsible for validating its inputs. Whether you need or want a central repository for enforcing business rules is up to you, and will surely change from application to application.
This month we will be focusing on both XML and JSON. So get your mobile devices ready or get behind your trusted computer and find out the pros and cons. Find out which of both technologies is best. Feeling nostalgic on this last day of my vacation I’ll answer that last question with a classic. It depends.
Content Committee Leader
IBM Gold Consultant