Today I presented my suggestion to how Ajax should be implemented in my clients framework. I presented my layout to the two people I work with on the web side.
It however turned out that my layout one way to go, but there was a much better way.
The client's framework, named the MAP (Multi Access Portal) is a MVC based framework. The View is rendered by an XSLT engine, the controller part is a multi dispatch engine calling different application servers and their respective plugins (we call these services), they return XML which is then collected by the controller and is rendered as, in this case, a single HTML page, showing output of several different services.
So up to now we have had the complete page refresh in order to interact with the often main service, but a really slow service came along and we needed to do something asyncronous.
The services are detected using our own UDDI-like implementation, the whole framework created was pre-soap days, back when XML-RPC was gaining speed, we came up with our own solutions, solutions we might do differently today.
Anyway the service methods, (we call these capabilities, borrowed from the IMAP protocol) return XML, so it was obvious that we should aim to reuse this when integrating Ajax.
But since the services are put on application servers, we do not have any knowledge as such as to where the run, we could ask the services to return this - but we would also loose the authorization. My outlined setup had these weaknesses, so my colleague outlined we would simply call the frontend as a normal browser, session would be valid and authorization would still be in effect - a bit slower, but in general a better way.
But we would need the XML to go through the normal rendering and we would like to reuse the capabilities, since the data would be needed in two calls, the initial call resulting in a HTML view all asynchronous interactions would start from here, but should result in XML.
So the solution was to define yet another view pointing to the same service, resulting in a single page, containing XML acting as result for the Ajax callback.
This framework has run for ages and it's durability has impressed me again. I am still proud to have been part of the team who created this software and now we can integrate Ajax without changing any code at all not even for our services, some service will need refactoring in order to utilize Ajax for speed increases, I cannot wait to get started on that, but in general it works out of the box.
So I got my Ajax enable prototype up and running in no time with success.
I would like to thank my colleague who has kept it alive for so long, even when I left to do other things, I am glad to work along side him again even if it is as a consultant.
