Thursday, August 2, 2007

SOA as in Service Oriented Architechture

In the next few posts I will post few articles,excerpts from various sources reflecting my understandings on SOA.


While doing a reality check on SOA,I really found"6 burning questions on SOA" which was published on JavaWorld by Jon Brodkin. very useful


Here are the excerpts.

1. Is anyone saving (or making money) using SOA?


Ashok Kumar of Avis Budget Group says he is. Avis began using SOA about two years ago in portions of the company to open new channels with travel partners. “They can now do direct business with us without having to go through a middleman. So it’s saved them a couple bucks, saved us a couple of bucks,” says Kumar, who is based in New Jersey and is director of services architecture information technology. “The cost of bringing on new partners is down to nothing now because of SOA.”
Avis Budget can now bring on a new partner in a day instead of a month, he says, because with SOA it is just a matter of configuring a service rather than making large application changes. “When we started that the cost of bringing on a new partner was anywhere from $40,000 to $50,000, now it’s down to $3,000 or $4,000,” he says.


Traditional approaches to building software assume you start from scratch and develop something designed to solve a specific problem, Hurwitz notes. SOA allows businesses to be flexible and seamlessly react to major changes. A business might not see much benefit from SOA for months after deployment, but if it is suddenly involved in an acquisition “there’s a major change in their ability to cope with that change and react and then provide the software,” Hurwitz says.


2. Why is it so hard to find employees with SOA expertise?


The task of finding SOA experts is complicated by the fact that people in the IT world simply don’t agree on what SOA means, Mengerink says.
“You get one person coming in and saying ‘that means it’s a Microsoft service interface.’ Another guy comes in and says ‘no it’s an Apple widget.’ Well, which one is right? If you’re hiring and you say ‘I want an engineer, you could get anything,’” he says.

The best approach is to train your own people, Mengerink argues, because the concepts and technology that underlie SOA aren’t that complicated. Of course, this is easier if you happen to be implementing SOA at a large organization such as PayPal. “If you take a really large company, they’re sort of defining what SOA is,” Mengerink says. “Somebody who has the resources is the one who’s going to say to the world what it is.”
SOA requires a different mind-set than traditional approaches to building an IT infrastructure, Kumar says. Many people can program in Java and understand how to make a single Web service, but putting it all together in a services-oriented architecture is difficult, he notes. “A lot of people have a hard time making that leap, and that’s why we tend to go to outside service providers,” he says. “Even then, I think good talent is just hard to find.”


3. Has Microsoft gotten a clue about SOA?
“I’d say in fairness, Microsoft is getting a clue about SOA,” Fulton says. “Right now, their SOA strategy per se is a little mysterious; it’s a little harder to tease out. I think they have recognized it’s a significant force in the market.”


“Microsoft’s current story on ESB isn’t ‘hey, here’s out ESB product,’ but ‘you [the customer] can build an ESB … and you can use these products to do it.' They even talked about having accelerator packs that make it easier to build them on top of things like BizTalk.” Fulton says.
That would be Microsoft’s BizTalk Server, a business process management server that has tools to design, develop, deploy and manage a company’s business processes. Hurwitz describes the integration technologies in BizTalk as Microsoft’s “alternative’” to an enterprise service bus.

4. How does SOA affect network performance and management?

For all its benefits, you can bet SOA will saddle your network with increased requirements and complicate network management and operations, consultant David Jacobs writes in a paper for IT professionals.
Since each application in a SOA is composed of many individual software components, a failure anywhere in the network can bring down an application, he notes. Your own performance in monitoring the network and immediately responding to problems is thus even more important after an SOA is deployed
Data rates and the time required for each interchange between components are a factor in transaction rate -- but only one factor. Management software must be able to detect problems at the application level and then be able to drill down to find the root of the problem.

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

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.

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.”

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 they receive 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, you have to figure out how to unify the data. People are still struggling with that.”

2 comments:

Udayan said...

Another major issue is what should be the service granularity?

TW said...

Service granularity is usually dictated by the actual business.It means that along with the saying "Understand you business and you will understand granularity",developers and designer are expected to have the complete picture of the requirement.

Other factors which could decide the granularity could be

1)Overhead:-In terms of the number of calls made and the size of each messages.

2)State of transaction.:-Keeping the state open in between the operations as this would again increase the round trip calls.

3)Suitability:-Keeping it simple, will help in reducing calls made.