Terça-feira Mai 19, 2009

SOA e-mail discussion group

Hello people

There is an SOA group on yahoogroups. To participate, send an blank e-mail to service-orientated-architecture-subscribe@yahoogroups.com

João Sávio

Terça-feira Abr 21, 2009

SOA: An Overview

I. Motivation

  • Reuse systems

  • Standardization of communication between systems enabling integration


Definition: paradigm for the implementation and maintenance of business processes that are in large distributed systems. But we can also think of SOA as a layer that provides a higher level of abstraction based on the Object Oriented paradigm (OO). It has as keywords: interoperability, loose coupling and services.


Interoperability is achieved through an enterprise service bus (ESB) that we can see in the representation below:

 The ESB would be the highest layer of abstraction that has several responsibilities, such as:

  • Provide connectivity

  • Transformation of data

  • Routing (smart)

  • Dealing with security

  • Dealing with reliability

  • Management services

  • Monitoring and logging

The idea is that all systems are integrated through the enterprise service bus. For example, if you have a system made in PHP, but your company currently uses Java, it is not necessary to completely change the old, but provide an integration of the them through an ESB for example.

Loose Coopling

In turn, loose coupling is related to the reduction of dependency of the system, minimizing the effects of changes and failures. We can illustrate this in the Object Oriented Programming with a class tight and one loose coupled:

public class classTightCoupling {
    public String name;
    public int age;                   

public class classLooseCoupling {
    private String name;              

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

In the first class, if you have an object, simply do nameOfObject.name = "something" to change the value of the variable. In the second class, the access to the variable "name" can only be done by the methods setName and getName. That is good! It may seem silly in these small examples, but imagine if you have an giant API that has rules to change the values of its variables. If this API was tightly coupled, there would be a great dependence between her classes and those that you were using, because anyone could modify the variables in any way and this could affect the outcome completely.

But, back to our world of SOA, we can use the loose coupling in various situations:

  • Asynchronous Communication - this means that the sender and recipient are not synchronized. This is good because the systems that are exchanging messages don't need to be online at the same time.

  • Iteration Patterns - only string are supported or other data types too? Structures? Arrays? Lists? Objects? Inheritance and polymorphism? Well, the more complex is the data type, the more your system is tighly coupled. For example, if you use objects to exchange messages, only the object oriented languages may participate in the integration.

  • Compensation - it's related with the security in the transaction. If you have to update two backends, how to deal with the problems if only an update was successful? Usually the commit is made of two stages, i.e., backends are updated at the same time. But, the more loose coupled and that ensures the overall consistency is change the backends separately. If only an update is successful, you can reverse it to the previous situation and send an error message, for example.

  • Control Logic Process - if you have a central controller, the failure of a component will stop all the process. Moreover, reducing the coupling, i.e., making a decentralized control, you eliminate this problem.

We only have mentioned advantages of loose coupling. But, there are also disadvantages, because the more a system is loose coupled, it is more complex. Therefore, it is up to you decide how much you're willing to pay for it.


The third key word is "services" that can be defined as a piece of an independent corporative functionality. There are three types:

  • Basic Services - there are basic services of data and logic. For example: create a new user, change a user, returning the age of a registered person, say if a year is leap or not, etc. They belong to only one type of backend.

  • Composite Services - they are services that are composed of other services, and usually multiple backends. In SOA, composing new services from existing ones is called orchestration. As in an orchestra, you combine "instruments" to perform different tasks more complex than those possible with only one. These services are still considered without states and with rapid execution.

  • Process Services - these are called workflows. These services contain states and sometimes need to use multiple sessions. Using a shopping cart as an example, we have one for each client, i. e., a session service for each one. And we have many possible states, because the service has to save the order when the client is looking for more products, finalizing the purchase when the confirmation is made, wait for confirmation of payment and complete the order only when the product is delivered.

III. Conclusion

In this article, we set and talk about the basics of SOA, it is essential to understand Web Services and other types of modeling practices.

IV. References

  • JOSUTTIS, N. M. SOA in Practice – The Art of Distributed System Design. 2008.



« Julho 2016