Service oriented architecture (SOA) is an architecture where independent

systems and applications communicate with each other by exposing and using
services. Services are defined using open standards, making intercommunication much easier to implement, and less dependent on proprietary
communication protocols.

From DOA to SOA

SOA follows the idea of a Distributed Object Architecture (DOA) where objects
in applications could move around freely between servers and call each other
remotely etc. The idea was that an object calling another object should not
have to know whether the called object was residing locally, or remotely. This
should be transparent to the calling object.
This architecture is slowly being abandoned, as too fine grained distributed
object communication is both very complex, and does not perform well.
Distributed objects are complex because there are more error possibilities
when calling a remote object, than when calling a local. For instance, you
typically need two phase commit transactions to coordinate a distributed
transaction, where a single phase transaction may do locally.
Additionally, you had less control over the communication overhead incurred
from unnecessary out-of-process communication, and from moving objects
between "containers" or "servers" behind your back. Thus application
designers wanted to be able to control location of objects, to lower complexity
and increase performance.

A distributed object architecture.

Instead larger grained less mobile services have been introduced - SOA.
Service can move, but they typically do not move as dynamically as people
imagined distributed objects would. Additionally, when you call a service you
are typically aware that you are calling a remote entity. This means that you
have better control of both complexity and performance.

A service oriented architecture.

Some people sarcastically say that SOA stands for "Same Old Architecture" which is actually not that far from the truth. Todays services are strikingly alike
yesterdays remote procedure call protocols. The main difference is that today
services are more and more communicating via open standards, like SOAP,

REST etc. meaning the communication layer becomes easier to implement.

SOA is not, however, the big increaser of "Return on Investment" as some
authors wants you to believe.
Another difference is that SOA introduces a set of new concepts, and attempts
to standardize some existing concepts across the industry. Some of these
concepts are:

Enterprise Service Bus

Service Composition

Service Transactions

Service Repositories

Service Orchestration

Services vs. Applications

When you start learning about service oriented architecture you might wonder,
what the difference is between a service and an application.
There are no precise definitions of a service or an application. Services and
applications are both software programs, but they do tend to have some
differing traits. I have summed up the most common traits in the table below:

Services

Applications

Perform a single or a few

specialized operations.

Perform a wide range of operations,

and may even expose some of these
operations as services.

Most often accessed by

other programs.

Often (but not always) accessed by

humans.

Often (but not always)

targets part of a larger
problem domain.

Often (but not always) targets a whole

problem domain.

Services often target smaller and more isolated problems than applications.
Applications often expose and call services, sometimes services in other
applications. It's hard to get more concrete than this. Here is an example of
why:
A mail server (as software) can be thought of as both a service and an
application. It runs on some server (hardware) somewhere on the network. It
exposes 2-3 primary services: An SMTP service used to send email, and a
POP3 and an IMAP service to read email via. The mail server may not have a
user GUI that the users can interact with. They might just use some standard
email clients.
The mail server may had an administrator GUI though. But there is no
guarantee. The mail server could also just be configured via configuration
files.
The reason I would still call a mail server an application is that it exposes 2-3
services, is intended to be used by end users (though via some client
applications), and it targets a whole problem domain. But really, you might as
well call it a "mail service". The border between services and applications is
unclear.
Here is an illustration of the mail server example:

Enterprise Service Bus (ESB)

Table of Contents

ESB Basics

ESB as Single Point of Access

ESB as Transaction Manager

ESB as Security Manager

ESB as Service Proxy

ESB as Gateway to the World

ESB Disadvantages

An "Enterprise Service Bus" (ESB) is a system to which all services are

connected. Through the enterprise service bus all connected services can
also be accessed. Here is an illustration of an enterprise service bus which
acts as central "bridge" or "gateway" to all applications exposing services
underneath it:

ESB Basics
The term "bus" is an analogy to the internal bus of a computer onto which the
CPU, RAM and other chips are connected. An enterprise service bus is
typically implemented as a server or a set of servers, and is thus more than
just a "network".

An enterprise service bus with applications

(services) connected

Clients and services connected to an enterprise service bus do not

communicate directly. They communicate via the ESB. This is done by having
the ESB essentially expose the same service interface to potential clients, that
the connected services expose to the ESB. This indirection via the ESB has
some advantages and disadvantages, which I will cover in the rest of this text.

ESB as Single Point of Access

One advantage of connecting clients and services via an enterprise service
bus is that clients need only look for services in a single location: The
enterprise service bus. If a service is moved from one server to another, you
only need to reconfigure the ESB. The clients still just access the service via
the ESB.

ESB as Transaction Manager

Another advantage is that the ESB can coordinate distributed transactions
which multiple services participate in. When multiple distributed services need
to participate in a transaction some entity typically has to coordinate the
transaction. Rather than forcing the client to do this, the enterprise service bus
can do so. The client may still have to demarcate the beginning and end of the
transaction, even if the work of coordinating the participants is done by the
ESB.

An enterprise service bus (ESB) managing a transaction

spanning three services

ESB as Security Manager

Security aspects like authentication and authorization can be centralized in the
enterprise service bus. Even if a service in an application does not have

authentication and authorization, the enterprise service bus can require this in
the service interface it exposes to potential clients.

An enterprise service bus (ESB) authenticating and authorizing the client

before forwarding service requests to services.

ESB as Service Proxy

An ESB may function as a gateway or proxy for appliations that do not expose
a standardized service interface to the world. For instance, lets say an
application exposes a Java RMI service. The rest of your network is running
on .NET which cannot directly call the RMI service.
To solve this problem you can implement a service proxy in Java which can
call the RMI service. The service proxy then exposes a web service interface
(SOAP + WSDL) via the ESB to the .NET applications.

Such a proxy service does not have to be a built-in capability of an ESB. It can
also just be deployed as a separate service, made available via the ESB.

An enterprise service bus (ESB) as service proxy for a service

with a proprietary protocol.

ESB as Gateway to the World

If some clients need to connect to services running in the outside world, the
ESB can potentially function as a gateway to the world outside. Again, security
aspects etc. can be added ontop of the external service. Furthermore, if the
external service is capable of participating in distributed transactions, the ESB
can coordinate this too.

An enterprise service bus (ESB) as gateway to the world.

ESB Disadvantages
Connecting your services via an ESB also has a few disadvantages. First of
all the ESB may become a single point of failure. If the ESB is down, no
communication between clients and services can take place. Second, the
extra level of indirection may result in decreased performance of client-service
communication.

A mail server (application) exposing 4

different services.