Agile Software Development

XML Magazine on Ulitzer

Should the enterprise standardize on JSON or XML as their lingua franca for Web 2.0 integration? Or should they use both as best fits the application?The decision impacts more than just integration – it resounds across the entire infrastructure and impacts everything from security to performance to availability of those applications.

One of the things a developer may or may not have control over when building enterprise applications is the format of the data used to communicate (integrate) with other applications. Increasingly services external to the enterprise are very Web 2.0 in that they provide HTTP-based APIs for integration that exchange data in one of a couple of standard formats: XML and JSON. While RSS and ATOM are also seen in APIs as options, these are generally used only when the data being presented is frequently updated and of a “listing” style nature. XML and JSON are used to deliver more complex structures that do not fit well in to the paradigm described by RSS and ATOM formatted information. Increasingly libraries or toolkits are used to build interactive Web 2.0 style applications – XAJAX, SAJAX, Dojo, Prototype, script.aculo.us – and these, too, generally default to XML or JSON, though other formats are often supported as well.

So as you’re building out that Web 2.0 style application and thinking about the API you’re going to offer to make it easier for partners/customers/other departments to handle integration with their Web 2.0 style applications – or even thinking about the way in which data will be exchanged with the client (browser) - you need to think carefully about the choice you’re making. There are pros and cons to both JSON and XML, and the choice has implications outside the confines of application development in your organization.

The debate on which is “best” or “optimal” is far from over, and it’s likely to eclipse – for developers anyway – the religious-style wars over the choice of browser. Even mainstream technology coverage is taking an interest in the subject. A recent piece from C|NET on “NoSQL and the future of cloud databases” says “Mapping object data to JSON, a JavaScript data interchange format, is far less complex. The "schemaless" nature of many of these products is an excellent fit with agile development methodologies.” Indeed, schemaless data formats are certainly more flexible, but that flexibility has a price that may need to be paid by the rest of the infrastructure.

A developer’s choice in which data format to standardize upon has broader impact on the organization than you might think. Application-aware infrastructure relies heavily on the ability to parse and understand application-specific data formats and protocols to provide security, acceleration, and scalability. Choosing a format for which there is very little or no support impacts the ability of the rest of the organization to effectively implement and deploy these types of functions in the appropriate infrastructure solutions, which means complete responsibility for providing these functions rests on the shoulders of the developers – and the application servers/platforms upon which those applications are ultimately deployed.

If intermediaries can’t parse the data format natively – or at a minimum have the capability to implement a parsing scheme – application delivery becomes problematic. This is especially true for security-related infrastructure because you’re effectively losing the ability to apply valuable security policies and functionality that is tied to application-specific data. Effectively you’re reducing what is (or could be) an application-aware network back to a circa 1999 network: little more than a set of dumb pipes.

This can also result in certain network services no longer being usable on the data: caching, for example, relies heavily on understanding the data and objects being returned. While most understand and can act on XML, not many are up to speed on JSON or <insert custom format here>. Using a format that is unknown to the caching solution can result in a loss of caching functionality in the network. That puts the burden for caching back on the web and application servers, which requires resources. Resources used to support caching takes away from the resources available for core application processing, which reduces overall capacity and can impact the ability to service customers. Security, too, may be impacted – from application firewall functionality and capabilities down to integration with identity stores for authentication and authorization.

In general, there are a wide variety of solutions that support XML across a broad category of functions. There are far fewer that natively support JSON.

Before making a decision go talk to the network, application network, and security teams. Determine whether there is a concern over the use of one format over another and then be sure to factor that into the decision making process. You still might need for business or technical reasons to choose a format that might negate the ability to use some infrastructure solutions most effectively, but at least you’ll have made an informed decision and understand the ramifications of that choice.

Don’t think you’re off the hook, non-developers. As network, application network, and security professionals you should equally understand what kind of data – not traffic – you’re going to be securing/delivering/accelerating and how that impacts the choice of solutions from your perspective. When you’re looking at solutions you should evaluate their capabilities at the application layer (HTTP and beyond) with an eye toward the types of data formats the solution will need to handle. If you’re looking at a web application firewall and it handles XML and traditional HTTP POST encoded data, but developers are using JSON to exchange data, the solution probably isn’t the best one for your organization. If, however, you can’t find a solution in a particular niche that supports the data formats in use, you’ll need to examine products with an eye toward extensibility; that is, can the product be extended via plug-ins, scripting languages, or other mechanisms to provide the functionality you’re looking for.

The key is that you’re aware of the data formats in the first place, as they directly impact the usability of infrastructure solutions to perform their given functions in your environment on your data.

Before making a purchasing decision on a product designed to manipulate or apply policies based on layer 7 data, talk to the development teams. Determine what formats are being used in a broad sense: XML, JSON, SOAP, HTML, RSS, ATOM, etc… and take that list with you when you evaluate solutions. Make support of those formats – or at a minimum the ability to be extended to support those formats – part of the decision making process. As with developers you might have an overriding business or technical requirement that forces the decision away from a product that can support those formats natively, but at least you’ll be able to explain to management why if or when the subject comes up.

In an increasingly application-aware world, where security and acceleration and even load balancing decisions are made based on business and application data rather than network characteristics alone, it is even more important that developers and their networking / security counterparts meet not just at the end of the development life-cycle as a formality for deployment, but at the beginning of development, too. The integration necessary to architect a dynamic, flexible application infrastructure not only requires collaboration at the infrastructure layer, but at the human layers as well.

It’s no longer enough just to categorize applications by name (PeopleSoft, Exchange, SharePoint) or even style (“Web 2.0”, Client-Server). It’s more important than ever that applications also be understood based on the data formats they use to exchange information both with consumers and with each other via APIs, and that not only developers take an interest in what data formats are being utilized.