Why Use Service Oriented Architecture

Why use a ServiceOrientedArchitecture? What do you gain, what are the costs?

This page grew from my concern that SOA is being used inappropriately. While it offers a lot for integrating "your stuff" with "other company's stuff", there seems to be considerable interest in using it internally - i.e. between apps or tiers developed by the same company. I don't think that's appropriate, and so I've started this page to discuss the matter.

-- AnonymousDonor

One example: I was talking about integrating software I'd worked on with a system under development at another company. The developers at the other company said they preferred not to use web services to integrate with our stuff, but that they did use web services extensively within their own system. I couldn't help wondering if that was one reason for their slow progress.

I think one reason for using WebServices internally but not between organizations is that within the company there is less concern about security, and also there is a need to put learning into practice (e.g. how to make it perform, what change management procedures are appropriate, etc), so do it internally first. -- DavidLiu
Some organizations are very large - there may be more differences between divisions of the same company than between two separate organizations. -- DavidAllsopp

Benefits

A great way to integrate with systems that you do not control. (I.e. to provide services for other organizations to consume, or to consume services supplied by other organizations.)
The ?only practical way to enable BestOfBreed delivery of Computing resources to consumers.
A high level of BuzzwordCompliance?

How about flexibility? By providing information or resources as a service, you avoid hardwiring systems together to meet immediate needs. When new, unexpected people need that service, it's easier to achieve. -- DavidAllsopp

Costs

Do SOA systems take more effort to develop? I suspect they must. See:

Some points for consideration, implied by the above...

(1) Firstly, even if you don't use SOA, a good architecture will typically follow many of the same principles. In particular, stateless servers. So while alternative technologies, such as DotNetRemoting, let you do all kinds of fancy stuff with stateful servers, you probably shouldn't. (See http://www.thinktecture.com/Resources/RemotingFAQ/RemotingUseCases.html) So, some of the fundamental principles are the same, regardless of whether or not you use SOA.

Nevertheless, SOA is not the only way to put those principles into practice. Between tiers of the same application, it's arguably not even the best way to put them into practice.

(2) SOA suggests that your server should assume nothing about the client. Therefore, you need to consider:

- Security. The server cannot trust the client, and therefore should perform authentication and authorization in response to every request received from the client. (Personally, I prefer to do this anyway, even when using alternatives to SOA, such as .NET Remoting.)

- The structure of the objects/XML messages that are passed between client and server. While a non-SOA solution, such as .NET remoting, lets you pass all kinds of complex objects (by value) between the client and server, with SOA you pass XML messages. Furthermore, are there any restrictions on the nature of your XML messages? For instance, passing .NET Datasets over web services is possible, but the XML is complicated. Is it realistic to assume that a non-.NET client can parse it?

- The validity of those objects/messages. I.e. your server cannot assume that the client has performed any particular data validation. In reality, the client probably has performed some validation, but the server can't really make many assumptions about it.

- Versioning. Techniques like .NET remoting automatically check that the client and server versions are in sync. With SOA the client and server may evolve separately and you, the developer, must assume much greater responsibility for that. You must either make sure your server can handle various versions of the client(s), or at least detect cases where an incompatible client tries to connect.

So, if you were going to run tight server-side security anyway, if your objects/messages are simple enough, if re-validating the data on the server is OK, and if you're prepared to take more responsibility regarding versioning - then I guess using SOA "between tiers" might be OK.

To me though, it still doesn't seem quite right.

NotQuickQuestions

Before we ask the question WhyUseServiceOrientedArchitecture, shouldn't we all know what distinguishes a ServiceOrientedArchitecture from other architectures? The ServiceOrientedArchitecture page doesn't make this clear at all. <- PleaseComment

You can always read the various links in that page, and then you will find AnythingGoes :) Seriously, I think of SOA as a way of constructing applications where one view interfaces (and their evolution over time) to be THE requirement, not end-users. Sort of like ComComponents at a different level of granularity. I am setting myself to be corrected on purpose here. -- DavidLiu

Many months later, I am going to restate the rationale behind the WhyUseServiceOrientedArchitecture - simply because :

Our users want to have the benefits of DistributedSystem (heterogeneous on-demand composable services) without the costs of DistributedObjects.
- see how MicrosoftWay is getting better (even WindowsCommunicationFoundation is a learning tool) at http://pluralsight.com/blogs/johncj/archive/2005/08/04/13855.aspx
more discussions at SoaAndLooseCoupling, but be aware of problems of SoaSystemsManagement
But ask: whether CulturalReadiness exist at your organization? There are two major SocialDynamics related issues that will derail any SOA implementation projects, do IT staff care?

The more things change ...

Having written a truckload of EDI code and having designed (and written) entire EDI/ETL systems, my first response is that the emperor has no clothes.

The emperor has lots of overhead, however.

SOA allows you to use somebody else's tool instead of writing your own, adopting the baggage that goes with the generalization, with plenty of YAGNI penalty weight, "because it's a standard."

We're going through this horror where I work even now. We have installations with thousands of units reporting, in near RealTime, to a central system with seriously interactive requirements. We have traditionally used a very terse messaging format in a lightweight protocol - bandwidth is precious - and done very well, thank you.

Now, we are in danger of death by ConventionalWisdom, as pointy-haired buzzword advocates wave the "standards" banner in our direction. Gotta use XML, it's the NextBigThing, and it integrates with SOA, and we can make our marketing reports talk to the electrician's priority list! Our personnel files will integrate with the customer issues list! We can all dance and nibble Lotus blossoms!

Down here in engineering, we are somewhat less enthusiastic. We are, even now, designing (quietly) the alternative methods. We've crafted a revision to the protocols that will, if it comes to that, be able to carry the load. We've developed a compression system that will lighten the load on the copper to the floor and prevent meltdown. And while this goes on we still appeal to the reason of those who would dress the emperor.

When execution time and bandwidth are not your primary concerns, maybe SOA is convenient enough to merit employment. When microseconds count and resources are thin, it's the wrong answer.

-- GarryHamilton

Hand designing protocols, designing an compression system? Sometimes necessary, sometimes not. XML is not evil, nor is it "slow". Bandwidth is not THAT precious unless you're in a real NarrowBand? environment or you have extremely high volumes. Obviously if your system works well today, why fix it? Is there a maintenance challenge? An integration challenge? If people are just applying SOA and XML without a business need, then the emperor in your organization has no clothes.

SOA, on the other hand, can have clothes, if there's a business need. Your complaints seem less targeted towards SOA and more targeted towards the problems of DistributedSystems in general. This is all true of course, if your architects and engineers don't "get" distribution and its risks like latency, partial failure, concurrency, etc., your SOA will not work. But this is not a reason to trample on the concept of SOA itself. I would be more concerned with your IT management's desire to be run by buzzwords instead of business needs. -- StuCharlton

Quest for the NextBigThing remain the same

Large armies of current and future computer professionals have vested interests in progressing current hypes of our technology driven industry. From major vendors who sponsor standards setting committees, down to the humble student starting their first course in computers. People have to innovate as otherwise there would be "diminished financial opportunities", to put it mildly.

And there are instances where material achievements and breakthroughs are made, e.g. the WorldWideWeb.

The rest of us are driven by fear.

To stay in the game of this industry, we keep to keep learning, just like a fish needs to keep swimming. Otherwise we (or our managers) become too expensive and therefore obsolete.

SoaIsNightSky. It is dark around us now. But just wait for the fireworks.

A matter of BusinessValue

According to RogerSessions in a mid 2004 newsletter, "SOA: WhyBother", it comes down to the value of integrating information, and the reduced costs of an SOA approach to fulfilment. He has, however, also outlined a few areas where implementers have been surprised by how practices need to be changed (e.g. error handling) in an SOA world. See http://www.objectwatch.com/newsletters/newsletter047.pdf

Viewpoint from Consultants that your CIO relies on

Gartner ShiftingGears?

"Despite the current disillusionment with SOA..." See http://blogs.zdnet.com/service-oriented/index.php?p=402

Since I am not amongst the privileged few to have access to reports from this firm, I can only find out what is cooking thru the peek-holes. Having said this, that blog did quote the word "despite".

So what kind of secure yet open architecture to build? Or should we forget about SoapProtocol based WebServices? And can we really forget about this because we are reliant on vendors for products that make EnterpriseApplicationIntegration possible?''

ZapThink? specializes in SOA and WebServices

The page has been deleted from this site, but there are lots of BackLinks. It may be worthwhile to use their viewpoint as a starting point to examine your options.

Do we have a choice?

If you work in a reasonably large organization, there is a lot of packaged software that keep the IT division at float. These tools are not easily replaced and IT Management do not have a choice but to follow the vendor's upgrade strategy. And new versions of most software packages are laden with WebServices. These provide opportunities for programming staff to create new services. You get the picture.

CategorySoa