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.
No comments:
Post a Comment