Integration Service Mastery plays a backbone of an enterprise which is based on EAI/ESB solution such as Vitria’s BusinessWare or JBOSS. ISM provides more efficient development environments than existing EAI/ESB tools for enterprise application integration. By the consolidated web console, a user can easily develop and manage interfaces without writing additional codes which makes ISM also reduce the development time and efforts of the enterprise. Through more than dozen years of integration experience, it has proved itself an efficient tool in integration projects. The main goal of ISM is to provide easy and convenient integration solution to the clients with pre-developed functions and interface services.
The benefit of the EAI/ESB tool is to enable the integration service with less development efforts. However, it also has limits to satisfy customer specific requirements for performance and functions. After the EAI/ESB solution is implemented, additional development processes will be followed to meet the user requirements. After all, the merits of using the tool fade away while the inserted API takes its place. Even though the EAI/ESB solution is better in productivity and liability to the development without it, in the long term, it may require additional maintenance work. Because the level of maintenance technicians depends on the program, there must be more technicians in need besides EAI/ESB experts.
The clients have tried to minimize the risks of integration by standardizing the development process, but it couldn't satisfy detailed user requirements. The problems cannot be resolved by standardising program level or hiring skilful technicians. Specific user group could have enough skillful technicians to handle this problem, but the others could suffer the lack of them. Integration consulting companies or SI service providers or development companies who understand this problem may want to avoid to struggle repeatedly with the same issues for every new project.
In other words, the users are facing the same integration problem, and the problems are handled in similar way but separately. The best solution for this kinds of problem is to provide them a more than a product, a program or package satisfying the user requirements for performance and functions. However, even though the integration product service providers provide the essential functions for integration, they do not have much experience on specific requirements so they have a difficulty to provide it as a product which reflects the development. In the awareness of the problem, ISM built up the experience of implementation of multiple user groups into the functions, and the interface services are provided by easy configuration not development.
ISM not only provides the general communication protocol level of integration such as socket, FTP, DBMS, but also provides an easy and efficient integration development and management environment for any specific application. Additionally, ISM provides the proved program as the integration backbone of enterprise satisfying the functions, performance, and liability.
ISM integration service embodies the main features and functions of EAI/ESB products, which has evolved in the last 10 years, and this solution is to overcome the constraints of integration using EAI/ESB tools. This chapter presents you the detailed information of ISM and compares it to the other integration solutions..
Before EAI/ESB, the data and application integration between the systems was in need. Because there was no product like hub providing the common integration functions from EAI/ESB tools, the integration took place directly between the systems in need. While the more systems use Peer to Peer(P2P) connection, a number of direct connections increase countless mass of connections which is commonly called "Network Spaghetti." When only a few systems are related to each other, the connection points are vivid, and it is not difficult to adopt changes. But when a large number of systems are related, it takes a huge efforts on development and modification.
One of the biggest problems of P2P integration is that the interface program which is developed by each technician who have different level of technology. The codes for the interface must be developed and maintained by assigned technicians, therefore themselves have the role of the subject of integration. In this way, even though the same functions are executed on the systems, the technicians who engaged in each system write the codes for each system. The quality of the output that is not in control of the integration standard have no choice but to depends on the developer's capability.
When a new feature or system is added, the clients have to find a proper technician to add interface or connect new application. Though there is some API or adapter for new interfaces, they still need skillful technicians who writes the codes for specific requirement with them. If not, they may have risk of unsuccessful implementation.
EAI/ESB based integration is somewhat overcame the limitations of P2P integration. To avoid the complex and fallible P2P integration, EAI/ESB solution adapted to use various middleware models with centralization and standardization. Thus, EAI/ESB got rid of complex and twisted connections from the integration and provided higher quality integration service instead.
Since EAI/ESB is adopted, the burden of interface functions has been left to the tool, so the users could focus on the implementation of business functions. Therefore, too much complicated and dispersed codes have been absorbed by EAI/ESB and it could reduce the management's burden. The system interface, which could be implemented by a protocol expert, is able to be implemented easier.
EAI/ESB has facilitated convenient function so that developers can focus on business logic. And also, EAI/ESB made it easy to deploy the interface program with GUI. However, it still has lots of duplicated codes scattered within, and also a limit that an interface program is to make a pair with an interface request, like peer to peer interface. It caused EAI/ESB to take P2P problem into itself causing the same problem of P2P Spaghetti connections. In spite of the limitations, the most complicated parts have been absorbed into inside of EAI/ESB, and it has brought about the benefit of standardization and simplification to the interface at least in the perspective of system architecture.
EAI/ESB provides monitoring and management functions to monitor whether the process or module works normally or not. And it also minimizes the down time with failover function when it has a critical problem.
The key role of interface service is more than doing interface itself. Proving interface service without any problem is just a basic function regardless of EAI/ESB tool or integration application. Integration service platform have to be stable as a part of infrastructure. Interface management includes the functions determine whether the interface is in working well, what the results are, how easy it is to change. These functions aren't simply provided by tools, but they have to be developed to the user's point of views. EAI/ESB provided functions are easy and convenient as a developing tool, but not good as a management tool. Administration function provided by EAI/ESB isn't related to the business interface but to the components of the tool. It is possible to show the status of relevant components but hardly to check whether the business interface is in working well because the status of individual component isn't directly related to the business service. Therefore, each user has to develop and customize the components which extract the information in each one's need using tool provided data. It is more efficient to include developing and customising components considering data in need and the way of using in design stage.
In terms of change management, more challenging process is ahead. Change management in a development tool is enough with the version management of developed program and method, however, the change history of business service cannot be managed in EAI/ESB system. The reason of change exists, but the information like how it has been changed isn't included. If there's a change on the job, and the program code is changed, which requires to reboot the process. It means the service stop. Of course, most of the systems are configured of master-backup, clustering so that there's no service interruption for end-users. However, there's a gap between the change management function provided by tool and change administration feature required by users. The reason of this problem is that the requirements are tightly coupled on the program. No program can be implemented separately from the business requirements. Regardless of the range of modification, modifying program code must be avoided.
ISM maximizes the efficiency of integration product and minimizes the risk of integration described above. ISM not only provides EAI/ESB functions but also the environment which makes it easier to develop by the excluding the interface logic on development. In addition, the information required in management is also predefined and provided to support the management and minimize the burdens of change management.
Easier developing environment provided by ISM means that there will be little development - no coding. The user generates the information not the program codes not to effect on the process physically. This environment means that the business requirements for integration doesn't exist as a program but information. It increases the visibility of implemented business requirements so that administrator can implement the business service not limited to a developer specialized in a specific tool.
사When a new integration requirement arises, a user can define, modify, and apply it to the integration service by configuration not development. The user inputs the information through ISM web console, and the information is not a compiled but saved as raw information itself so that it doesn't require to restart to apply the information. ISM plays a secret box which hides working principle and procedure except the results. Therefore, the user is able to know intuitively which data and how it is processed through the results on screen.
ISM Informatizes integration conditions so that the user can define them through web console without codes. It provides not only the status of the interface and failure, but also the integration view that shows what data and how much of them have been processed. If the request of information in need on the management, the provided data is configured on the screen without extra development of viewer.
Even when the integration condition is changed, the user can change it easily by modifying the information not the program or structure itself. The modification history is stored so that the user can look up the history. And ISM also provides how the change affects to other service. To prevent the modification go wrong to currently running active service, the information is managed in two stages, and the information is applied in the right time. The modified information can be applied in a instance or in any specified time.