SOA - Service Oriented Architecture http://www.ooxs.be/EN/architecture/SOA.

html

1. Introduction
1.1. Service
1.2. Web Service
1.2.1. Service Properties
1.2.2. Service and Transactions
1.3. SOA Example
1.3.1. Introduction
1.3.2. Service Consumer
1.3.3. Service Provider
1.3.4. Some Implementation Details
1.3.4.1. WS with Apache Axis
1.3.4.1.1. Providing the Service
1.3.4.1.2. Consuming the
Service

1. INTRODUCTION
When we talk about a service oriented architecture, most people think immediately about SOAP and webservices. However, the concept of a "service" can and should be
interpreted much more broadly.

Services could be implemented using a wide variety of transport protocols such as HTTP , RMI , CORBA etc. Or on top of technology such as JEE 's EJB stateless session
beans .

The fact that we think of SOA as SOAP, is because virtually every programming language can offer SOAP services and use them. That's not the case with all the other protocols
and technologies available. And there is the issue that the first three letters are identical...

When we talk about Service Oriented

Architecture , we mostly talk about an enterprise
architecture i.e. a set of software components
belonging to a single company - the occasional
external service provider fits in without a problem.

The other approach to web services, such as mash ups, and websites using services such as Google Maps etc. are not discussed here.

1.1. SERVICE

The service provider defines a contract, that is binding for both the provider and consumer. Think of this as a (kind of) API that has documented behavior, and that should only
evolve in a backward compatible fashion.

The parameters are always passed by value, not by reference. This is mostly required by the distributed nature of the deployment and the potential use of technologies that do
not support passing references.

A service should be autonomous, it should be owner of all it’s resources such as configuration artifacts (configuration file, jar libraries,…), database schema etc. This makes it
possible to substitute one service for another and to have freedom to improve, change the implementation without having to redeploy and test everything again. As long as they
observe the same contract.

This autonomy corresponds to the encapsulation principle of a good OO design.

If you want to evaluate whether a service is well

designed and abstracted, try to imagine two wildly
different implementations of the service, one
using a database and the other using for instance
an XML file as a persistence mechanism. If there
is no impact on other systems, you have a
perfectly designed service.

In real world cases, services are not always the owner of their database. Often this is because of a dependency by other software on that database like BI tools or worse, other
applications depend on the database schema. This is often the most important reason why SOA doesn't deliver on its promise of loose coupling and lower overall cost.

Relying only on well designed services that are loosely coupled, provides a way to incrementally upgrade or substitute part of the system without affecting the service
consumers. Such a substitution might be a migration of service per service to new technology or just the implementation of new business logic

1.2. W EB SERVICE

A web service is a service deployed with a particular technology, always involving HTTP and a text based data format such as XML or JSON. Different web service
technologies are available: SOAP, XML-RPC etc.

When talking about SOAP, some related technology, should be mentioned. UDDI (registry and discovery) and WSDL (WS Description Language) are XML-schemas and
documents that are primarily intended for discovering and consuming third party services.

1.2.1. SERVICE PROPERTIES

Ideally a service should respect a few rules. These are not always evident, but when followed, the service will be loosely coupled, more reusable and robust.

Autonomous
Reusable
Encapsulated
Idempotent Operations
Reentrant Operations
...

Autonomous . This means that everything the service needs, must be owned by the service. E.g. the database, other processes and services should not be allowed to
access the data except via the service. DTO and the service interface as described in the technical discussion are also "owned" by the service. This is the single most
important requirement for achieving the loosely coupled quality. Imagine replacing the current service with a completely redesigned new one, if other processes depend on
the same database structure, it is impossible to replace it.

Reusable . This is a quality that is not easy to detect and promote. It is related to an insight into the business logic AND a good grasp of clean, object oriented design
principles as encapsulation and coherence.

Encapsulated . This is a general design principle in OO , it enables loose coupling since the well encapsulated service can change its internal implementation without external
impact. It consists of hiding internal implementation details from external agents (components, other services etc.).

1 of 7 5/12/2010 7:19 AM
SOA - Service Oriented Architecture http://www.ooxs.be/EN/architecture/SOA.html

Reentrant Operations Reentrant means that the service’s operation can be called recursively and - more importantly – concurrently. Reentrancy is easily achieved by not
keeping conversational state . In development, it can be done by using local variables only, and accessing other variables as read-only values. Shared data must be
accessed in a thread safe way - such as using database transactions to achieve ACID-ness .

Idempotent Operations . This means that sending the same message twice should not result in two executions. E.g. obtain an invoice id and then invoke the makeInvoice
operation, if you invoke it twice, the service can detect this and react apropriately. This is not a required quality, it is something that depends on the concrete semantics of
the operation: ordering a chair twice might just mean ordering two chairs.

1.2.2. SERVICE AND T RANSACTIONS

One of the big issues when designing services is to determine how fine or coarse grained the scope of an operation should be. Other technologies such as EJB 's provide a
a notion of connections and can maintain conversational state over several, consecutive method invocations. JEE application servers provide distributed transactions that
can span multiple method invocations.

Typical web services do not provide a notion of session or transactions. The service interface should reflect that by offering operations that coincide with a typical
transaction.

Fine grained - two method invocations in single transaction

This example shows how the client can remotely interact with an EJB using several method invocations. In order to do this the client code has to explicitely open and close a
distributed transaction. In return it can commit or roll back all the changes with a simple commit or roll back.

Coarse grained - single operation invocations represents a single transaction

A service consumer should invoke an operation with enough data for the service to handle everything in a single transaction. In this example the two method invocations -
updateBalance and orderProduct - are turned into one operation - orderProduct . But all the parameters - price and stock number - are now passed together.

It is a very simplified example to illustrate the principle. In general the operations therefore require typically a lot more data compared to other local and remote technologies.

Another more concrete example is how a typical web shop application should interact as a service consumer with the service:

2 of 7 5/12/2010 7:19 AM
SOA - Service Oriented Architecture http://www.ooxs.be/EN/architecture/SOA.html

The consumer application maintains the conversational state with the browser/user

The web application assembles user data in a ShoppingCart object until the user wants to 'commit' his order by checking out. Only at that point does the application invoke
the order operation, passing all the necessary product information such as sku -number, quantity and probably customer identification to the service.

1.3. SOA E XAMPLE

This example is mainly provided as an illustration

on how different components in a SOA work
together. It is not a complete solution...

1.3.1. INTRODUCTION

We have a typical architecture that provides different sets of functionality to different sets of users, leverages existing investments in code and guarantees different
non-functional requirements which we will ignore for the moment.

We have several applications

A Dashboard application that provides management with BI to support taking insightful decisions.
A CRM application heavily used by the sales department.
A Helpdesk application, providing information about products and customers. Used by a call center.
A Financial application is used by financial managers and accountants to do monthly billing and invoicing.
An Infrastructure application is used by the IT department to install, upgrade and configure services and applications.

If we look at the CRM and Financial applications, you will see that both need data about customers, such as addresses.

In a well managed enterprise SOA, an architect will influence the design of services in such a way that they can be more easily reused later.

Example of an SOA

For the sake of argument, we assume that all

services and consumers are implemented in Java
technologies. This is of course not required,
services can be implemented and used in a lot of
programming languages.

1.3.2. SERVICE CONSUMER

Our consumers in the enterprise setting are typically web applications.

In this example we have a CRM application build on JSP technology, hosted on company servers and that can be accessed to enter new customer data from desktops and
laptops, used by sales reps.

A subset of this application is available for browsing on cell phones with limited capabilities - for a quick lookup of alternate contacts, phone numbers etc.

Workflow (orchestration) in this kind of applications is simple, so it would be probably handled implicitly from an MVC framework such as Spring MVC

Both applications use AXIS infrastructure to access the services over SOAP and HTTP.

3 of 7 5/12/2010 7:19 AM
SOA - Service Oriented Architecture http://www.ooxs.be/EN/architecture/SOA.html

Example of a SOA - Consumer

The WSDL-knowledge input symbolically shows that this service consumer implicitly needs to know a lot of about the actual service: parameter types, data types, return
values,... In an ESB architecture, this is externalized by the mediation function of the ESB

The consumer must also "understand" the semantics of the service.

Each consumer also needs to know where to find the service on the network. This is solved by the routing function when using an ESB architecture.

1.3.3. SERVICE PROVIDER

The service itself is plain java, using hibernate or jdbc to map objects to the database - in this example each service owns its own database.

The AXIS instance is hosted on a server and provides the business logic to service consumers such as our CRM application.

Example of a SOA - Provider

1.3.4. SOME IMPLEMENTATION DETAILS

In this section we will take a look at some implementation details when providing and consuming web services with Java.

This section is meant for developers, curious

about implementation.

JEE 5 provides means to offer access to session bean methods via the JAX-WS API.

Axis provides means to offer access to methods of POJOs as web services. Since this is the cleanest way to implement web services, we will use that as an example.

1.3.4.1. WS WITH A PACHE AXIS

It is not my intention to provide a complete WS with Axis tutorial, but a few quick highlights of the vital components when deploying a simple WS.

Axis consists of a servlet that uses the service class - CatalogServiceMemoryBased in the example - and a configuration file - deployCatalog.wsdd to make your service
available over the network. It contains an administrative servlet AdminServlet that helps deploying services too.

1.3.4.1.1. P ROVIDING THE SERVICE

We have here a very simple service that returns a list of products. Our implementation class creates the same list from scratch, but you could get it from a database
instead. That's left as an exercise for the reader.

We abstract this with an java interface, always a good idea when using something over the network.

package be.ooxs.examples.wsaxis.commo n;

import java.util.List;

public interface CatalogService {

public List<Product> getAvailablePro ducts();
}

We also have some helper classes that encapsulate data, you might know this as the DTO pattern.

Here is the Price

package be.ooxs.examples.wsaxis.commo n;

import java.math.BigDecimal;

public class Price {

private BigDecimal value;

public BigDecimal getValue() {

return value;
}

public void setValue(BigDecimal value) {

this.value = value;
}

Here is the product:

package be.ooxs.examples.wsaxis.commo n;

public class Product {

private String name;
private String sku;
private Price unitPrice;

public String getName() {

return name;
}
public void setName(String name) {
this.name = name;
}

4 of 7 5/12/2010 7:19 AM
SOA - Service Oriented Architecture http://www.ooxs.be/EN/architecture/SOA.html

public String getSku() {

return sku;
}
public void setSku(String sku) {
this.sku = sku;
}
public Price getUnitPrice() {
return unitPrice;
}
public void setUnitPrice(Price unitPrice) {
this.unitPrice = unitPrice;
}
public String toPlainString(){
return "Product " +name+" "+sku+" price: " +unitPrice.getValue();
}

Here we have the Web Service Deployment Descriptor (wsdd) , an AXIS specific file.

<?xml version="1.0" encoding=" UTF-8"?>

<deployment xmlns="http://xml.apache.org/axis/wsd d/"

xmlns:java=" http://xml.apache.org/axis/wsd d/providers/java ">

<service name="cat" provider=" java:RPC">

<parameter name="className "
value="be.ooxs.examples.wsaxis.provid er.CatalogServiceMemoryBased " />
<parameter name="interfaceName "
value="be.ooxs.example.wsaxis.common. CatalogService " />
<parameter name="allowedMethods " value="*" />
<namespace> http://catalog.ooxs.be/ </namespace>

<beanMapping qname="ns:Price" xmlns:ns="http://example.ooxs.be/ "

languageSpecificType=" java:be.ooxs.examples.wsaxis.c ommon.Price" />

<beanMapping qname="ns:Product " xmlns:ns=" http://example.ooxs.be/ "

languageSpecificType=" java:be.ooxs.examples.wsaxis.c ommon.Product " />

</service>
</deployment>

When the AXIS servlet is running, we can use the AdminClient to deploy our service.

Although you can deploy the service at run time,

you still need to provide the classes to the AXIS
instance. This means in practice restarting that
AXIS instance.

This is a Linux script file (bash), but it is a plain

java invocation. It should be trivial to do this on
other platforms...

export AXIS= your/path/to/axis /lib

export CLASSPATH="../classes":
export CLASSPATH=$CLASSPATH"$A XIS/axis-ant.jar":"$AXIS/axis. jar":
export CLASSPATH=$CLASSPATH"$A XIS/commons-discovery-0.2.jar" :"$AXIS/commons-logging- 1.0.4.jar":
export CLASSPATH=$CLASSPATH"$A XIS/jaxrpc.jar":"$AXIS/log4j-1 .2.8.jar":"$AXIS/log4j.p roperties":
export CLASSPATH=$CLASSPATH"$A XIS/saaj.jar":"$AXIS/wsdl4j-1. 5.1.jar"

java -cp $CLASSPATH org.apache .axis.client.AdminClient deplo yCatalog.wsdd -lhttp://l ocalhost:8080/axis/servlet/Axi sServlet

This is the WSDL generated by AXIS, formatted for your comfort

<wsdl:definitions targetNamespace=" http://catalog.ooxs.be/ ">

<wsdl:definitions targetNamespace=" http://catalog.ooxs.be/ ">

<!--
WSDL created by Apache Axis ve rsion: 1.4
-->

<wsdl:types>

<schema targetNamespace=" http://catalog.ooxs.be/ ">

<import namespace="http://xml.apache.org/xml-soap "/>
<import namespace="http://schemas.xmlsoap.org/soa p/encoding/"/>

<complexType name="ArrayOf_xsd_anyType ">

<complexContent>

<restriction base="soapenc:Array ">

<attribute ref="soapenc:arrayType " wsdl:arrayType=" xsd:anyType[] "/>
</restriction>
</complexContent>
</complexType>
</schema>

<schema targetNamespace=" http://xml.apache.org/xml-soap ">

<import namespace="http://catalog.ooxs.be/ "/>
<import namespace="http://schemas.xmlsoap.org/soa p/encoding/"/>

<complexType name="Vector">

<sequence>
<element maxOccurs=" unbounded " minOccurs=" 0" name="item" type="xsd:anyType"/>
</sequence>
</complexType>
</schema>
</wsdl:types>

<wsdl:message name="getAvailableProductsResponse ">

<wsdl:part name="getAvailableProductsReturn " type="impl:ArrayOf_xsd_anyType "/>
</wsdl:message>
<wsdl:message name="getAvailableProductsRequest ">

</wsdl:message>

<wsdl:portType name="CatalogServiceMemoryBased ">

<wsdl:operation name="getAvailableProducts ">

<wsdl:input message="impl:getAvailableProductsReque st" name="getAvailableProductsRequest "/>

5 of 7 5/12/2010 7:19 AM
SOA - Service Oriented Architecture http://www.ooxs.be/EN/architecture/SOA.html

<wsdl:output message=" impl:getAvailableProductsRespo nse" name="getAvailableProductsResponse "/>

</wsdl:operation>
</wsdl:portType>

<wsdl:binding name="catSoapBinding " type="impl:CatalogServiceMemoryBased ">

<wsdlsoap:binding style="rpc" transport=" http://schemas.xmlsoap.org/soa p/http"/>

<wsdl:operation name="getAvailableProducts ">

<wsdlsoap:operation soapAction=""/>

<wsdl:input name="getAvailableProductsRequest ">

<wsdlsoap:body encodingStyle=" http://schemas.xmlsoap.org/soa p/encoding/" namespace=" http://catalog.ooxs.be/ " use="
</wsdl:input>

<wsdl:output name="getAvailableProductsResponse ">

<wsdlsoap:body encodingStyle=" http://schemas.xmlsoap.org/soa p/encoding/" namespace=" http://catalog.ooxs.be/ " use="
</wsdl:output>
</wsdl:operation>
</wsdl:binding>

<wsdl:service name="CatalogServiceMemoryBasedServi ce">

<wsdl:port binding=" impl:catSoapBinding " name="cat">

<wsdlsoap:address location=" http://localhost:8080/ExampleW SWithAxis2/services/cat "/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>

1.3.4.1.2. C ONSUMING THE SERVICE

Although one of the big selling points for web services is that it is loosely coupled, a client is still bound (coupled) to the service by its interface - that is the operations
with their arguments and return values. That is not necessarily the same thing as a Java interface.

In an environment where both end points - consumer and provider - are implemented in Java and under your control, it is a good idea to share a common set of
interfaces and classes. In our example those shared, common classes are

CatalogService
Product
Price

We need to a little bit of tedious repetitive coding:

import javax.xml.namespace.QName;
import javax.xml.rpc.ServiceExceptio n;

import org.apache.axis.client.Call;
import org.apache.axis.client.Servic e;
import org.apache.axis.encoding.ser. BeanDeserializerFactory;
import org.apache.axis.encoding.ser. BeanSerializerFactory;
...

public static void main(String[] args){

Service service = new Service();
Call call = (Call) service.cre ateCall();

//Configure address, operation name and carefully map each t ype used in the service
call.setTargetEndpointAddress( new java.net.URL( "http://localhost:8080/Example WSWithAxis2/services/cat" ));
call.setOperationName( new QName("http://soapinterop.org/" , "getAvailableProducts" ));
call.registerTypeMapping(Price .class,
new QName("http://example.ooxs.be/" , "Price"),
BeanSerializerFactory. class,
BeanDeserializerFactory. class);
call.registerTypeMapping(Produ ct.class,
new QName("http://example.ooxs.be/" , "Product"),
BeanSerializerFactory. class,
BeanDeserializerFactory. class);

Object o = call.invoke( new Object[] {});

Object[] array = (Object[]) o;

for (Object object : array) {
System.out.println(((Product) object).toPlainString());
}
System.out.println( "Done");
}
...

OK that is the basic stuff.

But I would feel bad about giving bad examples. Here is a slightly refactored version that is a better starting point and example.

First an abstract base class that can be extended for each separate service you will use.

package be.ooxs.examples.wsaxis.consu mer;

import java.net.MalformedURLExceptio n;
import java.rmi.RemoteException;
import java.util.HashMap;
import java.util.Map;
import java.util.Map.Entry;

import javax.xml.namespace.QName;
import javax.xml.rpc.ServiceExceptio n;

import org.apache.axis.client.Call;
import org.apache.axis.client.Servic e;
import org.apache.axis.encoding.ser. BeanDeserializerFactory;
import org.apache.axis.encoding.ser. BeanSerializerFactory;

import be.ooxs.examples.wsaxis.commo n.Price;

import be.ooxs.examples.wsaxis.commo n.Product;

public abstract class AbstractServiceConsumer {

private Map<QName, Class<?>> register edParameterTypes;
{
//in production environment, u se Spring IOC instead
registeredParameterTypes = new HashMap<QName, Class<?>>();
registeredParameterTypes.put( new QName("http://example.ooxs.be/" , "Price"), Price. class);
registeredParameterTypes.put( new QName("http://example.ooxs.be/" , "Product" ), Product. class);
}

private void configureParameterTypes(Call call) {

for (Entry<QName, Class<?>> entry : registeredParameterTypes.en trySet()) {
registerSOAPType(call, entry.g etValue(), entry.getKey());
}
}

private void registerSOAPType(Call call, C lass<?> javaClass, QName qName ) {

call.registerTypeMapping(javaC lass, qName, BeanSerializerFac tory.class, BeanDeserializerFactory. class);

6 of 7 5/12/2010 7:19 AM
SOA - Service Oriented Architecture http://www.ooxs.be/EN/architecture/SOA.html

protected Object invoke(String methodNa me) throws RemoteException, MalformedURL Exception, ServiceException {
String endpoint = "http://localhost:8080/Example WSWithAxis2/services/cat" ;

Service service = new Service();

Call call = (Call) service.cre ateCall();

configureParameterTypes(call);
call.setTargetEndpointAddress( new java.net.URL(endpoint));
call.setOperationName( new QName("http://soapinterop.org/" , "getAvailableProducts" ));

Object o = call.invoke( new Object[] {});

return o;
}

protected <T> List<T> convert(Object[] array, Class<T> type) {

List<T> list = new ArrayList<T>();
for (Object object : array) {
list.add(type.cast(object));
}
return list;
}

Next, a concrete implementation for our CatalogService

package be.ooxs.examples.wsaxis.consu mer;

import java.util.ArrayList;
import java.util.List;
import java.util.logging.Level;
import java.util.logging.Logger;

import be.ooxs.examples.wsaxis.commo n.CatalogService;

import be.ooxs.examples.wsaxis.commo n.Product;

public class SimpleCatalogConsumer extends AbstractServiceConsumer implements CatalogService {

@Override
public List<Product> getAvailablePro ducts() {
try {
Object o = invoke( "getAvailableProducts" );
Object[] array = (Object[]) o;
return convert(array, Product. class);
} catch (Exception exception) {
Logger.getLogger(SimpleCatalog Consumer. class.getName()).log(Level.SEVERE, "getAvailableProducts threw Ex ception", exception);
throw new RuntimeException(exception);
}
}

2008-2009, Mark Meyers

7 of 7 5/12/2010 7:19 AM
ESB - Enterprise Service Bus http://www.ooxs.be/EN/architecture/ESB.html

1. Introduction
2. An Example
2.1. Introduction
2.2. Consumer
2.3. Provider
2.4. Functions

1. INTRODUCTION
First things first. At the time of this writing (2009) and for the past few years, there has been a big
controversy about what exactly an ESB is. There are largely two opposing camps:

ESB is a concrete instance of a SOA where some standardized ways of invoking services are
implemented, enterprise wide.
ESB is a software product, that connects different technological applications together.

The first approach is an interpretation where an Enterprise Architecture is introduced, relying on SOA
principles. An ESB then is SOA as required by and seen from the perspective of a single company. Where
SOA could be more general spanning different companies and service providers - e.g. a social
networking site A relying on a service implemented and hosted by another company B for SMS messages
and company C for backup etc.

The second approach is the one favored by EAI vendors who sell a product, often relying on messaging
systems - MoM . For a few years now, this last interpretation seems to win the upper hand. Big marketing
efforts might have something to do with this. On the other hand, an integration effort that promises
leveraging existing (legacy) applications and related investments, has its own merits of course.

One difference between both approaches is that

in a EAI approach, communication flows in both
directions.

Personally, I prefer the first approach, since I believe this empowers the enterprise (customer) and not the
vendor.

An article about this subject summarizes some of these concerns. Incidentally, the article was edited to
reflect the fact that IBM still thinks their ESB offerings are OK - which shows the entire ESB concept has a
lot of controversies...

An increasingly common request from clients is to complete a

project that does not use SOA as a whole, but instead
implements only an enterprise service bus (ESB) architecture.
Such an ESB-oriented architecture is easy to envision, but its
success is difficult to measure. What clients requesting such
projects don't understand is this: An ESB-oriented architecture
doesn't produce business value. A project based on
ESB-oriented architecture needs to be made into one based
on SOA to help ensure that it successfully delivers business
value.

I found a very good definition that would cover both ideas in an article on the ServiceMix website:

1 of 4 5/12/2010 7:20 AM
ESB - Enterprise Service Bus http://www.ooxs.be/EN/architecture/ESB.html

The Enterprise Service Bus (ESB)- which can be defined as

middleware that brings together both integration technologies
and runtime services to make business services widely
available for reuse - offers the best solution for meeting
today's enterprise application integration challenges by
providing a software infrastructure that enables SOA.

I think the main business value comes from the promise to write or reuse software and integrate them
easily, as any "appliance" you plug in to your personal computer, such as USB keys, digital cameras and
cell phones. My personal attempt at an informal definition then, would be:

An ESB is an architecture or software product that envisages

a pluggable enterprise architecture - where services and
applications can be plugged in and work together easily.

2. AN EXAMPLE
Let's take a look at an ESB from a more concrete point of view.

This example is mainly provided as an illustration

on how different components in an ESB work
together. It is not a complete solution...

2.1. INTRODUCTION

Imagine a company producing and selling goods. They have sales people visiting customers looking up
information about their customers, offering quotes, registering orders. There is a financial department
doing the billing, detecting overdue payments, reporting revenue and cost to management. These
business activities are supported by different applications.

2 of 4 5/12/2010 7:20 AM
ESB - Enterprise Service Bus http://www.ooxs.be/EN/architecture/ESB.html

Example of an ESB

Now look at the particular use-case of salesman who just entered the data for a new order, on his
laptop in the offices of the customer. The order can be printed and sent by mail - or in a PDF-format by
e-mail - together with service contracts etc.

His laptop shows a web application in a browser, his browser connects to the application running on a
server of his company, the application is plugged into the ESB and uses the "Printing Service" to
generate and send the documents to the customer.

2.2. C ONSUMER

Example of an ESB - Consumer

Consumer in this context means "consumer of the provided services".

The user hits a button in his web browser, a JSP is invoked, and this uses the ESB to send a message
to the printing service, typically the payload of that message would be XML in a format favored by that
web application. This message is the green one in the illustration.

An important difference with a basic, plain SOA is that our web application does not need to know
about the actual format used by the service, it still has to send sufficient data though. It does not need
to know about the location of the server that hosts the service, only about how to contact the ESB.
Even if the application uses a multitude of services on different hosts, it only needs to know one
address: that of the ESB.

2.3. P ROVIDER

Example of an ESB - Provider

The Printing Service receives a message from the ESB to generate some documents, print them and
send them by mail (more probably print them on a dedicated printer...). This message arrives as XML
containg the necessary data to perform these tasks, in a format favored by that service , possibly a
different format to the one that was sent initially. This message is the blue one in the illustration.

2.4. F UNCTIONS

3 of 4 5/12/2010 7:20 AM
ESB - Enterprise Service Bus http://www.ooxs.be/EN/architecture/ESB.html

Example of an ESB - ESB Functions

Our ESB receives the original message from the web application (Consumer), determines by the origin
in what format it is. Extracts information about which kind of service is required and determines which
service to use. Next, the ESB determines which format is expected by the concrete selected service,
then transforms the incoming message (green) to the format of the service and invokes the service with
the transformed message (blue).

This course of events shows some internal functions of our ESB: routing and mediation. A typical ESB
might offer much more functions, but this will do for the moment. These functions are represented as
the black boxes in the illustration.

Let's look a little more into the routing function. The consumer requests a service invocation with some
data. But it only specifies what kind of service: "print". The ESB also offers a management console or
application that allows for configuration of the routing (and mediation) function. You could introduce
logical rules ("if application 'crm' requires printing, then select 'any PrintingService, version 123' on host
'SERVER002 or SERVER005'") or hard wire the routing information ("if application 'crm' requires
printing, then select 'PrintingService001' on host 'SERVER002'").

The mediation function is often implemented using XSL-T , for each possible transformation, an XSL-T
document must be provided so that an incoming message can be transformed into the format required
by the invoked service. This XSL-T document is the red one in the illustration.

2008-2009, Mark Meyers

4 of 4 5/12/2010 7:20 AM