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.
We’ve got a new reader contest at SearchSOA.com. It involves the very thing our readers tell us they most want to hear, yet it’s what they least want to talk about.
It’s worst practices, which are always fascinating when it’s someone other than you. We love other peoples’ pain … our own, not so much. Yet the demand is such that we figure some of you out there are willing to sound a warning for your colleagues out there. Users are hitting the majority adoption phase of SOA and they’re rightfully nervous about the potential pitfalls. Plus we figure part of the tale has to be how you corrected the mistake since people normally fix a mistake once they realize they’ve made one. Mac Daddy and Daddy Mac from Kris Kross don’t still wear they’re clothes backwards.
Anyway, for those interested, here are the contest details. Winners will get a free copy of SOA: Principles of Service Design by SOA guru and SearchSOA.com site expert Thomas Erl.
It is common for small and midsize business to wait out technology bubbles. If a hot new technology bursts onto the scene, the SMBs don’t immediately adopt it. Expensive and unproven technologies aren’t usually their cup of tea. It’s a sensible approach that keeps IT from being too much of a cost center for users who don’t have a ton of cash to spare.
Yet, as we all repeatedly hear, service-oriented architecture isn’t a technology. Rather it’s an approach to using technology and, like Jennifer Lopez’s love, that don’t cost a thing. Service orientation is an approach toward business that has been around for decades and embodied in things like ITIL. Enterprise architecture is a discipline. On the face of it, SOA requires nothing an SMB can’t do.
A while back, I spoke with Sandy Carter, IBM’s vice president for SOA and WebSphere strategy, about SMB adoption and she noted that three quarters of mid-market companies are using Web services and that “I’ve never seen this fast of an uptick for a technology in the SMB customer base.”
Carter then caught herself and added, “Well, we don’t consider SOA just a technology and maybe that’s the reason for the uptick.”
She noted that service orientation was allowing SMBs to create value added services and to connect to larger trading partners and markets with a minimum of custom work involved. The thing those sorts of projects have in common is they’re revenue generators. Carter said that while larger companies are often focused on cost cutting (viewing IT as a cost center), SMBs who’ve entered the arena seem to view SOA as a way of running IT as a profit center.
Ask anyone what the ideal startup project for an SOA should be and you’ll almost invariably hear the answer that it should be tied to a revenue stream in order to provide the necessary ROI for the work involved. It should be the first step in a strategic plan, but tied to a tactical business opportunity. Could it be that SMB’s fundamentally understand SOA better than some of their supersized counterparts?
Carter pointed to some other advantages SMBs might have in this area.
- “Because there are fewer business and IT people involved, they can align faster. Often the CFO has business and IT reporting directly.”
- “Big companies have significant governance issues. SMBs can be focused on targeted processes, not fixing overall categories.”
- “In a smaller business, people often wear multiple hats. They have a broader view of the business than just what they do.”
Gary Grandlienard, director of enterprise architecture for Railinc Corp., a $51 million rail industry information services business based in Cary, N.C., agreed with Carter’s take that SMBs have decided advantages over large companies when it comes to SOA.
- “I’m able to work directly with the project teams and that ensures there’s consistency in the tools they’re using.”
- “It’s a lot easier to educate everyone involved, executives and developers, about what we’re trying to achieve with SOA. It’s much easier for us to communicate with one another.”
- “A lot of our apps were using the same information, but we were still building stovepipes. The truth is we’re too small to not be sharing this information across our application portfolio. The problem isn’t so big that we can’t get our arms around it.”
- “One of the reasons we’ve been able to sell SOA is because it’s part of our data quality initiative. It’s tied to our core business.”
- “We meet weekly with our application architects to make sure they think interface first. We can do follow up at the enterprise level.”
Smaller scale has its advantages, particularly when it comes to governance. The enterprise architect can work directly with the project teams and report directly to the executives. While a lot of SMBs may lack the confidence to try a full bore SOA implementation, here’s a guess that in the coming years many of the leading SOA success stories will be coming from the SMB ranks. They can best see a targeted three- or five-year plan through to the end and they’ll probably realize SOA-related gains the quickest. In fact, expect a lot of larger companies to look at those SMB case studies and ask, “I wonder if that would scale for us?”
Michael Meehan, Site Editor, SearchSOA.com
Those of you who have been longtime SearchWebServices.com readers might have noted our recent name change to SearchSOA.com. The shift was inevitable and, being totally honest, we probably should have made the change a long time ago.
Certainly our coverage has been focused on service-oriented architecture since late 2004. Web services are an important adjunct to that, but we long ago devoted our resources to the big architectural picture rather than the integration plumbing issues in this area. In essense, SearchSOA.com is a proper statement of who we are and who we’ve been for quite some time.
In terms of our topics of coverage, nothing is changing. In our taxonomy, we have broken down the SOA topic into four main areas — strategy, governance, infrastructure and data architecture — in order to make for better navigation of the site, but our writers have long been on top of those subjects. It should be noted that we fully intend to continue to cover Web services, standards and integration like we always have.
In terms of what to expect from the site, the answer is more. We’ll be adding numerous blogs beyond this one. We’ve got new lessons coming in our Service Orientation for Architects School. We’re going to be trotting more columns and a brand new bookshelf page along with reader quizzes and contests.
In other words, what you can expect from SearchSOA.com is what you got from SearchWebServices.com with the volume cranked to 11. We pride ourselves in being the top site on the Internet for independent coverage of SOA. That won’t change, we’re just upping the ante. Make sure to check in daily at the SearchSOA.com homepage because it will be constantly restocked with news you can’t afford not to use.
Michael Meehan, Site Editor, SearchSOA.com