An article from John Crupi (reference below) reminds me of many discussions around the topic of “what do we do with services?” For many, services are simply a mechanism to expose back end functionality that can be consumed by a composite application. But I have always been more than a little uncomfortable with composite applications because they are a kluge – to the extent that many refer to mash-ups and composite applications in the same breath.
John suggests that business unit developers have a hard time consuming services for all sorts of reasons. They may be the wrong granularity, there is no governance, or the right services don’t exist. So the conventional response to service based solution assembly is to layer even more complexity into the stack comprising more middleware, orchestration tools and portals.
I don’t necessarily agree with all John’s arguments – if a service is suitably generalized, abstract and genuinely loose coupled, and conforms to a sensible reference architecture framework, it can be easily consumed to support many different contexts. But I am attracted to the idea of a client side programming model that allows us to implement process logic and easily make asynchronous calls to the server while managing the presentation of the Web Page, without all the additional reuse infrastructure complexity that is becoming ubiquituous.
"AJAX, shorthand for Asynchronous JavaScript and XML, is a Web development technique for creating interactive Web applications. The intent is to make Web pages feel more responsive by exchanging small amounts of data with the server behind the scenes, so that the entire Web page does not have to be reloaded each time the user makes a change. This is meant to increase the Web page's interactivity, speed, and usability." Source: Wikipedia.
But beware! The primary issue with composite applications and mashups will also apply to AJAX based service consumption – it’s essential to avoid coding “business” logic into the client layer. The need for a solid reference architecture is paramount. The reference architecture must provide clear guidance (policy) on the purpose of each layer, permitted behaviours and dependencies. The same reference architecture must also guide the identification and design of services so they provide a useful capability that can be easily reused and specialized with the minimum amount of overhead. Some may call this granularity, but in reality it’s nothing to do with size, it’s all to do with creating designs that are fit for purpose.
Within this architectural context it seems to me that AJAX could support a really worthwhile objective particularly for relatively simple or narrow focused applications and processes – to easily consume services with the minimum additional infrastructure.
AJAX + SOA: The Next Killer App by John Crupi
