SOA's six burning questions

1 2 Page 2
Page 2 of 2

"The SOA technology and approaches recently employed are largely untested with higher application and information and service management traffic loads," Linthicum writes. "SOA implementers were happy to get their solutions up and running, however in many cases scalability is simply not a consideration within the SOA, nor was load testing, or other performance fundamentals. We are seeing the results of this neglect now that SOA problem domains are exceeding the capacity of their architectures and the technology."

Linthicum recommends performance modeling and testing of real-life scenarios before putting an SOA into production. "You won't know how it will behave until you put it through its paces," he writes.

Linthicum also recommends improving performance by adding processing power at the origin of each SOA service.

There is always room for "more network," Fulton notes.

"I can always build a system that performs better if I'm willing to send out binary data and not have something that has to be parsed the way XML does," Fulton says. "But can I build it as fast and modify it as quickly? We're always asking the hardware and operating systems and the layers on top to support higher and higher levels of abstraction. ... Is it more efficient to do it a harder way? But how many CPUs are less than a gigahertz today? Not many. We let the computer do some work for us again and again through the life span of the application just so we can get it built quicker."

5. Do security requirements change when an IT department uses SOA?

At Avis Budget, IT executives thought security was a peripheral concern when SOA efforts began. Now it's become one of the most pressing issues they must address.
Using SOA has opened new channels with business partners, and Avis must make sure sensitive data like driver's license and credit card information is encrypted inside databases and in transit.

"You'll have queues, you'll have databases, you're going to have channels. So we're trying to go for secure all the way through," Kumar says. "You are creating a more distributed environment. From a security point of view, it becomes harder to manage. You have many more components that are part of it, versus a more centralized mainframe base where you have one place to go."

Identity management is one of the key challenges IT managers have to address with SOA.

"When you have a SOA environment, the same business service may be used in 10 different ways," Hurwitz says. "You have to make sure you have a security structure in place that says who's allowed to access what in what circumstances. ... It becomes more complicated. The risks in some ways get higher because you're reusing a lot of services and you have to make sure you have the right level of security on top of that."

Traditional application security is "ineffective and unwieldy in a SOA" because identity and access rights -- including passwords and privileges -- vary widely among applications, Saugatuck Technology's West wrote in a research paper released last year.

Single sign-on has not proved scalable in large organizations and is complicated by privacy and competitive issues when applied to SOA environments that range across business partners, West wrote.

Less problematic is a federated identity management approach that works by trusting the source of assertions and uses Security Assertion Markup Language. Requests for access control information can be coded in browser requests or included in Web services transactions, West wrote.

"In this way, an identity management server produces assertions about the identity and rights of users that an application responds to," West said. "An application, a service or a 'wrapped' services interface wouldn't need to have access to a directory or trust an individual user, because it only needs to know and trust the assertion and the assertion's source."

West portrays the IT perimeter as a "porous membrane" allowing data transport among a wide variety of business partners, customers and nonemployees. SOA, he says, carries its own unique vulnerabilities that require adequate management on multiple fronts within the enterprise and in dealings with vendors.

A more optimistic view can be found with Mengerink, who says security actually becomes easier after an SOA is deployed. But that's compared with the enormous task PayPal is faced with when securing payments on the Web. PayPal's SOA is provided solely for developers, Mengerink notes.

"The number of attack surfaces we have on a Web page is just enormous," he says. "Now if you say, 'All you can do is you have to register with us and I have your names, I know who you are, and I've got to give you a special token before you're allowed to talk to me,' that's a very narrow channel of people. That's a much easier problem for us than everyone on the planet can go to www.PayPal.com and start attacking."

6. What are SOA's dark sides?

Security is clearly posing a challenge to at least some IT executives deploying SOA, but it's not the only dark side you'll find when building a service-oriented architecture. One of the "dark underbellies" of SOA, according to Fulton, is the challenge of providing a unified view of data and access to data across multiple business services.

Reusing old software for new business processes is great, but it exposes an Achilles heel of most enterprises: Their customer data has evolved over time.

Offering an example, Fulton notes that five years ago, cable companies thought of a customer as a person who lives in an apartment or house where he receives a bill. "Today, you probably [say] a customer is someone who receives a bill for multiple premises, potentially. That's a small change, but the old applications can't do that. ... So all building blocks of services can be manipulated to do things quickly, [but] you have to figure out how to unify the data. People are still struggling with that," he explains.

There are probably 15 vendors that offer a solid ESB, but industry efforts in managing data are less mature, Fulton says.

The challenge of securing the cash to fund new SOA projects is another potential downside. Even though SOA can save businesses money in the long run, Kumar says, it's difficult to persuade the people who control the purse strings to look to the future.

"You have this whole establishment that's based on project-based funding. Every project has to justify its own ROI," he says. "We are getting traction at it now, but it still is a challenge to teach finance people to look beyond just single projects."

Hurwitz claims that the dark side of SOA is "never about the technology." It's the people developing the technology that cause problems, she says, particularly when they don't collaborate with people on the business side of the house or think about what services the business really needs.

"You go out and create 10,000 business services, well, they're way too granular and it's hard to access them," Hurwitz says. "And it's not going to help you much. The dark side is not doing it right."

Fulton says there are fewer "dark sides" than there are "impacts" with SOA. One impact is the need to buy technology to support SOA, and the confusion that can result when one realizes just how many products there are to choose from.

"There's ESBs, there's SOA management products, there's products for managing Web services, there's hardware acceleration devices for Web services, there's gateways and you name it," Fulton says. "The question is, 'What do I really need?' And of course the true answer is, 'It depends.' But a lot of people are saying, 'Tell me everything I need to buy so I can get SOA off the ground.' Well, that's probably a very bad way to approach it, because you can end up spending money for things you're not going to take full advantage of."

This story, "SOA's six burning questions" was originally published by Network World.

Copyright © 2007 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2
  
Shop Tech Products at Amazon