The past half year or so of developing for a company within the boundaries of a large application that spans multiple teams and multiple languages was quite a departure from my previous few years of experience freelancing. While freelancing I happily kept within the confines of the Adobe products, and probably 95% of the time within Coldfusion. Sure I would use Javascript, HTML, and CSS, but my applications were built with Coldfusion and Coldfusion alone for the dynamic portion.

As a freelancer I built code with Coldfusion knowing it could be executed by Coldfusion. Now I have to build code that is capable of transcending development languages, as well as performing optimally in the transition. While not all code moves between the languages we work with, I have to assume that it could at some point.

Applications should be configurable to some point, and when I performed Coldfusion centric development I most likely would have built my configuration in CF. This isn’t bad if your application utilizes CF and CF alone. In fact, it is certainly the best route for performance. However, as I now know, we don’t always get to develop CF centric applications. So the question arises – how can I build a configuration and data objects that can be passed to most any language and still work?

I began to, and still primarily, use XML to build configuration settings for an application. XML is a well defined and portable format that can cross most any boundary you want it to. XML can also have transformation objects (XSLT) and schema validation (XSD) applied to it for further control. It allows the configuration options to be externalized from the core components of the application. This means that Coldfusion, .net, Java, etc. can tap into that configuration for their own use. It also means that an application does not necessarily need to be regression tested in the case that data or configuration is manipulated.

Beyond configurability, we sometimes need to maintain a log of complex data that can be read across systems. For this purpose I’ve found JSON to be most useful. It’s light-weight, super portable, and is more than capable of handling objects as character strings. Here an application built with Java can log complex objects as JSON strings. A customer-facing Coldfusion application could then parse through the logs evaluating the JSON string objects and displaying appropriately.

Lastly, using JSON or XML allows complex data to be stored in a language that is more clear than the dynamic languages. For example, I probably couldn’t just jump right into a .net object and start parsing through it and utilizing the data the same way a .net developer probably couldn’t jump into a Coldfusion object and do the same. However, it is highly likely that both the CF and .net developers both understand XML, and maybe a little less likely JSON. This means that if the object structure or data needs to change the Java, .net, or Coldfusion developer can easily make the necessary changes to the externalized XML file and assume that the processing language will be capable of handling the change.

So, just some thoughts on architecting an application in a cross-language environment, while also possibly adding externalized application configurability that certainly reduces core functionality regression testing when changes need to be made.