We will try to introduce this book with a simple, brief, and concise discussion of SOA, talking about its origin and what it means. We will discuss the facts or problems that large companies with a huge IT system had to face, and that finally gave rise to the SOA approach.
Once we know what we are talking about, we will introduce the WSO2 technology and describe the role it plays in SOA, which will be followed by the installation and configuration of the WSO2 products we will use.
So, in this chapter, we will deal with the following topics:
- A basic knowledge of SOA
- Download WSO2 Enterprise Integrator
- WSO2 Update Manager (WUM)
- Update with the official Patches
- Set up WSO2 Enterprise Integrator
- Start Enterprise Integrator
Service-oriented architecture (SOA) is a style, an approach to design software in a different way from the standard. SOA is not a technology; it is a paradigm, a design style.
There comes a time when a company grows and grows, which means that its IT system also becomes bigger and bigger, fetching a huge amount of data that it has to share with other companies. This typical data may be, for example, any of the following:
- Sales data
- Employees data
- Customer data
- Business information
In this environment, each information need of the company's applications is satisfied by a direct link to the system that owns the required information. So, when a company becomes a large corporation, with many departments and complex business logic, the IT system becomes a spaghetti dish:
The spaghetti dish is a comparison widely used to describe how complex the integration links between applications may become in this large corporation. In this comparison, each spaghetti represents the link between two applications in order to share any kind of information.
Thus, when the number of applications needed for our business rises, the amount of information shared is larger as well. So, if we draw the map that represents all the links between the whole set of applications, the image will be quite similar to a spaghetti dish. Take a look at the following diagram:
The preceding diagram represents an environment that is closed, monolithic, and inefficient, with the following features:
- The architecture is split into blocks divided by business areas.
- Each area is close to the rest of the areas, so interaction between them is quite difficult.
- These isolated blocks are hard to maintain.
- Each block was managed by just one provider, which knew that business area deeply.
- It is difficult for the company to change the provider that manages each business area due to the risk involved.
- The company cannot protect itself against the abuses of the provider. The provider may commit many abuses, such as raising the provided service fare, violating service level agreement (SLA), breaching the schedule, and many others we can imagine. In these situations, the company lacks instruments to fight them because if the business area managed by the provider stops working, the impact on the company profits is much larger than when assuming that the provider abuses.
- The provider has a deeper knowledge of the customer business than the customer itself.
- The maintenance cost is high due to the complexity of the network for many reasons; consider the following example:
- It is difficult to perform impact analysis when a new functionality is needed, which means high costs and a long time to evaluate any fix, and higher costs of each fix in turn.
- The complex interconnection network is difficult to know in depth.
- Finding the cause of a failure or malfunction may become quite a task.
- When a system is down, most of the others may be down as well.
- A business process is used to involve different databases and applications. Thus, when a user has to run a business process in the company, he needs to use different applications, access different networks, and log in with different credentials in each one; this makes the business quite inefficient, making simple tasks take too much time.
- When a system in your puzzle uses an obsolete technology, which is quite common with legacy systems, you will always be tied to it and to the incompatibility issues with brand new technologies, for instance.
- Managing a fine-grained security policy that manages who has access to each piece of data is simply an uthopy.
Something must to be done to face all these problems and SOA is the one to put this in order. SOA is the final approach after the previous attempt to try to tidy up this chaos.
We can take a look at the SOA origin in the white paper, The 25-year history of SOA, by Erik Townsend (http://www.eriktownsend.com/white-papers/technology). It is quite an interesting read, where Erik establishes the origin of the manufacturing industry. I agree to that idea, and it is easy to see how the improvements in the manufacturing industry, or other industries, are applied to the IT world; take these examples:
- The hardware bus in motherboards has been used for decades, and now we can also find the software bus, Enterprise Service Bus (ESB) in a company. The hardware bus connects hardware devices such as microprocessors, memory, or hard drives; the software bus connects applications.
- A hardware router in a network routes small fragments of data between different nets to lead these packets to the destination net. The message router software, which implements the message router enterprise integration pattern, routes data objects between applications.
- We create software factories to develop software using the same paradigm as a manufacturing industry.
- Lean IT is a trending topic nowadays. It tries, roughly speaking, to optimize the IT processes by removing the muda (Japanese word meaning wastefulness, uselessness). It is based on the benefits of the lean manufacturing applied by Toyota in the '70s, after the oil crisis, which led it to the top position in the car manufacturing industry.
- We find an analogy between what object-oriented language means to programming and what SOA represents to system integrations as well.
- We can also find analogies between ITIL V3 and SOA. The way ITIL V3 manages the company services can be applied to managing the SOA services at many points. ITIL V3 deals with the services that a company offers and how to manage them, and SOA deals with the service that a company offers to expose data from one system to the rest of them. Both the conceptions are quite similar if we think of the ITIL V3 company as the IT department and of the company's service as the SOA service.
There is another quite interesting read--Note on Distributed Computing from Sun Microsystem Laboratories published in 1994. In this reading, four members of Sun Microsystems discuss the problems that a company faces when it expands, and the system that made up the IT core of the company and its need to share information. You can find this reading at http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.48.7969&rep=rep1&type=pdf.
In the early '90s, when companies were starting to computerize, they needed to share information from one system to another, which was not an easy task at all. There was a discussion on how to handle the local and remote information as well as which technology to use to share that information.
The Network File System (NFS), by IBM was a good attempt to share that information, but there was still a lot of work left to do. After NFS, other approaches came, such as CORBA and Microsoft DCOM, but they still keep the dependencies between the whole set of applications connected. Refer to the following diagram:
Finally, with the SOA approach, by the end of the '90s, independent applications where able to share their data while avoiding dependencies. This data interchange is done using services. An SOA service is a data interchange need between different systems that accomplishes some rules. These rules are the so-called SOA principles that we will explain as we move on.
