Identifying the right vendor for an ESB-based integration platform is not an easy task. It depends on several factors associated with your current ALM use case and requirements. Project stakeholders should decide on the integration flow, future tool enhancements, tool accessibility, and configurability before coming to a conclusion. This article takes them through the steps of identifying value propositions in an ESB-based integration solution.
Identifying a comprehensive and unified middleware suite to integrate ALM and IT tools is a difficult task. In my first article, I explained the concept of using an enterprise service bus (ESB). While the use of an ESB is an emerging best practice, there is no global standard to define an appropriate ESB architecture. Integration vendors build and use their own ESB-based integration technology to implement service-oriented architecture. Therefore, each ESB-based integration product has its own strengths and weaknesses.
It is important that business users know how to make the best use of ESB as an integration technology. Self-evaluation of project requirements followed by a few live demonstrations can help you in this regard. Whether you pick a large proprietary vendor, an open source group, or a niche tool integrator for the solution, you should not miss out on the following value propositions.
Easy accessibility: An ESB-based integration platform must support common tools that application developers are familiar with, such as Maven, JUnit, Eclipse, and Spring. It should also provide the option to write custom codes in a variety of languages, such as Java, JavaScript, Python, Ruby, and Groovy.
Solution beyond mediation: An ideal ESB solution does not start with or end at coupling separate ALM or IT tools. It should not be driven by a vendor-specific bus technology. The users must be able to use both synchronization and a linking model as it fits in their particular use case. There is no point in considering an ESB model as a combination of separate products for hosting business logics and publishing services.
Support for OSLC: Not all ALM tools act as providers for Open Services for Lifecycle Collaboration while integrating with Jazz-based IBM Rational tools such as Rational Requirements Composer, Rational Team Composer, and Rational Quality Manager. The integration platform must enable users to view, manage, and track artifacts of non-OSLC tools from the new-generation IBM Jazz tools by using the bus technology.
Lightweight integration: The benefits of using an integration platform weighing less than 40 MB are many. A lightweight container model hosts integration components as remote services and allows you to strip out unnecessary modules as per the integration needs. This also helps control the cost of making changes to existing integrations. Modularization, quick deployment, and ease of configuration are among the other essentials.
Easy referencing of services: The distributed service architecture of an ESB acts as an interconnected system of lightweight service containers, which allows users to configure, deploy, manage, and monitor remote services. These service containers provide scalability, security, and consistent availability as well as ensure quality of service throughout an application lifecycle. A coherent piece of ESB infrastructure must perform all kinds of activities for external and internal services.
100 percent web-based: Whether a project is developed on premise or on the cloud, developers should feel no difference in working on either. A cloud-ready integration platform should not limit its capability to facilitating integrations between applications. The objective is to create a middleware that supports application development as well as integration between tools—the way platform as a service works.
Open messaging models: Though XML is the preferred format of messaging in any ESB model, users may still need to use Cobol Copybooks, JSON, flat files, streams, Java objects, binary, and file attachments for message queuing and publishing or subscribing. The graphical data mapper of an ESB product should be open to all kinds of data.
Support for long-running business processes: Transforming a significant volume of data through a service bus as a large number of individual messages is often problematic. Ideally, BPEL and BPMN technologies are used to implement stateful business processes. However, a good ESB solution must support this for stateless message flow.
Process management across tools: Not all ALM tools have their own process-mapping capabilities. However, it is of utmost importance that a developer can view how an event occurring in one tool triggers the process diagram, which in turn modifies the status of the other related artifacts in other connected tools. An integration platform that includes workflow management can automatically generate tasks for users based on their roles, availabilities, and the required plan of actions.
When to Use ESB and When Not To
As said earlier, an ESB is not a product, it is an architectural concept. If the technology is not chosen for the right reasons or the concept does not fit in the application requirements, it may turn into an architect’s dream but a developer’s nightmare. An ESB should not be treated as a beautifying element in your development CV.
Here is what you need to understand as the basic requirements.
An ESB is worthwhile only if you integrate three or more applications in a distributed environment. If you cannot do this, then a simple point-to-point integration between two applications may be more cost-effective. An ESB makes sense if your project requires services from external stakeholders over which you do not have any direct control. This helps you monitor the service-level agreements that external service providers guarantee you. If you are using a single communication protocol such as HTTP, Web Services, or JMS, investing an ESB does not make sense. However, it is rare that different tools use the same protocol for messaging. ESB architecture helps if message-routing capability is a necessity for a particular project that spans across different tools. The ESB model is a good fit if there is a need to publish services to be used by other applications. In such a case, you can avoid handcrafted code by using plug-in and plug-out ESB systems.
Scalability is another important and decisive factor for comparison between ESB and point-to-point integration solution. Because scalability requirements change quite often in an organization, it is ideal to take advantage of scale-up and scale-down features in an ESB-based integration solution.
These are some of the guidelines to reap the benefits of middleware integration technology. Business users may follow them depending on how they want this technology to satisfy their application integration needs. A few consultations with integration vendors may help you come to a conclusion.
