Ajit Jaokar is the founder of the London based publishing and research company futuretext (
Mobile mashups: The implications of ‘Data is the intelligence’ on mobile software development
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
New technologies like Mobile Ajax themselves don’t solve this problem. Web-based apps (that use SOAP or REST) to access web services do this well. However, Mobile Ajax is relevant because it means that those web-based apps have sufficient interactivity to be usable and useful, which wouldn’t be the case (typically) if you wrote a conventional HTML/Javascript app without Ajax.
As usual, comments welcome!
Very interested in all the points surrounding mobile ajax as we have been experimenting with the Opera platform ourselves.
My main concern is that for mobile ajax to have any significant impact we are going to need the majority of users equipped with a decent ajax ready browser.
Frustratingly, as usual, this seems a way off – years away infact.
Comment by Richard Spence — September 19, 2006 @ 8:12 am
Hello Paddy,
I agree totally with the first part of this post, but not with the conclusion…
The good think with Web services, is that they are not linked to a single technology…And it’s very easy to create a composite application in most of the existing techno:
- Flash/FlashLite
- native (Symbian, Windows Mobile, Brew)
- Wap/Html/Xml
- JavaMe (and yes, no need to bring the complexity of JSR172 to call for instance Flickr…). Even in MIDP1.0 you can create good composite applications
- and in the future, Ajax (but currently it’s the one who haves the lower installed base)
Comment by Thomas Landspurg — September 19, 2006 @ 9:58 am
I don’t think the fact that Java ME and other frameworks lack certain connectivity technologies (eg REST & SOAP) is a problem. Most developers of complex connected applications have been using server side proxies for years. In this way a single application to server request can be translated into several different web service API calls. The reponse data from these API calls can then get formatted into a single custom response which gets sent back to the phone application in simple XML. Conclusion… its painful but possible!
Comment by Jason Delport — September 25, 2006 @ 5:58 pm
Widgets all over again…Content came back with MVC again!
Suddenly everything’s coming up widgets – September 1, 2006 Is an interesting introduction to the widgets and why this concept is successful:
…In the early days of the Internet, most companies would create a destination website, wait for u…
Comment by Everything and the Mobile Software Universe... — September 27, 2006 @ 9:45 pm
Yes data is the central point, and the way to provide it to the user (to represent it) should be as flexible, as platform “ad hoc” and custom as possible: if no you will never fit in an ultra low cost phones where the high volumes are and will be for a foreseen futur.
I agree with the previous comment from Thomas Landspurg : many technologies exsit today to do some sort of data interpretation and display, but 2 big things are lacking today:
-Standardization and full description (access, content, etc) of the provided web services and their data: it has to be framework (java/flash/.Net…ajax also) agnostic!
-Some kind of more “ad hoc” frameworks to allow third party ecosytem (like you said) on each type of phone. (a little advertizing here : it is what we are building at http://www.open-plug.com, working directly with ODM/phone manufacturer and existing third party IP providers).
Thomas
Comment by Thomas Menguy — September 28, 2006 @ 10:31 am