RIA clients: Not just for the Web anymore

It's hard to ignore the obvious contrast between the thriving and vibrant Web 2.0 software industry, rife with Ajax-powered Web clients, and the frequently slow moving, ponderous Web services and SOA efforts in the mainstream IT community.  Rich Internet Applications (RIAs) are getting lots of attention and That fact is, reusing Web services inside your organization isn't like plugging into some Web services you happened to find out on the Web.turning heads with flashy graphics, immersive experiences, and roaming software and information.  RIAs, usually associated with Ajax but often created just as compellingly with Flash, Flex, or Laszlo, require no installation, love Web services and SOA environments (heck, they require them), and don't care much which browser you use.

Increasingly, the IT community is seeing RIAs as successful models for creating lightweight front-ends for SOAs.  ZDNet's Dana Gardner cogently nailed many of the high-level issues recently.  However, though I completely agree with him it's the future, the problem is that it is the future.  There are internal forces within most organizations that put a large amount of drag on what should otherwise be a simple process of wiring together existing Web services and pushing the results out as an Ajax app accessible with a simple URL.  In fact, these forces are preventing organizations from taking the mashup phenomenon and replicating the same speed, success, and rough-and-ready results within their walls. 

And it's not the tools or the developers.  There are some absolutely terrific tools for doing all of this today including TIBCO's General Interface, Bindows (a great Windows-quality Ajax framework complete with a SOAP stack), or even the latest version of Ning which just came out today (which I'll do a tour of here soon).  And most enterprise developers these days are at least conversant with Web services and XML, if not more sophisticated than their Web counterparts who generally use simpler techniques. 

No, the barriers are generally somewhere else and collect around the classically hard issues that have been impeding SOA and EAI all along.  Here's a good start on what's holding back RIAs from the vision they offer:  Quickly and cheaply creating and injecting rich, SOA-enabled applications into the browser of any user that needs it.  This vision is something increasingly called the SOA/Client:

Common Obstacles to SOA/Client

• Lack of Web services or SOA: Like Joe McKendrick observed yesterday, Web services adoption is actually still in the early stages for many organizations.  Don't have lots of good Web services?  Then building Ajax apps is much harder because they require capable back-end services to do useful work on your behalf.  If you can't just wire together a bunch of existing services, but have to create them too, possibly over your complex legacy systems, then the ROI advantage begins to diminish.  This is the tipping point problem that SOA experts always talk about.
• Governance Constraints:  That fact is, reusing Web services inside your organization isn't anything like plugging into some Web services you happened to find out on the Web.  Political and organizational forces are much different than on the free-wheeling Internet and folks offering Web services from their part of the organization typically can't support the same kind of unlimited sharing.  Whether that's from licensing or IP restrictions, scalability limitations on bandwidth/hardware, sensitivity of information, or other constraints, you will typically run into a surprisingly amount of impedence to service reuse and integration within your RIA SOA/Client.
• Tools and Practices Are Little Known:  While it will almost certainly turn into best practice, RIA SOA/Clients are still a relatively new idea with immature tools and techniques.  Most of us are familiar with the saying that the "pioneers are the ones with the arrows sticking out of them."  Ajax is just getting widespread on the Web, never mind within your organization.  It's still a high risk endeavor even with the solid tools out there today; you will run into the usual early adoption problems, though the returns could still easily overpower any downside.  Don't forget, developing this way is lightweight, easy, and course-correctable.  That's why it's so popular.
• Disconnects between heavyweight SOA and lightweight services:  The big WS-* stacks don't play well with SOA/Clients.  Products like Microsoft's Atlas will provide bridges between these worlds but that also causes problems.  The chances are good that if you have a well-designed SOA in the advanced stages of deployment that your SOA services are not accessible via your RIA.  Specifically design your SOA for this, even if you have to provide a limited level of service for SOA/Clients.

So what do you do today?  Of course, the early-adopters of SOA and Web services are clearly the ones well-positioned to take advantage of the benefits of RIA SOA/Clients and that's part of the message.  Once you've built a SOA, there are numerous second-order benefits such as dynamic business process definition, business activity monitoring (BAM), and all the other buzzphrases.  For now, all I can suggest is taking the first step, build some SOA/Clients, and find out what you don't know.

The convergence of SOA/Client and Web application mashups (WAMs) will be complete soon enough with the same tools developing both (TIBCO being the exemplar here.)  Organizations will continue to get smarter about sharing services across internal boundaries when the advantages become increasingly clear and more accessible.  And your architects, developers, and users will continue to get many of their skills and ideas in this space from out on the Web.  That's not to say that mashups don't have their own unique set of challenges, as Peter Rip so eloquently wrote about today.

Is this for real?  Are you looking at the benefits of RIA SOA/Client?