Service Oriented Architecture: How would you define it

Question

Service Oriented Architecture seems to be more and more of a hot quote these days, but after asking around the office I have found that I seem to get many different definitions for it. How would you guys define SOA? What would you consider the official definition?

Answer 1

An SOA design includes components (i.e., services) that can be used by code regardless of implementation (i.e., any OS or langauge). A single instance of a service may also be used by multiple applications, whereas, e.g., a DLL would have to be duplicated for each app and require the same implementation technology as the linking application.

Services in an SOA design are usually implemented as interoperable web services.

Answer 2

As Martin Fowler says, it means different things to different people. His article on the topic is pretty good although it isn't quite a definition.

http://martinfowler.com/bliki/ServiceOrientedAmbiguity.html

It may explain, the difficulty coming up with a concrete definition.

Answer 3

I'd go with:

Defining a series of stateless, client agnostic business operations created to be leveraged in multiple applications.

Answer 4

How would you guys define SOA?

A vague marketing term, on a fast train to the bustling burg of Meaninglessville. Used as a stand-in for more precise pattern names. See also: Web 2.0...

Answer 5

I attempted to define SOA in one of my blog posts. Here's an excerpt...

For years it's been standard practice to separate functionality into functions, classes, and modules. The idea has always been that these smaller, highly specialized components are easier to share and maintain than monolithic blocks of code.

Functionally, SOA is not much different. The goals are the same - reusability and easy maintenance. The biggest difference - in the case of a web service SOA - is that the shared library included in your application is replaced with an HTTP call.

Answer 6

There isn't an official definition as Ryan mentioned eariler. However, I find Thomas Erl's view of the whole service-orientation quite well-structured and relevant. Here is the definition of SOA from his SOA Glossary (more):

Service-oriented architecture represents an architectural model that aims to enhance the agility and cost-effectiveness of an enterprise while reducing the overall burden of IT on an organization.

Thomas Erl is the author of many SOA titles most of them receiving endorsement from SOA vendors including IBM, Oracle, and Microsoft. The nice thing about his books is that they are as SOA vendor independent as possible. It means you learn more about service-orientation itself and less about some vendor's middleware that supports SOA.

Answer 7

Wikipedia: "A SOA is a software architecture that uses loosely coupled software services to support the requirements of business processes and software users. Resources on a network in an SOA enviroment are made available as independent services that can be accessed without knowledge of their underlying platform implementation."

SOA is not that new, but it has potential to achieve some amazing things. But the organization has to be ready for it: the business has to think in processes and that's the big problem

Answer 8

I agree with all of the people that point you to Fowler on this. Basically it runs like this: service oriented architecture got a reputation as being good, so anything that people want to be associated with good they call SOA. In reality it has a lot of downsides and can create a Service Oriented Gridlock or Dependency Oriented Architecture.

Here's my go at a definition: Service Oriented Architecture is a systems integration and code reuse approach where applications are dependent on connecting to services provided by other running applications across the network. This is distinct from component architectures, where software components are shared statically between applications in the form of libraries or SDKs, for example.

Answer 9

A clarification here - "Service Oriented Architecture is a systems integration and code reuse approach where applications are dependent on connecting to services provided by other running applications across the network."

I have a scenario where two j2ee applications have been integrated using event driven messaging. Here the above phrases of systems integration and connecting to services provided by other running applications across the network hold good. Can i call this SOA ?

The following principles would hold good here 1) statelessness 2) message oriented - loosely coupled infact de-coupled 3) extensible.

However, the following do not apply 1) platform independence - neither of the applications being integrated has been designed to work in a different platform. 2) The applications are plain j2ee applications which have not been designed with all soa concepts.

Answer 10

Marketing Bullshit 2.0