In The Trenches: Pushing RIA Development In Non-SOA Environment
In 2002, Jeremy Allaire wrote a whitepaper that arguably spawned the RIA revolution. In that whitepaper a couple quotes stick out that are related to a lot of the conversations I have with potential clients even today. Here’s one:
Rich clients are made much more valuable when combined with logic and data
delivered from application servers and XML web services.
Of course to developers of n-tier systems like the ones using rich clients built with Flex, Silverlight and AJAX, this is a given. This is a rudimentary building block in the creation of any client-side application, be it thick, thin or somewhere in between. A services layer doesn’t really make the rich client “more valuable”, in reality it makes it possible. Try building a rich client with name value pair text files or screen scrapes. I guarantee epic fail. The problem is, not all companies have services in place today.
For the enterprise or legacy developer still entombed in the day to day of a legacy infrastructure, where custom developed desktop executable clients and the request-response page rendering model of old style brittle HTML applications using vendor specific markup rule the roost, though, this is a novel concept. This might be a little foreign or even scary, perhaps. If nothing else, it’s at least seen as something nice to have, but not mission critical at this point, or at least not justifiable in it’s ROI.
Why is this? I have done a lot of thinking on this, as I encounter this sort of issue fairly regularly as an external consultant brought in by business units to assist in media delivery or client side application design needs. Some things I sense:
- To expose APIs to your business logic tier allowing client side developer to retrieve reports, operate CRUD transactions or even reduce clicks via simple DOM scripting seems like a total loss of control. Previously, if a C level exec needed a specialized report or dashboard for some vital info, it was a ninja-like developer who needed to swoop in and generate this view. This project might take months or at least require special requsition of resources via internal workorders. Now, with a properly documented and robust API, nearly any developer can wire up XMLHTTPRequests or similiar to an endpoint and make something passable for that board meeting. A little JQuery and wapow.
- Lack of general faith in the “web2.0″-ing of enterprise media deployment. Dependancy for 20 years of Windows/early Mac OS might do this to you. Enterprise document management system vendors reliance on desktop applications for management of these types of systems do little to help assuage this fear. If it’s not a real program, a application I can run on my desktop, it doesn’t count. I can’t possibly do as mush or work as efficiently without one.
- Misunderstanding of the technology. As evidenced by the many misguided articles about Silverlight, Flex, AIR, AJAX, Sproutcore and on and on, the three letter acronym soup is just too much for technology policy makers and committees at many of these institutions/corporations. SOA, SOAP, REST, RPC, JSON, XML, SWF, MXML, XAML, etc. If tech journalists and podcasters can’t even get this mess straight, how can we expect IS/IT staff to figure it out?
A little more context, I work in the midwest. Not the valley, not the east coast. In the grainbelt. We work with companie, museums and educationsl institutions s who need technology to produce hard goods or foods or services (financial, educational, entertainment and otherwise) consumed by people. They don’t push bits, bytes or set up servers to serve as the primary focus of the business. Technology is there to assist them in the business goals. So how do we push these companies towards the SOA so promised in the 2002 paper by Jeremy Allaire? Great questions.
I’m forming some answers, but it’s a toughie. Maybe it’s going to be the dbms/application server providers and admins and not the UI designers and middleware developers that drive this. When your SQL server is spewing out services by default with no extra configuration and doing it the old way is seen as the hard way, then maybe the panacea will be here. I am well aware of what SQL server 2005 and newer does this, but what about the heads down IT professional? And what about the LAMP stack admins out there? On and on.
Now this doesn’t seem like an attractive timeline IMHO. Users are clamoring for rich easy to us experiences. Flickr, Google Maps and various nice eCommerce sites are really pushing this. These tools are built on modern SOA systems, with APIs and all kinds of modern hoohah that makes the web so great. This is indeed creating a disconnect between the non-web arena companies internal technology offerings and the expectations of the audiences that need to use these tools for common business tasks.
This post is getting a bit long, so I’ll wrap it up here, but I’d love to here from you on this… what challenges are you facing when attempting to create RIAs with customers or internal teams? How are you assisting teams move to services? How are you dealing with these sorts of technology/platfrom related roadblocks?
