News

SOA Synergy and Obstacles

• By Kurt Mackie
• May 25, 2007

Lipton posed more questions than answers in his presentation on "The New SOA Synergy: How Runtime Governance, Triage and Security Must Work Together," which he delivered this week at Enterprise Architect Summit 2007. First, however, Lipton described SOA as an approach that's here to stay.

"It's pretty clear now that we've bought into SOA. It's really good 1980s thinking. There's really nothing new under the sun here," Lipton said. He added that there's no vendor out there that hasn't embraced XML standards, and the extensibility aspect of XML has really opened things up.

SOA is based on loose coupling and decreasing the dependencies between components. Having fewer dependencies is a good thing, Lipton said. However, there's a downside to loose coupling.

"There's a tremendous amount of complexity, and it's unpredictable," Lipton said. "There's a far greater rate of change and there are more people (such as nonprogrammers) who can make the change."

Problems With Reuse
Reuse of system resources is the primary justification for SOA, Lipton said. However, problems can arise as the number of users increase, leading to unexpected bottlenecks.

"The truth is, the more users there are of your service, there's extra complexity. You are going to have single points of failure that affect the whole organization," he said. "As new people reuse the service, do they go back and say, 'We're using this service?' Hey -- come on!"

Enterprise architects face other resource use problems. For example, it is possible to create a legitimate request that takes 10 times longer to parse, Lipton said.

"You don't need a denial-of-service attack [to slow your network]. Just create a legitimate request that's stupid," he said, emphasizing the need to have visibility into the pieces of your infrastructure.

"Do you really understand what applications are being used in an SOA -- at runtime, not governance? There are lots of considerations that go beyond governance," he said.

He also questioned how one can measure service level agreements in an environment that is distributed. In complex, heterogeneous environments, 99 percent availability isn't enough, he added.

"If you can't relate the performance of these applications back to the performance at the customer's level, you're going to have a customer that hates your application," he said. The reality is that you will need a transaction trace capability to manage service transaction flow, Lipton said.

In essence, having an SOA doesn't mean things will go smoothly.

"Loose coupling is going to be a two-edge sword," he said. "You'll have points of failure that will be more complex. It's going to be harder to trace business transactions. You're going to have more outside services that are hard to control."

Enterprise Service Bus
Lipton had lots of complaints about the enterprise service bus (ESB) component of an SOA. He suggested that the term had entered the SOA lexicon by analogy from PC-technology jargon.

"The bus is an important part of the PC," he said. "So, therefore, your SOA can't work without an ESB!"

Some say that an ESB in an SOA is a centralized place to put your policies. However, Lipton argued that ESBs are more like loose cannons in a SOA world.

"The problem I have with ESBs is that there is no standard for them. If you go to any [standards] group in this space (OASIS, etc.), you will not see a standard for ESB," he said. "An ESB works best when it's the only bus in town, but SOA has to work with multiple systems. It's important to think of ESBs as a piece of middleware you may not need. Each ESB considers itself the center of the universe. Once you have localized your security policy to one ESB, you've wrecked your SOA."

He added that all ESBs have different log file formats, "so if you get audited, are you going to get all of those log file formats? I don't think so," he said.

Governance
Lipton also focused on governance in an SOA, suggesting that "the industry has started to use the 'g' word somewhat obsessively."

SOA governance is usually focused on the development side, working with XML documents and code, he said.

"The [governance] products that work well integrate into the development platform (for example, Visual Studio, NetBeans, etc.). There is a policy effect to these governance tools. They tend to have a lot of scanning mechanisms. The best solutions tend to be the ones that understand both Java and COBOL code," Lipton explained.

People working with governance tend to focus on coding standards and metadata, Lipton said. The "runtime governance" phrase really is just a fancy way of saying "security," he added.