What is SOA “in plain english”? [closed]

Answer 1

You might find this article (What is SOA? - SOA and Web Services Explained ) helpful.

A little teaser:

• SOA is a style of architecting applications in such a way that they are composed of discrete software agents that have simple, well defined interfaces and are orchestrated through a loose coupling to perform a required function.

• There are 2 roles in SOA- a service provider and a service consumer. A software agent may play both roles. SOA is not an entirely new concept – however, this article mainly focuses on SOA as implemented with web services.

Answer 2

SOA is an architectural style but also a vision on how heterogeneous application should be developped and integrated. The main purpose of SOA is to shift away from monolithic applications and have instead a set of reusable services that can be composed to build applications.

IMHO, SOA makes sense only at the enterprise-level, and means nothing for a single application.

In many enterprise, each department had its own set of enterprise applications which implied

1. Similar feature were implemented several times

2. Data (e.g. customer or employee data) need to be shared between several applications

3. Applications were department-centric.

With SOA, the idea is to have reusable services be made available enterprise-wide, so that application can be built and composed out of them. The promise of SOA are

1. No need to reimplement similar features over and over (e.g. provide a customer or employee service)

2. Facilitates integration of applications together and the access to common data or features

3. Enterprise-centric development effort.

The SOA vision requires an technological shift as well as an organizational shift. Whereas it solves some problem, it also introduces other, for instance security is much harder with SOA that with monolithic application. Therefore SOA is subject to discussion on whether it works or not.

This is the 1000ft view of SOA. It however doesn't stop here. There are other concepts complementing SOA such as business process orchestration (BPM), enterprise service bus (ESB), complex event processing (CEP), etc. They all tackle the problem of IT/business alignement, that is, how to have the IT be able to support the business effectively.

Answer 3

A traditional application architecture is:

• A user interface
• Undefined stuff (implementation) that's encapsulated/hidden behind the user interface

If you want to access the data programmatically, you might need to resort to screen-scraping.

SOA seems to me to be an architecture which focus on exposing machine-readable data and/or APIs, instead of on exposing UIs.

Answer 4

I would suggest you read articles by Thomas Erl and Roger Sessions, this will give you a firm handle on what SOA is all about. These are also good resources, look at the SOA explained for your boss one for a layman explanation

Building a SOA

SOA Design Pattern

Achieving integrity in a SOA

Why your SOA should be like a VW Beetle

SOA explained for your boss

WCF Service Performance

Answer 5

Well You see.. SOA stands for Service Oriented Architecture.... In simplest words, you write a piece of code that is very generic i.e. it does some thing that can be used in a lot of applications ... may be something like a address book or may be a calculator. and you launch this code on the IIS. So you provide a service through your code. So you are a service provider. Now someone wants to use a similar code then he does not have to write the code again. He simply uses your code maybe through a web service. Hence he becomes a service consumer. Hence making a program using such services is called SOA. And the loose coupling is there as the service provider and consumer may be interacting even if they are using diff programming languages. Hope you understand.

Answer 6

from ittoolbox blogs.

The following outlines the similarities and differences to past design techniques:

• SOA versus Structured Programming o Similarities: Most similar to subroutine calls where parameters are passed and the operation of the function is abstracted from the caller - e.g. CICS link and execute and the COBOL CALL reserved word. Copybooks are used to define data structure which is typically defined as an XML schema for services. o Differences: SOA is loosely coupled implying changes to a service have less impact to the consumer (the "calling" program) and services are interoperable across languages and platforms.

• SOA versus OOA/OOD o Similarities: Encapsulation, Abstraction and Defined Interfaces o Differences: SOA is loosely coupled with no class hierarchy or inheritance, Low-level abstractions - class level versus business service

• SOA versus legacy Component Based Development (CBD) - e.g. CORBA, DCOM, EJB o Similarities: Reuse through assembling components, Interfaces, Remote calls o Differences: Wide adoption of standards, XML Schemas vs. Marshaled Objects, Service Orchestration, Designing for reuse is easier, services are business focused vs. IT focused, business services are course grained (broad in scope)

• SOA (for integration) versus Enterprise Application Integration (EAI) o Similarities: Best practices (well defined interfaces, standardized schemas, event driven architecture), reusable interfaces, common schemas o Differences: Standards, adoption, and improved tools