Friday, June 5, 2009

Enterprise Service Bus (ESB): a critical part of SOA

SOA deployments could end up having large number of services and similar number of servers hosting these services. Such system would have many business process servers, coordinating the business activities using available services. It may also have several web/application servers and other systems to provide user interaction, etc, which communicate with various services hosted in the deployment. Such SOA deployment would look like the below diagram, where there are large number of components and even larger (possibly unmanageable) amount of interconnections.

Figure 1: A deployment with front end web servers, process servers running various business processes and set of servers with business systems (e.g. HR systems, inventory). Note that these business systems may be wrapped as services (e.g. web services).

It's obvious that an improvement is needed for such deployments. But, let's first consider the problems with this type of system. In this deployment, each and every component (service, BPMS, web server, etc) is directly connect with other components. So if we want to change one component (e.g. move a service to a different server), we have to reconfigure all the components connecting to that component. Another major problem is that, it is very difficult to get an idea about how different components are interconnected, once the system is deployed. We have to study the connections between each and every component (by examining their configurations, etc) to get a complete view on the system. Therefore, troubleshooting the deployment and introducing new components would be a tremendously painful process. Added to these complexities, we have very limited control over the messages passed between the components. For example, different components may react differently to failures and components may use different payload formats and other attributes.

So it is clear that we have a problem. One part of the problem is due to the large number of components making up the SOA deployment. We can't do much to prevent the number of components from growing, as it is a natural consequence of expanding the business units or organizations. But, of course, we can do a lot to better organize and manage the growing number of components, which I am hoping to discuss later. For now, let's consider the other part of the problem. That is the exponential increase of connections between components. There is a neat way of solving this problem, which addresses almost all the problems mentioned above and also provides lot more benefits. That is to use an Enterprise Service Bus (ESB) as the backbone of all the communications of the SOA deployment. The simple idea is:

(1) Do not make direct connections between components
(2) Connect all the components to an ESB (or to multiple ESBs)
(3) Configure the ESB to route messages between components

Again, there are no strict rules. Decisions like how many ESBs to use in a deployment, how to configure ESBs, whether a direct link is preferable in a particular situation, etc are mostly depend on the requirements of the deployment. Let's consider how we can construct above architecture using the WSO2 ESB. We can easily build this using the feature called proxy services, which acts as a virtual service hosted in the ESB. Once a proxy service is configured, it provides an endpoint similar to a real service, so that external parties can invoke it. But internally, the ESB can be configured to do whatever we want with the message. In this case, what we can do is to create proxy services for all the components in the SOA deployment and configure those proxy services to direct the messages to the actual services. Then we have to configure all the components to interact only with the proxy services defined in the ESB. So we effectively end up with the architecture mentioned in above 3 steps. SOA deployment after the introduction of the ESB is shown below.

Figure 2: SOA deployment after introducing an ESB. Note that two new components, an administrative server and a central log is added, which are difficult to support without this type of architecture.

So, how do we gain advantages over the previous deployment. In this architecture, all the interconnections are handled through the ESB. Therefore, if we want to relocate a component, it is simply a matter of changing the configuration of its proxy service. We don't have to touch any other components. The next problem is getting a detailed view about all the interconnections in the SOA deployment. In this architecture, all the messages are passed through the ESB. Using the ESB configuration, we can enable logging at all required points with necessary level of details. These details could be client address, target address, message type, etc. Then we can analyze these logs (with the support of visual tools) to get an in-depth knowledge about interactions in the SOA deployment. Next, we can easily impose constraints on message formats passing through the ESB. ESB can be configured to examine all or required set of incoming/outgoing messages and perform desired corrective actions on malformed messages. These actions may include reformatting the messages on-the-fly, dropping the message and sending an error message to the client, blocking the client and informing an administrative service, etc. This type of ESB based deployment also gives us more control over the errors and failures within different components of the SOA deployment. Different components may react differently to errors occurred while processing requests. But in this type of deployment, all those error messages (possibly in different formats) are sent to the ESB. So we can gain overall control of such failure situations and configure the ESB to take necessary actions. These could be one or combination of actions like redirecting the request to another similar component, temporarily block the failed component, sending an error message to the client, logging the error according to standardized format, etc. Whatever the actions are, they can be configured centrally with a clear view of the overall architecture, so that the SOA deployment reacts consistently and gracefully to failures.

Use of ESBs could provide much more advantages to SOA deployments than mentioned here. But if a SOA deployment is experiencing the problems addressed above, it is time to start evaluating how an ESB fits in to the picture.

A simple introduction to SOA

Organizations use software systems to improve their operations, in terms of productivity, accuracy, reactivity, security, cost, etc (of course, some of these points are interrelated). But the problem is that, there is no strictly defined way of how to use software in various business operations. And the worst part is, you may not achieve anything or may even make it more complex and inefficient, if software systems are not used appropriately.

What usually happens is that individual and isolated areas of the business will be automated using software systems. These can either be broad areas like customer handling, HR management, inventory control, etc or small and more specific sections. Organizations may use commercial grade systems like CRM systems, SCM systems and inventory control systems to automate some of these areas and may use outsourced or in-house developed software systems for more specific business tasks. At the end of the day, what it has is a set of independent software systems working in isolation to perform individual business tasks of the organization. This method works fine and may introduce some improvements for the business as well. But if you think carefully, there is a huge potential for further improvement, which can be tapped by going only one step forward. That is to integrate of existing systems and make them work collaboratively.

So, how do we achieve this? There are many systems developed by different vendors and also custom built systems. Possibly, they have different interfaces and different data formats. And how do we establish a flow of control/data among these systems to make them work collaboratively. Hold on, this is where SOA can help you.

Again, how SOA can be used in a particular environment varies according the nature of the problem, scalability concerns and many other factors. Simply, there are no hard and fast rules on how you should use SOA. But we can use a simple example for explaining a application of SOA. Let's consider a online book store. Book store has a web site for browsing and ordering books, an inventory system, a shipping system, payment system, etc. A trivial way to develop the online system for the book store is to build a web based program (e.g. JSP/servlets), which accesses all other systems and perform all the business operations. One problem with this approach is that the web based program has to access each and every system using their specific interfaces, which requires separate client modules for all those systems. And if there is a need to do a simple change to the business operation, we have to change the program and redeploy it. And the worst part is yet to come. Let's say we want to introduce another business process involving these systems. Then we have to write a new program from the beginning. Even though, we go for something similar to three tier architecture and separate the web interface and the business logic, there won't be much difference. This situation is illustrated below.

So how could SOA improve this scenario? As the first step of SOA, we need to identify units of functionality in our systems and make them services. For simplicity we can assume each system (inventory, payment system, etc) as a single service. But in real-life situations, we might identify multiple services in a single system or expose features of multiple systems as a single service. Once services are identified, we have to implement them as standard services. One recommended way is to implement them as web services. There are many products to help you in creating and deploying web services and automating this process in various levels. WSO2 Web Services Application Server can be very useful in this phase of SOA implementation. These web services should wrap the existing systems (hiding their internal complexities) and expose well defined and required functionalities. Once this step is completed, we have a set of services, which have well defined functionalities (using WSDL) and communicates using a well known protocol (e.g. SOAP).

Next step is to make them work together to perform business operations. Business Process Management Systems (BPMS) can be used for this purpose. We can define a business process by specifing how the control flows between different systems (and users) and what data is used for input and output of each system. Once a business process is defined, we can deploy it in a BPMS and the BPMS will expose our business process as a service. So, the only thing that our web interface has to do is to call the service exposed in BPMS with required parameters. Again, there are many BPMS products, which can be used for this purpose. Specially, the WSO2 Business Process Server provides many features to simplify the deployment and management of business processes.

Now, let's examine how this SOA based approach improves the process over the previous methods. First, we have standardized the interfaces of all the systems. Therefore, other systems can communicate with these systems with same protocol (same client modules). And their functionalities are defined in well known format (WSDL), so that any third party systems can understand what they exactly do. Then, we have moved the business logic to a BPMS. Business processes are defined using text based files in BPMS. So it is very easy to change and redeploy business processes according to the changing requirements. Most BPMS have graphical interfaces to simply this process further. Introducing a new business operation is also straight forward in this environment. We just have to write a new business process definition and deploy it in the BPMS. It already knows how to communicate with existing systems (as they are exposed as web services) and all the infrastructure is already in-place for execution. This is shown in below diagram.

This is only a simple example of how SOA can help you in improving the business operations. As I mentioned earlier, how we can (and how we should) apply SOA varies greatly based on the scenario and other conditions.