By Dr Paddy Byers
Software as a service is one of the main principles of the new web and collaboration is one of the key distinguishing features of how things are now getting done. In this context, by collaboration, we mean the construction of composite applications by combining multiple, independently created, applications or services.
Collaboration itself is not a new idea. It is the result of the standard practice of breaking down complex entities into a number of simpler constituent pieces, and sourcing those pieces independently. It’s what software developers have been doing for years – except that the specific mechanisms for binding the pieces together (ie REST, SOAP) are new.
It was not always like this. What Joel Spolsky tells us is that, in fact, software developers hadn’t been following the collaboration mindset as much as we thought; and that NIH (Not invented here) is not always result of arrogance but a legitimate policy of eliminating dependencies on things that are outside your control.
But now we are seeing widescale reuse of services across the web – often by the hobbyist and experimental sites – but also by real commercial entities. And not just the Bubble 2.0 startups.
So what’s different now that makes it the right thing to do?
It’s not about new technology. Granted, SOAP and REST might make it easier to do certain things but industrial strength distributed systems have been around for a long time.
The answer is that in fact you no longer have a choice. The data is the software; you can’t make the data yourself. It becomes a dependency that you can’t eliminate any longer. .
Does any of this help us predict what will happen in mobile services? Are the drivers different in mobile than the mainstream web?
A key conclusion is this: if the technologies you use to build mobile services aren’t capable of independent modular construction, then you won’t be able to build comparable services to the mainstream web. You don’t necessarily have to use the same technologies as you would in the fixed web – but you do have to be able to build apps that bind to independently defined and provided services.
Java ME for mobile has traditionally lacked this – specifically, there is no means for a Java ME app to link dynamically to any independently provisioned libraries. (This kind of linking mechanism has existed in more functional java configurations but not in the CLDC that MIDP uses.) So there is no ecosystem for third party library (and, by extension, service) development.
JSR172 does provide a mechanism to do this using SOAP and WSDL. But here’s a problem: it is absent from MSA subset which is the next significant functionality target for operators specifying J2ME for their handsets. So MSA missed a key opportunity to reinstate a critical feature that will enable services to be structured by web 2 principles.
So to recap :
- use of third party services now is more the rule than the exception
- web 2/ajax apps do this well
- MSA subset missed an opportunity to allow J2ME to do this
As usual, comments welcome!