System integration using Websphere MQ
Streamlining the user's workflow
The main reason EAI technology is necessary is because of the need to streamline a
user’s workflow to increase productivity. This purpose of EAI is often overlooked
because focus shifts to the complexity and expense of the interfaces needed to achieve
this streamlined workflow. The picture below shows an example of EAI where a process
may be streamlined from several applications with many interfaces to a single user
interface for a field resource to perform his job.
Figure 1 - Streamlining Field Workflow
To that field user, a single workflow-oriented application is used to do his job. In reality,
he is accessing and manipulating data from multiple systems with this streamlined
application, which interfaces with these other enterprise systems. It is important to keep
this goal of streamlining a user’s workflow at the forefront of system integration in order
to achieve the desired paybacks.
EAI technology
Now that we’ve seen the goal, what technology is recommended to enable this
integration? The classic example you see is to replace all point to point interfaces with a
hub or message broker to handle all application to application interfaces.
]
Figure 2 - EAI using Middleware
With this approach, all interface messages are funneled through the hub, which is
typically a middleware application responsible for message brokering. The message
broker accepts messages from one system and then sends the message to the other
system. The main advantage of using this technology is that it decouples applications
that are interfacing with each other. Advantages of decoupling these applications
include:
- Providing a standard mechanism for integrating applications across multiple
hardware and operating system platforms
- Providing a standard message language so that applications need not know the
programming languages supported by other applications.
- Ability to upgrade or replace software at one end without causing the other
application to break (assuming that the new software understands the messages
being sent by the broker)
While we agree with this approach, there are some items to consider.
- The technology for EAI is great (for the reasons listed above), but it is difficult to
cost justify as a project by itself, especially when existing interfaces are working
fine. One ideal time to evaluate such technology is when a new system is being
implemented or going through a major technology change. During
implementation of a new system, evaluate the interfaces necessary, and
evaluate using EAI technology instead of point to point interfaces. Another time
to evaluate EAI is when you are looking to streamline a particular workflow within
your organization. Evaluate that workflow and all they systems/databases
involved in the workflow. Using EAI technology can help you integrate these
systems into a single streamlined workflow for the end user.
- Using EAI technology provides a loosely coupled interface. While this is fine for
the interfaces between most applications, there are times when a more tightly
coupled (point to point) interface may be appropriate. An example of such a
case could include integration of a GIS application with an analysis package. If
the desired workflow is for the engineer to invoke analysis directly from the GIS
during design, then it may be more appropriate to incorporate objects from the
analysis package in the GIS application. These tightly coupled interfaces are
generally most appropriate when client applications need to talk to each other
(instead of server applications).
- Not all applications need to talk to every other application. When implementing
an application, evaluate other application(s) need interfaces (both now and in the
future) before deciding whether integration using a message broker is
appropriate.
