 This is second part of a two-part article series. The first part is published at EAI and SOA - Part I. Data Model As previously stated, the data model in EAI deserves a separate chapter. A common mistake in systems integration is to transfer their job is requirements as the systems communicate. It is common to hear from integration teams, "they are only the pipe, and don't care about what's going on inside it". In fact, the integration concerns the exchange of information (represented by your data) between systems. This is your goal and that is what adds value to the business. This is only possible through communication, but if the information exchanged are incorrect, or simply arrive at the wrong time, they will be worth nothing to your business. Therefore, an old diskette sent by regular mail with the correct information recorded and delivered at the right time is worth more than the most complex Web service, running at best SOA suite on the market, but that has the wrong information. Defining the format and content of the data bus is important because handling this data is the objective of any integration. However, defining a data model for the bus is a difficult task because they should be attached to the definition that each entity has to business processes. To create this model, we must first understand and document the business process, which is a time-consuming and complex task involving interactions with the various areas of the company. This also implies that the areas need to be familiar with their business processes, which unfortunately is not usual. Moving forward, this bus data model will be named "corporate data model". When using the systems data model in integration we can see that for simple integrations involving only two systems, it may be easier, but for more complex problems involving more than two systems, the mapping grows exponentially and using the corporate data model becomes easier and faster. The problem is the complexity of interfaces always tends to increase, and simple interfaces become complex. In addition to the complexity of mapping, there are more reasons to use a corporate data model. The main reason is that each system has its vision of the data. In a large organization, various systems are used for specific functions and do not always represent the vision of the company as a whole. When we take the data model of a specific system we became hostages of that vision, but with time we end up having to modify it to meet our needs. This creates a hybrid model, which is no longer the original system model, but doesn't correctly fit our needs because it was created with a limited view of the data. When this occurs, the benefits of using the system model are non-existent. When we decide to begin creating a corporate data model, we can cast it to our needs, and we end up creating a global vision of information. This will influence the new systems that are developed or integrated; creating a virtuous cycle that reduces the effort of integration and facilitates the understanding of the business process. Business Process Model Lately, there have been discussions about BPM leading to my opinion that it should be considered a major evolution in systems integration. However despite this, the concepts are not new and already existed since the first EAI systems were designed. The key technology for building BPMs is the state diagram, which allows business process to be represented and carried out by the systems. They are the key parts of the processors in the business layer, controlling the state of each request, storing information, implementing and monitoring tasks (manual or automatic), and allowing the business processes to be realized by the integration system. In old EAI systems business was built on state diagrams, which use a technical language, requiring a professional with knowledge of a programming language and causing the business analyst, who knows the company's business process, to pass this information to the programmer to build the corresponding state diagrams. After construction, the system maintenance also needs to be done, i.e. whenever the business process changes, the business layer also needs to be changed. This entire process generates inconsistencies due to flaws in understanding, and the dynamics of change end up causing the updates not to be replicated to the integration. There are advantages in using the BPM systems and standards. An advantage to this system is that in addition to implement state diagrams, it also allows the construction of business diagrams using a language that enables the business analyst to define their process. These are mapped directly to the systems without the need for a programming layer. The evolution of these systems will soon be how business areas retain their processes, reducing the cost and time of change and minimizing the flaws. This development combined with the new tools incorporated to BPM systems, such as the control of human workflows, rule engines and business monitoring, will give companies an agility and quality never before achieved. There is another point in favor of using a corporate data model; this model will be the common language that will be used by business processes to exchange information. Without this common language, it is impossible to construct business processes that consider interactions between the various areas of the company. EAI & SOA Conceptualize the main components and objectives of EAI; this will better your understanding of the interaction between EAI and SOA. However, we still need to introduce some concepts about SOA and clarify some common confusion in the market. Web services and SOA are two completely different concepts. SOA is a set of concepts used to create an architecture and Web service is a standard for remote communication between systems. Typically, the SOA architecture is implemented through Web services, but the concept of service does not specify the technology, and there are numerous other technologies that can be used for implementation.
Web service is a communication standard that uses XML messages validated by XSD schema definitions, it usually exchange information using the HTTP(S) protocol. It is supported by most existing application servers on the market today by being across all operating platforms, and turning to be the principal pattern for communication, especially between heterogeneous platforms. A service is a real world action provided through a specification and governed by restrictions and policies established through a contract. The technology used to build a service doesn't matter, as there are other additional concepts. The most important is isolation: the consumers of the service do not need to know what will happen internally, but only the information in the service description.
With these concepts in mind, we can now try to understand how SOA and EAI interact, and what the relationship between them is. Moving forward we will be using Web services to exemplify services, but always keep in mind that could be replaced by any other similar technology. Communication Services Within our EAI infrastructure, Web services can be found in two ways: 1. When systems provide Web services as part of your infrastructure 2. When the integration bus provides the Web services. Let's see these two case in more detail:
One important point is that these services are in communications layers, so they are called "communication services". If we want to build a service in the business, the service starts to become more interesting, and similarly to the other layer, we will call then "business services". Business Services We saw that in this layer, the tasks performed are the company's business processes, and the data model is the corporate model. Then we have a service that performs the business process, using common definitions adopted for the company. More importantly, this process is independent of the systems that are connected to the bus, because whatever they need, the business process will forward the request to the correct platform, and the communication layer will be responsible for making the requests to the correct system. Existing services in this layer are quite powerful, because they correspond to the official process of the company. They are not changed by infrastructure problems and changes, and are independent of the systems that will execute the request. Then, once the clients are using one of these services, they will know that the task will be performed correctly and homogenously, and that if a business process is changed, the new version will be automatically used by all clients simultaneously. The goal of a SOA infrastructure: build a set of services that execute business rules, and that can be used by client applications, enabling a homogeneous and centralized vision of business process by abstracting the technical details, and ensuring that corporate objectives are achieved. Let's see the almost final model of our integration architecture: The final goal of SOA is to use only business services; it no longer makes sense to have communication services with the same functionality published to clients. Then the communication services exist only for the integration bus to use in communication layer. However, we know that the Web services are not very efficient compared to other technologies. Its main advantage is compatibility, but if we have only the integration bus performing calls, this advantage is no longer relevant, and we can return to using other technologies more efficient to communicate with systems With this change, we now have the final model of the integration architecture: With this change, we now have the final model of the integration architecture: With the implementation of business services, a problem occurs for the applications to call business services using the corporate data model, they will have to make mapping from its data model to the corporate model, and vice versa. This adds to each application a level of complexity that only exists because of SOA architecture, which was previously provided by EAI. Each system has its degree of complexity and flexibility to deal with this problem, and there is no definite rule for its resolution, but some guidelines can be followed:
In this case, a possible solution is to build a mapping service that could receive data in the system model and return in the corporate model and vice versa; being treated as another service provided by integration. It may seem interesting at first glance, but this approach has performance and availability constraints that need to be addressed very carefully before implementation. Always remember the basic concepts of integration: there are no simple solutions to complex problems. Conclusion In this document, we review the history of EAI, and describe the main blocks that make up its structure, showing where and how SOA infrastructure is connected to. With this vision, we can realize that rather than replace the integration, service oriented architecture fits and complements the integration architecture and the modern "SOA Tools", despite having many conceptual and technical enhancements, have all components before presented in traditional integration tools, and in reality exists as an evolution of then. The conclusion therefore is that the two visions were complementary and fundamental for the construction of a system architecture that meets the needs of a modern company, using the new features and functionality without forgetting the old concepts and standards, by taking the best advantage of each one and fulfilling its role of bringing agility and quality for business. |
