Atomized Integration, IBM Worklight and AngularJS

Over the past year, I have worked fairly extensively with IBM Worklight, Big Blue's enterprise mobility package. In the coming year, I plan to find more things to do with Bluemix, IBM's cloud mashup line; for now, some thoughts.


In general, my guidance has been to use open source mobility frameworks, PhoneGap for cross-platform, Bootstrap for Responsive Web Design, Angular for templating, and some form of OAuth2 for security, at least until the vendor solutions from IBM, Oracle, et al reach a higher level of maturity, since these are stepping stones.

If you look at the latest Gartner quadrants for enterprise mobility and cloud for the previous year, you will see IBM maturing in the MADP space and Oracle maturing in the cloud space... but maturity in both areas is necessary for enterprise mobility to fire on all pistons.

Worklight does three things really well:

1. Simple adaptation on the server-side, using Rhino-based Javascript adapters.
2. Integrating with existing Websphere and SAM infrastructure.
3. Increasing productivity through modularization and emulation.

Probably the biggest win here is 3. I started out 2014 working with Firefox OS, Saxon-CE and AngularJS, so I was already committed to using Javascript and XSL as much as possible, and Worklight Adapters played into this approach nicely; however, after *hating* the slowness of native Android development using the Android toolkit, what I appreciated most about Worklight was being able to use an emulator that ran as smoothly as the Firefox OS simulator (which is really just a browser plugin). On the server-side, we are becoming more accustomed to devOps tools like JRebel; on the client-side, we should have similar expectations - is, don't use the Android emulator if you can avoid it. It sucks.

I have mentioned previously how much I like Worklight's lightweight Rhino-based adapters. They are intentionally lightweight, eschewing any sort of SOA reusability. A Worklight adapter does one thing, and it does it well. This can be initially quite pleasant, then very frustrating, and then liberating, as you sort out how much integration you need to do in your client applications. My experience has been that a well designed piece of XSL can convert an XML data source into some standards-compliant JSON, and then a client-side library service can take it from there.

For instance, consider that I have an XML data source containing a number of patient records. Let's say it is NIEM compliant XML. I could build a client application that can consume NIEM compliant JSON, and then all I would need to do in Worklight is create a very simple boilerplate adapter that transforms the XML into JSON. This is assuming that my server-side data source doesn't already support JSON-flavoured NIEM, which would be even simpler. In other words, if my intent is to take a NIEM compliant data source and build a NIEM compliant mobile application, this is quite straightforward. Server-side Worklight adaptation transforms XML into JSON; client-side Angular data-binding injects JSON into the HTML-based presentation layer, and presto, you have an application.

Granted, the development process is not that easy, and let's consider now that we have a number of data sources, some of which are NIEM compliant, some of which are HL7 compliant, some of which are based on direct SQL access, and some of which are ad hoc.

When you look at the various Worklight adaptation examples, you might get the idea that RSS is treated preferentially, which is untrue; however, thinking of these adapters as syndication is still a useful approach.

Throughout the past year, I have been working with HL7 FHIR, a draft standard from HL7 that among other things introduces a JSON-based pattern for aggregation and composition that is essentially Atom syndication in JSON instead of XML. It turns out that if all of my Worklight adapters create Atom-compliant JSON on the server-side, then I can use a Javascript Atom library in the client, and it really doesn't matter what format my data sources are using. By the time they reach my client application, they are all Atom-based.

The client-side service that I have written - using Angular for modularization - is responsible for merging multiple Atom streams. Once I have a single Atom stream, data-binding takes place, so that information can be presented. In practice, this can be frustrating because Atom is intended for serialization of information, but an Atom bundle can also contain relative links between entries. This is fundamental to the way HL7 FHIR works, but not NIEM, so I have ended up creating synthetic and essentially schemaless resources as necessary. Ideally, all information could be mapped into Atom-syndicated FHIR resources. Maybe that's a good project for this year.

Adaptation frameworks always run into a problem based around the decision to go lightweight or go modular. I like that Worklight has gone lightweight, but I am frustrated that I can't reuse just a little bit more code between adapters. In particular, I would really like to use a single set of XSL transforms to support multiple adapters. Perhaps there is a way to do this, but for now, I am still forcing myself to prune my adaptation code as much as possible to keep it easy to maintain. If I find myself using the full set of DocBook or DITA transforms in an adapter, it's probably time to rethink my approach.

On the whole, I have enjoyed working with Worklight adapters immensely; I don't think this would be the case if I was not also using Angular or some other Javascript framework to support development of client-side services. I haven't particularly used the built-in Worklight support for Dojo or JQuery, but I'd go so far as to say that without some sort of hybrid framework support, you will lose much of the productivity that Worklight gives you. After a year, I have reached an understanding that I would not enjoy using a framework like Angular without a platform like Worklight, and I would not enjoy using a platform like Worklight without a framework like Angular.

Unless, of course, the platform was also a framework, which is what approaches like Meteor promise.