Skip to Content

SOA Reference Architecture



During the last years it becomes obvious that there are disruptions in software that changes the IT world completely and how software is used and developed. These market trends are important to define architecture, because the trends directly influence the implementation or define what has to be done.


Software is not only used directly at customer side; it is hosted in a central infrastructure. This is usually called on demand or software running in a cloud.
The technical changes also imply a change in the way how customers are working with the solutions and what qualities they expect. It does not mean that these qualities were not expected before, but in the on demand world the priority of these requirements is even higher.

The most important qualities are:

  • Elasticity: the ability of the system to scale to the customer’s needs very fast.
  • Administration: TCO is always rated as a key cost driver, but in the on demand world the administration costs should decrease to (at best) zero for the user of the cloud infrastructure.

To achieve such qualities the architecture has to be changed. Nevertheless, the existing solutions are used by customers and usually the customers want to use their systems in the future, until a move to the on demand infrastructure is possible. Therefore the integration of the existing system, usually called on premise, with the on demand infrastructure is a key capability of the reference architecture. In the best case the two worlds work together, so that the customer can benefit from the on demand offerings even in on premise systems.


Over the last years the internet becomes more and more interactive, i.e. people are connecting to others, and exchange information. There are a lot of platforms like facebook, twitter, del.icious etc. that define networks of people. The people are collaborating on these platforms and share information.

In the moment big vendors like are integrating such collaboration features into their products to create communities around the topics.
Web 2.0 was the starting point of this market trend, because it brought the internet from the static pages to more dynamic and interaction.


The IT world is moving from PCs to mobile device, e.g. iPhone, Blackberry devices, or Android cell phones. These devices open a completely new area of computing, because the devices are connected always and everybody can carry it every time. So, the services that the internet provides are available always.

Usually people are interested in information, so there is a need to adapt the data to the user’s needs. SOA as an architecture principle should allow an easy assembly of predefined services. All frameworks around SOA focus on the information exchange. To connect mobile devices to SOA infrastructure is a very natural step. The only addition that has to be done is that the data has to be tailored to fit to a mobile device regarding size of the data or response times.


Beside the changes in the market that are coming from the business side there are even trends in the architecture that influence how the SOA architectural style will be implemented in the future.


Some years ago software was developed by companies completely on their own. Starting from the deepest level of the operating system, it goes to the platform level, and specific frameworks. Everything was coming from one hand. The SAP R/3 system is a perfect example for that.

The world outside SAP has changed, because there are a lot of frameworks that are taken by software companies to speed up their product development. So, open source frameworks are taken to avoid reimplementation of an already existing piece of code.
In the end the product development is much faster, because not the full product has to be implemented from scratch. The development of SOA frameworks has to take this into account by using opne source software and even contributing to the open source projects to improve them in a way to fit to the needs.


The virtualization infrastructure is providing the scalability capabilities of frameworks and services, both on premise and on demand.


The virtualization infrastructure first of all has to provide runtime nodes for execution. These nodes are bundled in clusters, and on top of the hierarchy there is a cloud infrastructure. The nodes can run with arbitrary operating systems and can be added to a cluster very fast to scale the workload of the system.

This infrastructure is not only used on demand, there are definitely use cases in the on premise case, that make a scalable and low administration infrastructure useful. The first example for such a use case is the message handling in an ESB for high volume scenarios. The workload of the message handling infrastructure has to scale to a very high limit and at the same time the customer do not want to invest so much in the maintenance of the message handling infrastructure.

So, the virtualization infrastructure is used on premise and on demand. The runtime components have to be implemented in a way that the work on this infrastructure.


Traditionally the SOA infrastructure is on premise, i.e. all the systems are running directly at customer side, so that the customer can orchestrate the services directly in his network. But this comes with the price of installation, configuration, and administration. Therefore the capabilities of SOA should be provided in an on demand infrastructure, so that the customer can benefit from the on demand advantages and migrate completely to on demand.

On the other side the investments at customer side have to be protected, so that the customer does not have to change his infrastructure without any benefit. The customer should be able to utilize the new on demand capabilities and even benefit in the on premise installations from the investments in the infrastructure. This requires a transition architecture, i.e. an architecture that builds on the existing assets and extends it with the new capabilities for a small period of time, until all capabilities are on demand.


After summarizing the market changes and trends and the overall direction it is important to map it to SOA and the implementation of SOA how we know it today.
SOA is first of all an architectural style, not a technology or framework. So, beside the market changes there is usually a definition where the architecture style helps and in what way it helps. The scenarios that are discussed in the SOA area are the following, see [4]:

  • Service creation: Creating flexible, service-based business applications. A new service-oriented application exposes business behavior as a service and also reuses business logic which is exposed as a service.
  • Service connectivity: Link people, processes and information in the business with a seamless flow of messages and information from virtually anywhere at anytime using anything by making accessible a set of core services available to a variety of applications through the usage of an intermediary service gateway or bus.
  • Interaction and collaboration services: A service or set of services must be presented to a human user through multiple devices such as browser, PC and mobile devices. Interaction and collaboration services also improve people productivity by aggregating these services as views delivering information and interaction in the context of a business process.
  • Business process management enabled by SOA: Business process management is a discipline combining software capabilities and business expertise to accelerate process improvement and facilitate business innovation.
  • Information as a service: Information as a service offers information access to complex, heterogeneous data sources within the company as reusable services.
  • SOA design: Aligning the modeling of business design and IT solution design through a set of roles, methods and artifacts to render a set of explicit business processes for optimization and services for composition and integration.

These scenarios are the foundation of the architecture concepts and principles.



Before defining architecture, it is required to derive basic principles out of the scenarios. All the scenarios have some qualities in common:

  • Flexibility: the applications, services, and process are built on top of existing services in a flexible way. So, the principles should allow flexible solutions to adapt to changed requirements. This leads directly to the loose coupling principle of SOA that is applied internally in the frameworks and even externally in the applications.
  • Scalability: in all scenarios information is exchanged between the different participants. So, the transfer should be fast and not restricted by bottlenecks in the infrastructure.

The basic principles are used as guidelines for implementations and should improve the architecture to fulfill non functional requirements like performance, maintainability etc. But a second goal is that a clear, layered architecture with the right abstractions prepares a product even for future requirements. Experiences have told that it is extremely important for implementations to design upfront for changes, otherwise the product cannot evolve in the future, because it is one monolithic block of coding that nobody understands any more. So, flexibility is not achieved.

The most important principles are summarized:

  • Partition by function: Related pieces of functionality belong together, while unrelated pieces of functionality belong apart.
  • Split horizontal: Decouple the required implementation in smaller parts to achieve scalability.
  • Avoid distributed transactions: Distributed transactions would couple components together, therefore transactions are not crossing component borders.
  • Asynchronous communication: asynchronous communication decouples the runtimes of different components.

After defining the principles the key concepts should be mapped to the principles. First of all the release independent components are the smallest building blocks. By assembling these building blocks it is possible to ensure flexibility on the technical level and by doing that on the business solution level, too. The layers allow flexibility and scalability on the higher level of architecture of the system itself. On the highest level of architecture different products are assembled by release independent components and layers following the product lines.


The different frameworks, services, and components have to be built in a way that reuse of the implementation is possible. Here, the strategy of a platform with different platform variants has to be applied. The most important aspect of product line architecture is that the atomic building blocks for different products (assemblies of components) are clearly defined. The component criteria are defined as follows:

  • The component clearly exposes required and provided interfaces, see [3]
  • The interfaces of a component have a version information
  • The component is focused on a precise and coherent mission
  • The component is not intimately linked to a non-reusable framework
  • All components used by the component are known and documented
  • Links between release independent components are versioned

The release independent components are the building blocks of a product. In the diagram two products are shown constructed out of release independent components.



The release independent components are even under development, so there are new features available in the components that make it sometimes difficult to evolve the implementations. There are two ways of implementation possibilities:

  1. Compatible changes. If a component is changed in a compatible way, then the new component can simply replace the old version.
  2. Incompatible changes. Sometimes a component and even the interfaces that it exposes have to be changed in an incompatible way, then it is important that all links to such a component are versioned, so that the components that use the old version get an instance of it. Usages to the new component version have to versioned, too.


Based on the release independent component it has to be defined how the components work together. Again, it has to be avoided that the components are assembled into a monolithic block for a product. Even in a monolithic block a basic reuse is possible, but the overall goal of a flexible architecture is not achieved.
Therefore it is essential to talk about a layered architecture. It is a known pattern that the architecture of a product should be done in layers. The layers have a specific purpose and the functionality between the layers is not mixed. The simplest layering is that there is a layer for persistency, then a layer of logic, and after that layers for user interfaces.

During the last years an architecture principle arises that gives more structure, see SEDA (Staged Event Driven Architecture) [2].

SEDA is based on two principles:

  • Stages: are the defined layers of architecture. Inside a stage the execution can be done in parallel, so modern technologies like parallel execution can be used inside the stages. The stages are decoupled by event queues.
  • Events: are the communication mechanisms between the stages. The input event queues receive the events and delegates the work to the different execution engines (threads, processes, actors, etc.). If a task is done, the output can be send as an event to another stage.



By using SEDA the communication between the stages is done in an asynchronous way. So, it is possible to scale the different stages by simply adding another execution node in the stage to handle incoming events.

The layers are the sections of a product and define the overall skeleton of the solution.


Especially on demand scalability is a very important capability, but even from a pure architecture point of view SEDA makes sense, because it decouples the layers and makes it possible to replace the implementations of the stages, if one implementation is not working well. So, by applying SEDA the architecture is prepared for changes in the future on large scale.


Two principles defined before are the asynchronous communication between the components and the horizontal split of functionality to allow scalability. These two principles are used in the SEDA architecture concept and applied in all frameworks and services in the SOA platform.

The concept can be explained in the best with a simple blue print of split architecture. The layering of the functionality should start from the user interface layer, continue in the logic layer, and end in a decoupled layer for persistency. Each of the three layers is a stage according to SEDA, so the parallel requests to the user interface are handled with different threads. When the functionality of the logic layer is invoked, this will happen with an event that is raised in the user interface layer and caught in the logic layer. This pattern will even be applied between the logic and the persistency layer.

Such layering has advantages

  • The layers can scale independently, e.g. if there is a higher workload on the user interface layer, it is possible to add new execution nodes.
  • The layers are decoupled from each other. If the solution is used later and one of the layers is not performing well because of some basic architecture decision, it is possible to exchange the implementation of this layer at a later point of time. So, the system is designed for changed, because parts of it can be replaced independently.


There are different products in the area of service orchestration, especially if the infrastructure is on premise or on demand. Nevertheless, there is a lot in common in the different products, so that reuse of implementations would make sense. Such a reuse has to be planned upfront, otherwise the frameworks, services, and components would not fit to each other. In the last years the terms product line architecture or product line engineering, see [1], become more and more important in this area.

All frameworks, services, and components have to be built in a way that they fit to the requirements of independent pieces that are reusable in different products of the family. Release independent components and even whole stages can be reused in different products.



In the past development was based on many repositories and many repositories. This leads to a lot of breaks between the different parts of SOA with life cycle management gaps. The principle to avoid this in the future is to define a very low level of agreement, again to allow flexibility.

The development is based on resources that can be put in any arbitrary repository. So, a specific framework is not required any more.

The basic principles for resource based development are:

  • The technology of the tool follows the user requirements. The tool set for a complete task has to be available in one tool technology. The current assumption for developer tool technology is Eclipse, for business user a web UI is assumed.
  • The tool persists the data in a human-readable format in a resource.
  • The developer tool provides a superset of the functionality of all other tools. Based on the current assumptions Eclipse provides the capabilities to edit all resources. This does not mean that all graphical editors have to be reimplemented in Eclipse. Human-readable resources can even be edited in a text editor.
  • The tools are built with minimal assumptions. If an integration with another tool is required, then it has to be implemented in an optional way, so that the tool can be installed and used independent of the other tool.


Federation is the capability of a system network to federate content between participants. So, the systems in the network are communicating and the systems need the same information at many places. Again, flexibility and scalability is key in the repository area.

Therefore the simplest solution is to create a local copy of the information in one system. This leads to redundancy. The redundancy has to be managed in a controlled way, so that the redundant data should be in sync with the original.

Federation has to be applied in service orchestration at many places:

  • Design time content: is stored locally in every system and is exposed to other consumers.
  • Process instance information: is exposed to other consumers, so that end-to-end monitoring involving many systems is possible.
  • Service configuration: is exposed, so that it becomes clear what other systems are used. This is used to provide a consistent view of the network including all systems and services.

Federation is an important functionality in a network including communication and sharing data between systems. Service orchestration should not rely on any central hub functionality for sharing of content; nevertheless any system can be defined as a hub system, if centralizing functionality helps customer in his integration tasks.


Service orchestration is based on specific entities. This section will describe the main entities in this area. The concepts behind that go beyond the terminology used in SOA so far.


In service orchestration some entities are enough to explain how the technologies work together and how the infrastructure has to handle the instances. The foundation of the service orchestration is the network where the whole interactions between systems via services and processes happen.

An overview contains only a few entities:



The network is bundling a set of systems to define that these systems can see each other and can interact with each other. A system itself can either be an on premise system or an on demand system and contains services and processes. The traditional way of thinking inside a company to see the company intranet is a special kind of network, a company wide network.

Networks can be defined based on the business requirements. If many companies need a secure communication infrastructure, then they define a business network that is only accessible for them, completely hidden for others. So, there is not a predefined set of networks, it is part of the business to define the network and work in these networks.

Contexts are connected with the network to allow putting data into a context to make it available for all services and processes. So, the data is not only exchange from one service to each other, it can be shared generally in the whole network.

Services itself can call other services, and it does not matter, if the service is located at the same system. In principle one service can run in an on demand system and it can call a service on premise.

So, the network is the underlying infrastructure. Based on the network some consequences have to be explained further. Currently most of the architecture design is system centric, but in the service orchestration in a network some principles are new.


A Business Service is an extension of the services as they are defined in a SOA environment and fulfills the criteria of a Release Independent Component. The key differentiator is that the Business Services have to fulfill other qualities to ensure a performing and scalable solution.

A Business Service is an entity that can run on its own; it usually does not require any other service or framework. It has to work according to the loose coupling principle, meaning that every used function is only optional and the dependency is not mandatory. So, Business Services should be able to run in isolation, so that the following case is possible: two Business Services are loosely coupled. So, they use the functionality of each other, but the dependency is not mandatory. Both are for free usage, but at some point of time one of the services is not for free any more. Now the other Business Service should run independent of thepaid service. Such decisions are pure business decisions, but the design of the Business Services should allow and support such decisions.



The difference between a Business Service and a service is that a Business Service is a self contained entity. If there is reusable functionality, then a service has to be defined and the Business Service can use it. Services themselves can call each other. Enterprise Services are services in this terminology.

The Business Services are loosely coupled and not connected necessarily via direct runtime calls; invocation via a network is the usual way of interaction. This means that the network becomes more important, because it provides the runtime environment for the Business Services.

Because there is the network between the various actors, each one has to design in a way that failures do not hurt the whole system. It has to be expected that one other part that should be used over the network is not available, so design for failure is a principle in Business Services.


The architecture of the new solution is split by nature in two parts: an on premise part and an on demand part. But both parts have to work together. Both sides work together in the following ways:

  • The on premise frameworks of the orchestration hub are integrating with the on demand services.
  • The on demand services can access exposed data of the on premise systems. This is highly security relevant.



All the concepts and principles are applied in this integrated architecture.

  • The basic building blocks are based on release independent components (mainly implemented on top of open source).
  • The layers are designed in an asynchronous way to allow scalability.
  • The product line architecture principle is followed by reusing release independent components in different products.
  • The virtualization infrastructure is used on demand and even on premise for scale out scenarios. But all frameworks can run in a virtualized infrastructure.


Based on the integrated architecture of SOA in the future and the direction to go on demand there are quite some challenges that exists even in the past, but become more important in the new implementations.

So, the challenges are definitely the areas were further analysis is required.


Some of the principles are focused especially to allow scalability of runtime components and whole products. But beside the principles it is definitely required to define the concrete requirements for the runtime and even for the systems.


In an on premise landscape (at one customer) the identity management is very important, because it is not allowed that all users of a system can do everything and the access to the systems has to be restricted. So, they need to authenticate to the systems and the authorizations to do specific actions have to be checked always. Therefore there are specific systems and frameworks to do these checks.

In an on demand landscape this requirement becomes even more important, because a good isolation of users and the data is key. The isolation of data based on the tenant information is called multi tenancy.

Every framework running in an integrated SOA environment has to be implemented in a way that such identity information are handled absolutely correctly.


Customer networks will be connected to on demand functionality in the future. How such connectivity can be built in a fast and secure way is one of the biggest challenges in the integrated SOA environment.

All frameworks are potential candidates to run on demand and therefore have to use data from customer side.


The new infrastructure for service orchestration is using the same building blocks that are even used in a SOA environment:

  • ESB
  • BPM
  • Repository

All components are built in a way that they can run either in an on premise system or on demand. This requires the adoption of the product line architecture principles for the runtime components.


An Enterprise Service Bus (ESB) is providing the infrastructure for message handling between various systems. Because the types of messages can differ a lot (formats, protocol, etc.), the ESB has to provide an extensible mechanism to handle message and transform messages into other messages. An ESB is the backbone of a SOA solution, because services are usually transferring messages from one to each other.

The amount of messages in a company network is usually huge, so the infrastructure has to be highly scalable and performing well. But there are not only messages inside one company, even in a business network that is created between many companies the number of messages is very high, so message exchange in an on demand solution is very important. Therefore the ESB has to be built in a way that it can exchange the messages in the on premise landscape of one customer or even in the on demand network of many companies.

The ESB has to provide a functionality to show the communications between the involved systems. There the systems have to expose what other systems they call, so that it is possible to get the information.

In an ESB all the communication in a network comes together, so that it is possible to monitor the service calls first of all, and in a next step it is possible to define, what system is allowed to call what other systems and at the end the communication can be controlled. This is usually called runtime governance.


A Business Process Management (BPM) solution is providing the infrastructure to execute processes inside a network. Usually many systems are involved and the business process defines how the data is transferred between the systems. One important aspect of a business process is that many people can be involved, e.g. one person creates an request, others have to add some information, and at end one person has to approve the request in another system.

The process is using the services that are provided by the systems, and the process is usually the entity that provides the flexibility in a SOA environment, because the services are the immutable entities in a SOA environment (stable, available, always compatible, etc.), but the process can be changed every easily, if there are new business requirements.

Therefore it makes sense to allow BPM on demand, because a user simply wants to adapt an existing process or to create a new one in a very fast way without too much effort (setting up a new system, no administration for the process infrastructure, etc.)


An Enterprise repository is the storage location for all artifacts in an SOA environment. This includes the service definitions, the message types, the process definitions, etc. The repository has to provide this information for the whole landscape. In case the repository is used on premise inside one company, then the repository is only accessible inside this network. In case the artifacts have to be reusable inside a business network, the repository has to be accessible within the whole business network, therefore it would be a good choice to put it on demand.

To make it available on demand does not mean that there is a central repository for a network that stores all entities. The repository infrastructure needs the capability to federate content, i.e. one repository can use content in another repository. All involved systems in a SOA environment have to respect the principle of locality, i.e. content is stored in the system where it is executed, not in a separate system. So, the repository on demand is highly federated and referencing a lot of content in other repositories.

On top of the federated repository infrastructure it is possible to search the content in the Enterprise Repository in a distributed way. This is similar to a Web search where the whole network is analyzed. The search functionality is a key capability of the repository.

Like explained in the ESB area and in the runtime governance, it is possible to control the usage of services, even directly in the design time by defining, if a specific service can be used in this or that way. Together with controlling the development process of services and processes this is usually called design time governance.


Authoring in a SOA environment is a wide area. It can start from the pure development of processes and services in a development environment. Beyond that it makes sense to provide tools for business users to easily create the artifacts.

To allow the option that the different tools interact it is important that the tools are only handle resources. A resource is an artifact with a unique identifier and human readable, and the basic rules are defined in the basic architecture concepts.

Beside the requirement that resources are used there are some decisions inside SAP what are the tool frameworks that should be used. For the developer role Eclipse is the basic infrastructure, and for business users the user interfaces have to be implemented in HTML5 and Silverlight. Therefore the authoring environments for business users in the service orchestration have to be implemented with these frameworks.


The SOA frameworks on premise and on demand are similar regarding their functionality. The only difference is that the on premise infrastructure runs directly in the landscape of a customer, so it is completely owned by him. For short term project requirements or scaling reasons it would make sense, that on premise and on demand solutions complement each other.

The two options, either on premise or on demand, are not exclusive, so a customer can mix the different infrastructure in principle in two ways:

  • Starting on premise and using on demand infrastructure: customers with running systems have a lot of content. Now, the on demand infrastructure can provide additional capabilities, e.g. Business Activity Monitoring (BAM) or Process Simulation, and the on premise infrastructure can integrate these capabilities in a way that the models can be transferred to the on demand system for simulation or the process instances are monitored by an on demand system.
  • The business user starts on demand and switches at a dedicated point in time to the on premise infrastructure. This can happen because of many reasons, maybe the performance of the on premise system is better, maybe the customer does not want to expose mission critical data into the on demand infrastructure. There are a lot of reasons, but nevertheless such transfers of content should be possible.

Close cooperation happens between the frameworks on premise and on demand. So, the SOA frameworks should work together in arbitrary combinations, e.g.

  • ESB on premise, BPM and Enterprise Repository on demand
  • ESB and BPM on premise, only Enterprise Repository on demand

So, the design principle is that the components are designed to work together in all combinations.

From a technology point of view there are different ways to integrate the on premise and the on demand infrastructures. It is rather straight forward to use functionality that is provided on demand. It is the basic characteristic of an on demand service that it is available publicly.

The other direction from the on demand to the on premise infrastructure is more difficult, because the on premise runtimes are located at customer side in a private network, usually secured behind a firewall. Therefore there are at least two ways to allow interaction:

  • Simple integration works via well known technologies like email or file download. So, the known channels are used to transfer data into the private network.
  • Secure communication channel between on demand and on premise allows information transfer into a private customer network.


[1]  Product Line Engineering in Wikipedia: 

[2] SEDA:

[3] Jaroslav Tulach: Practical API Design: Confessions of a Java Framework Architect

[4] SOA and Web Services:

1 Comment
You must be Logged on to comment or reply to a post.
  • Ulf,
    this is a interesting and challenging document.
    I got some questions, sections indicated by capitals:
    -RESOURCES: “many repositories” duplicated, what would be the second word ?
    -NETWORK: how is “process” defined in the metamodel compared to “service” ?
    -BUSINESS SERVICES: why is an “Enterprise Service” a “Service” and not a “Business Service” ?
    -TENANTS AND IDENTITY: why don’t you mention SSO and federation of roles ? Imagine R/3 users would like to utilize Business By Design services !
    -ESB: as a business network hub would you recommend an ESB “on premise” or “on demand” ?
    -BPM: again not clear to me the exact meaning of “business process”, “business service” and “service” in your metamodel
    -INTEGRATION OF SOA: surprised that you distinguish “on premises” and “on demand” frameworks. I understood your document as an important step towards ONE framework !  

    Btw what are the differences between Fig. 2,4,5 ?

    Thanks and best regards