Introduction
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.
Every SOA solution requires service consumers, which send requests, and service providers, which send responses on requests:
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.
Endnotes
- [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
http://www.informatik.uni-hamburg.de/TGI/PetriNets/
