At the Ajax Experience in Boston last week, I caught a presentation by Joshua Gertzen, primary architect at ThinWire, called “Dodging the Pitfalls of Enterprise Ajax Applications”.
Gertzen and ThinWire came into the Ajax/RIA space through an interesting side door, working on desktop banking apps at an ISV called Custom Credit Systems Inc. So Gertzen’s perspective is that of a programmer with a business focus than one who likes to make pretty Web pages. In fact, he noted that the Web traditionally doesn’t handle data-centric applications very well, which is no small issue for those building data-heavy business apps.
Even more than that, he said that a serious financial application can have thousands of business rules attached to it (16,000 was his number of choice) and it can make for a presentation layer nightmare when it doesn’t understand a rule change. The degree of difficulty only rises when you add Ajax and Web services to the mix.
“All the new application endpoint handlers on the server could number in the hundreds,” Gertzen said.
Gertzen’s proposed solution is that logic and events should be handled on the server to allow full access to server resources and to make debugging easier. That will allow developers to create a tightly coupled Ajax/RIA interface that doesn’t get bogged down with too many rules.
Of course, since this is an SOA blog, I probably just hit a trip wire for many of you when I used the words “tightly coupled.” Aren’t we trying to get away from tight coupling? Well … yes … though obviously there comes a point where you have to implement and that may involve some tight coupling.
I caught up to Gertzen after his talk to bounce that very question off of him. What does the application architect need to consider when tying these rich interfaces to a Web service that may have shifting data sources and business rules? How do you rationalize the tight coupling of the interface with the loose coupling of the service?
Gertzen suggested having the server make a Web services call to itself to create a new, separate instance with which the interface can interact. That way state and change management don’t become rolling trouble spots.
Let’s take that ball and run with it. Say you’ve got an enterprise that runs a few hundred Web services inside its SOA and you want RIA interfaces for all of them. That would seem to be a real sweet spot for virtualization tools. You could make those new instances part of your overall SOA governance strategy (specifically in how you handle change management). It’s amazing how all of these hot, new areas in IT can potentially fit together. Whether virtualization will become the secret sauce in the RIA/Web services sandwich remains to be seen, but it certainly would seem a handy way of getting around the problem of tightly coupling an interface to a service that will not remain static.