Currently I’m part of local SOA group. Purpose of it is to accumulate information about SOA and its implementation, to talk and discuss different approaches that could be applied with this paradigm of developing software. I volunteered to prepare first introduction presentation. So other more experienced guys will prepare more deep presentations. Right folks? ;)

What is SOA?

Over internet you could find lot of different definitions to SOA. One of the most simplest is:

Service Oriented Architecture is an architectural style of building software applications that promotes loose coupling between components for their reuse.

Term itself could be a bit confusing, because it combines two different things. First two words describe software methodology – how to build software. Third word, architecture, represents picture of company’s assets, which all together should build a good building. So, in other words, we could say that SOA is strategy that forces building software assets in business using service-oriented methodology.

Wikipedia gives more complex definition:
A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.

SOA is not simply IT solution, it is whole paradigm shift. It is another step to the IT industry dream, when we will not need write low level code, but just combining different ready components to have product which is good for immediate selling. It is about describing, building, using and managing your IT environment with focus on services and capabilities it provides rather then on concrete technology used for that.

Advantages both for Business and for Development

Before we start with what stands behind SOA lets first take a look on advantages that it brings for Business and Development process.

Advantages of service-oriented development:

Software reuse is one of the most commonly used arguments to justify SOA. If services are developed of good size and correct scale they could be reused. Consider that you company has for sailing departments, each of them works with orders, so all of them have code that checks customers credit card, books order and so on. But checking credit card is almost 100% the same task in all departments, so developers could gather code and make it shared for all systems, in this case software reuse is accomplished. All that we need to have in our systems is client that is able to consume service. Systems are no longer concerned about the internal verification process. In future is company will create new department it will just reuse existing service, so development time will be saved and money for business.
But we could not say that reuse will be accomplished everytime. First of all service should be of right size, not to big and with correct scope. This meas that we will not be able to use ‘verify credit card and book that car’ in department where they sale phones. I also found that by only from 10 to 40 percents of services are reused. This adds additional requirement to implementers to be accurate with choosing correct scope and size of service.
Productivity increase. That is easy, once we achieved re-use system, we could not spend our time on implementing same things, testing them. We only need integrate services and do integration testing, so this becomes more cheaper.
Increased agility. Even if re-use will not be achieved we anyway get additional agility with having services. For example our selling department has divided whole process into few services, like ‘check user’, ‘check credit card’, ‘get order’, ‘ship order’… And if will need change in process we could do this in isolated island of concrete service. That is how we get more flexibility.    

Advantages of SOA strategy are:

Better alignment with business. Business people can now imagine how their business are constructed in terms of technology. Once they better understand how application is built they could promote their requirements to development teams in more efficient way. And as well development team is now more suitable with understanding of what does that business really do. It is now much easier to explain why having credit card in one service is good decision.
A better way to sell architecture to the business. Having gap in understanding how all is really implemented was also a preventing thing to sell IT product to the business.

What are services?

So we talk about services. But what exactly are those services?
Service is complete self-contained component, that provides defined tasks. List of tasks could be obtained by consumer using agreed contracts. Consumer should not know about internal implementation of service. Communication between consumer and service should be done through platform and language independent contracts.

Here is list of just mentioned properties of good Service:

• Self-contained module that performs a predetermined task
• Software components that have published contracts/interfaces
• Black-box to the consumers
• Platform-Independent
• Language-Independent
• Operating-System-Independent
• Interoperable

Main Architecture Concepts

On the picture below we see how three main parts of SOA interacts with each other.

Loose coupling – Services maintain a relationship that
minimizes dependencies and only requires that they maintain an awareness
of each other.
Service contract – Services adhere to a communications
agreement, as defined collectively by one or more service description
documents.

Service abstraction – Beyond what is described in the service
contract, services hide logic from the outside world.

Service reusability – Logic is divided into services with the
intention of promoting reuse.

Service composability – Collections of services can be
coordinated and assembled to form composite services.

Service autonomy – Services have control over the logic they
encapsulate.

Service optimization – All else equal, high-quality services
are generally considered preferable to low-quality ones.

Service discoverability – Services are designed to be
outwardly descriptive so that they can be found and assessed via
available discovery mechanisms

How could it be implemented?

Since SOA is technology independent we currently have really lot of different possiblities to implement it. So this could be simple Web service, which sends data packed into XML with help of SOAP, at the same time contracts are established with WSDL. Possibility to discover available services could be UDDI.

We could also realize SOA with REST, DCOM, CORBA, DDS and other things.

Also Microsoft has its solution for the SOA which is WCF. It is very great tool to develop distributed application. I’m glad that already have at least some experience using it.

What
are SOA Patterns?

Here is very good site on disign patterns applicable with SOA.

Mistakes when implementing SOA

There are lot of mistakes that could appear when you are trying to introduce SOA in your project. They are listed in Twelve Common SOA Mistakes pdf.

I hope that I will be able to provide a good presentation, since I don’t feel myself to be professional in this area and don’t have enough required background, except of few months using WCF.