Service-oriented architecture (SOA) implementations are falling into three distinctly different development approaches, says John Michelsen, chief scientist and co-founder of iTKO Inc., a testing vendor focused on service-oriented architecture.
Added to what might be called the orthodox SOA approach based on Web services and the WS-* standards, he is seeing two other approaches emerge, large enterprise implementations that make use of installed messaging middleware and may not use Web services and departmental implementations experimenting with REST and Web 2.0.
"Those are the three ways I've seen people rolling out SOA and all three have merit," says Michelsen, who is something of a neutral observer since all approaches require the testing tools, which he's been developing since 1999, when his focus was on what then was called the composite application test space. Since 2003, his attention has been fixed on SOA.
The major trend Michelsen says he is now seeing is that SOA is moving beyond Web services.
"Many people say let's go SOA and they immediately make the association with Web services and make the association from there to WS standards," he says. "So SOA basically becomes a WS-* type Web services gig. The approach is build a center of excellence, define WS-* standards, start with policy, bring in a registry. Let's go the Gartner prescribed way to SOA."
While he finds there is "a fair amount" of that orthodox approach to SOA, the alternatives are increasingly capturing his attention.
"There are certainly trends where SOA and Web services are not synonyms," Michelsen says. "SOA is an architectural pattern and you can do it in any number of ways. There's plenty of SOA going on outside Web services and the WS-* standards."
Larger enterprises appear more dedicated to the SOA tenant that prescribes reuse of technology that is already in-house, even if it is not state-of-the-art, as in the case of CORBA.
"A lot of the largest, most interesting SOA environments I've seen at large companies are not Web services based at all," Michelsen says. "They might be CORBA-based, or ESB-based. They might be some custom framework that's been built that sits on top of standard app servers."
Keeping existing IT infrastructure is key to the SOA philosophy, Michelsen contends.
"SOA can't be revolutionary because by its nature it has got to encapsulate and extend what's already there, so you can't really throw out the old stuff, bring in new stuff and somehow make an SOA easily," he argues.
For the company that has a long-term investment in something like IBM MQ Series middleware, he recommends working with what you've got and moving to a service-oriented approach from there.
"Let's say that the majority of your mission critical apps are Tibco or they are already running on IBM MQ. Let's start from there and go services-based from there. I like that approach," Michelson says. "Where a company has done well with a particular distributed middleware technology already, it makes sense to keep leveraging that and to build services in that particular technology. If they already had experience with ESBs and what they need to do is rethink the software design to get more service-based, but use the same commodity middleware, let's do part of what we're already good at and make this an evolutionary thing, not a revolutionary thing."
But while he says building on existing technology and expertise is his favorite approach to SOA, he is also seeing some intriguing work being done on the cutting edge of Web 2.0 and REST. He has doubts about how the Web 2.0/REST approach will scale, but he sees it as a good place for departmental IT to begin an SOA journey.
"There is a lot of ground-up SOA being done in Web 2.0 and REST," he said. "I think it's got legs at a departmental level. I think there are some challenges that the REST guys are going to have when they try to go enterprise-wide. It's good to have a rapid application development environment, especially if you're building front ends with the ability to collaborate lots of services from disparate providers. Web 2.0/REST approach is certainly handy for that."
From the perspective of a test tool developer who believes in governance, Michelson said, he is yet to see how standards-based governance technology and practices are going to work with Web 2.0 and REST as it moves from a department into the enterprise.
"With enterprise-wide reuse, the level of chaos that could be introduced by going purely RESTful in the services side might be dangerous," he cautions. "I've yet to see someone go widely distributed, enterprise-wide on REST. I have a feeling that's because it doesn't provide for any real way to standardize."
But if developers do not overreach, REST and Web 2.0 is "a great approach" at the departmental level, he says, and he finds a growing interest and excitement about going RESTful.
"There's been an enormous swell of RESTful stuff," he says. " Ruby on Rails, Google's platform, there's some great Web 2.0/REST-type stuff that's coming out."