Click here to Skip to main content
13,198,465 members (67,068 online)
Click here to Skip to main content
Add your own
alternative version


36 bookmarked
Posted 6 Jan 2007

Extended SOA - A Pattern for Enabling SOA in a Big Organization

, 6 Jan 2007
Rate this:
Please Sign up or sign in to vote.
The purpose of this paper is to present one of the possible approaches of implementing SOA in a big organization using existing business processes and within existing infrastructure.
Sample Image - Extended_SOA.png


SOA, Service Oriented Architecture is a well-known buzzword, which has been for about two years on the IT market and it has captured from the beginning the hearts of business owners and project managers. Nowadays SOA, due to continuously better technological support is getting to change the point of view of software architects also. It seems to be finally possible to build an application that consists of reusable, extensible components that are able to communicate in easy and effective way. It seems to be possible to couple business processes, decouple technology and to enable infrastructure. But to achieve this aim, SOA has to be driven by business. The key point of the approach of implementing SOA is to analyze and document all business processes within an organization, thus allowing exact and comprehensive definition of business domains, boundaries, services and messages.

This service-based approach makes sense for building solutions that cross organizational, departmental, and corporate domain boundaries. So SOA is a very interesting concept for big organizations. But these types of organizations are especially difficult for SOA implementation due to inconsistent definitions of business processes, different technologies being used and distributed and heterogeneous infrastructure. For many software architects, these problems make the implementation of SOA in a big organization almost impossible.

The purpose of this paper is to present one of the possible approaches of implementing SOA in a big organization using existing business processes and within existing infrastructure.

1 The Challenge

The standard approach of SOA implementation requires that this process has to be driven by business. Business representatives together with software architects should analyze and document all business processes within an organization, optimize them if required and then start the SOA implementation. But what kind of approach should we follow if we have a possibility to build or rewrite a part of a global solution, but we are not able to analyze the processes entirely, we do have a limited influence on technologies being used and we do have to use fixed infrastructure (remember: the aim of SOA is to couple business, to decouple technology and to enable infrastructure). Are we able to stay SOA compliant?

1.1 Definition

Lets recall one of the simplest but very good definitions of SOA:

“SOA is an architecture based on loosely coupled components (services) that exchange messages” [HJ00].

1.2 Business

In a big organization, it is common that the business is crossed over different departments, internal organizations and countries, which makes the description of it for SOA purposes very difficult. Even if the organization has created a good, consistent and comprehensive documentation of business processes, they may be understood by the parties involved in slightly different ways. It is not unusual that the same global business processes exist in many sub-versions due to e.g. different law regulations, specific situation on marketplaces, etc. On the other hand, the internal business processes that we are going to implement have no such problems. We have comprehensively analyzed and documented our processes and we are able to easily define our business domains and describe services for our application needs.

1.3 Technologies

The technology-environment that we can find in a big organization is mostly heterogeneous. We are not easily able to recognize or assume the types of systems and technologies that our system will have to use or to exchange data with. On the other hand, our architecture is well defined and the technologies we are going to use build a homogenous environment.

1.4 Infrastructure

Big organizations have very often more than one software development team, more than one business critical application and more than one application center. It is very common to find additionally a middleware system between those systems, which is responsible for communication between them. These systems serve functionalities that have to be used by our application too. On the other hand, our application has to serve services for the other systems in a well-defined way within this existing infrastructure.

2 The Solution: Extended SOA

All problems and requirements described in the previous topic make SOA implementation, using single SOA solution quite difficult. Nevertheless we are able to associate each of the issues to one of two areas of architecture: internal and external. So the solution is to use two SOA implementations: internal and external. Together they build the Extended SOA.

2.1 Architecture

Extended SOA consists of two SOA implementations: internal and external. In this way we can spread different requirements from business, technology and infrastructure sites on both implementations without losing the benefits of SOA.

Extended SOA - Architecture

Every SOA solution requires service consumers, which send requests, and service providers, which send responses on requests:

Extended SOA - Service Consumers and Providers

In the Extended SOA implementation, we can recognize the following services:

  • Foreign Services
    They represent services served by other systems of the external SOA. These services communicate with the middleware only and they are out of scope of our implementation.
  • Middleware
    It acts as a service consumer part of external SOA implementation. The middleware is responsible for communication between all foreign services and our External Application Services and it is out of scope of our implementation.
  • External Application Services
    They act as service providers for the middleware and as service consumers for Internal Application Services. These services combine and connect both SOA implementations.
  • Internal Application Services
    They serve core functionality of the application acting as service providers for External Application Services and as service consumers for Basic Application Services.
  • Basic Application Services
    They serve basic functionality of the application simplifying the build process of Internal Application Services (Add, Update, Delete, etc.). They act as service providers for Internal Application Services.

2.2 Services in Scope

2.2.1 External Application Services

External Application Services (EAS) bind both SOA implementation thus are core element of the whole Extended SOA architecture. They work as service providers for the middleware using messages and communication types that have been chosen for this implementation. In this way, we are able to serve services that are compliant to global guidelines and IT portfolio strategy of the company without affecting an internal architecture based on internal SOA implementation. The key point is that we don’t need to build as universal service as possible, supporting as many usage scenarios as possible. Instead of this, we can follow a “Value-Up Paradigm” [GS00] of building modern software, delivering changes in an agile way, thus being able to support continuously changing business requirements. The recommended behavioral pattern for building EAS is the Mediator Pattern [CJ00], which promotes looser coupling between the components.

2.2.2 Internal Application Services

Internal Application Services (IAS) build the core business functionality served by our application. They allow well-defined business workflows to run and exchange internal messages. But the most important characteristic of those services is the ability to change the logic of services without affecting the existing architecture. In this way, the application is out of the box extensible, thus ready to support different business scenarios caused by e.g. law regulation or marketplace situations for the same business process. The best approach to achieve this aim is to support the COP (Component Oriented Programming), which allows easily separation of interfaces and implementation [LJ00]. The recommended behavioral pattern for building IAS is the Strategy Pattern [CJ00], which consists of a number of related algorithms depending on a specific context.

2.2.3 Basic Application Services

Basic Application Services (BAS) serve the basic functionality, which covers such processes like adding, updating, deleting and filtering of business entities. These services should be based on well-defined application framework with well-known interfaces.

2.3 Messages

Messages are exchanged by the services involved in SOA. The key problem of a message definition is to keep it simple, consistent, extensible and strong typed. In case of external SOA implementation, our services act only as service providers (the service consumer is the middleware) so our message should have a well-known and deterministic syntax. External SOA message should consist of a context that defines all processes involved together with data needed by those processes. Additionally it should contain a definition of expected return values and behavior in case of eventual exceptions. The internal SOA message does not have to follow this pattern and it is allowed to be more process and technology oriented. The most common way for analyzing and describing business processes and thus recognizing types of messages is the usage of Petri Nets. Petri Nets is a formal and graphical appealing language which is appropriate for modeling systems with concurrency and resource sharing [UH00].

3. Conclusion

Extended SOA is a pattern for implementing SOA enabled application in a big organization within existing business processes, technologies and infrastructure. To keep the idea simple, I didn’t mention any special technology or platform (like web services are) because they are only tools to achieve the aim. The key concept of the Extended SOA Pattern is to have “two-in-one” SOA implementations, i.e. internal and external SOA together, thus enabling communication of loosely coupled services and their extensibility in a much wider scope as when we would have only one.

About the Author

Adam Boczek has over 10 years of experience with enterprise architecture and software development projects. He holds a master's degree from Technical University of Szczecin in Poland and is a Microsoft Certified Application Developer (MCAD) using Microsoft .NET Framework. He is a LogicaCMG senior consultant and he works currently for Shell Company in Hamburg, Germany as the New Architecture Technical Lead.


  • [CJ00] Cooper, J.: C# Design Patterns, USA 2003, Addison-Wesley
  • [GS00] Guckenheimer, S.: Software Engineering with Microsoft Visual Studio Team System, USA 2006, Addison-Wesley
  • [HJ00] Hasan J.: Expert Service-Oriented Architecture in C#2005 Second Edition, USA 2006, APress
  • [LJ00] Lövy, J.: Programming .NET Components Second Edition, USA 2005, O’Reilly
  • [UH00] On-line Resources: Petri Nets World, University of Hamburg, 2006


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Adam Boczek
Web Developer
Germany Germany
Adam Boczek has over 10 years of experience with enterprise architecture and software development projects. He holds a master's degree from Technical University of Szczecin in Poland and is a Microsoft Certified Application Developer (MCAD) using Microsoft .NET Framework. He is a LogicaCMG senior consultant and he works currently for Shell Company in Hamburg, Germany as the New Architecture Technical Lead for Fuels Pricing System. He collects historical typewriters, loves flyfishing and modern software architectures.

You may also be interested in...


Comments and Discussions

GeneralI like SOA, but not Acceptence of middleware Pin
twesterd8-Jan-07 20:32
membertwesterd8-Jan-07 20:32 
I come from a large organization with over 750 locations and thousands of users. From your article, the inference is that multiple platforms, multiple applications and middleware "translators" are somehow logically smart, feasible, and desirable using SOA.

I, personally, think the most prudent and favorable opportunities are usually overlooked or downright rejected. Too many managers and "experts" search the software market for "modules" of supposedly "pluggable" components that snap together into an overall solution for an organization. They consider these modules like video cards and hard drives for computers. What they “miss” is that much like the selecting the latest greatest video card is the fact that its often not compatible with the motherboard. So, they end up suggesting the “middleware” interface or “translator”. How common is it for a company to choose a general ledger accounting “module” and then try to interface that module with their operations software. I have watched over the last 20+ years as each new technology release or programming model promises to finally and magically end these problems. Frankly, what a load of bull!

Each company responsible for the continued development of their respective applications (modules) will go through a series of minor updates and then a major update (these rarely align between the respective modules). Each minor update virtually always leads to significant effort to keep the middleware functioning. The major update, obviously, leads to major headaches. Furthermore, the infrastructure required for each application module usually grows into ridiculous. Separate DB administrators, business analysts, programmers, software licenses, hardware, security implications, documentation, and – of course – the teams needed to create and mange the middleware.

Most of the time, if thought out properly, the correct choice is to integrate into one application and dump the separation of modules. Of course certain “true” business services will still be needed and cannot be integrated such as running credit checks and obtaining credit reports. However, if your business has separate distinct application modules that are not a service received from a third-party (like the credit reports) and the middleware is all internal, then you work for an organization full of incompetence. Sorry – not pulling any punches here.

Seriously, a small team of competent developers can create, develop, and replace nearly any application/ module within 2 years or less. If they can’t, they are not competent and/ or are required to follow ridiculous SDLC (Software Development Life Cycle) policies- see this article because I couldn’t agree more:

What steps does it take for a small change to get implemented? Its one thing to not simply allow small changes to break an application and another to require 200+ documented steps, emails, transfers from one group to another, meeting after meeting, and end up with 6-9 months before a small change gets implemented.

Honestly, the correct solution for most clients seeking SOA as an answer to middleware problems is not SOA; it’s the consolidation of modules and the complete elimination of the middleware and its associated communication channels. This doesn’t happen often because of the points pointed out in the article I linked. The wrong people are making the wrong decisions and have built up a bloated and lethargic development team. I feel sorry for every great developer who has their hands tied within such an organization. If you ever want to test this theory, then grab the best practicing developer in the organization and let them compete against a team with “no strings” attached (none of that garbage SDLC). I will wager that the single developer will produce 5 times the output and the result will be of significantly better design.


GeneralShort but to the point Pin
Herre Kuijpers8-Jan-07 0:10
memberHerre Kuijpers8-Jan-07 0:10 
GeneralRe: Short but to the point Pin
Adam Boczek8-Jan-07 7:38
memberAdam Boczek8-Jan-07 7:38 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Terms of Use | Mobile
Web03 | 2.8.171020.1 | Last Updated 7 Jan 2007
Article Copyright 2007 by Adam Boczek
Everything else Copyright © CodeProject, 1999-2017
Layout: fixed | fluid