BITPIPE RESEARCH GUIDE :
EAI and Web Services First Steps
No two integration projects are exactly alike. The unique nature of each
project has forced most enterprises to rely on a web of homegrown point-to-point
integration code. Even packaged applications like
Enterprise Resource Planning
(ERP) are customized to the point where each instance of the system has
its own unique requirements. Gathering these requirements and doing a complete cost
and effort comparison is the critical first step in any integration project.
The requirements for each project are determined by the number and type of
applications, the format of the data, the type of transactions, and other requirements
for security, performance, and reliability. (If you're new to application
integration, please read our EAI and Web Services
Number and Type of Applications
The first step in determining your approach
to integration is the type and number of applications. If you are
trying to integrate packaged applications from different vendors,
then there is a good chance an
Application Integration (EAI) vendor has a standard adapter that you can use. If you are
trying to integrate applications from a single vendor, such as
two instances of an SAP application, then the vendor may have a
solution that works and is more cost-effective than EAI. However,
if your applications are homegrown, heavily customized, or legacy
mainframe systems, then integration will likely require much more
development work on your end. You will probably need to build your
own adapter from scratch, or hire a systems integrator to do the
work for you.
Types of Transactions
You will also need to determine what kind of
transactions you need to support, as this will have a significant impact
on the technology choices available to you. For example, if the applications
you are trying to integrate support long-running transactions, such as
complex business processes that have multiple steps or transactions where
the source application doesn't require a response, then you will need a
message-queuing solution that can send messages to a queue and then
forward them to the destination application. Sending the message to the
queue essentially completes the transaction for the source application
and allows it to move on to other tasks. If the applications support
short-lived transactions, where the client application sends a request
to the server applications and waits for a response, then a Remote Procedure
Call (RPC)-based solution such as an application server will probably work
for you. An example of a short-lived transaction would be a credit
Type of Data
Each application and database has its own data format and
object model. Regardless of the approach you take to integration, the
communicating applications need to receive data in their own format.
You will therefore need some kind of transformation technology to interpret
data from different systems. Most EAI tools include data transformation.
Increasingly eXtensible Markup Language
is becoming the centerpiece of
data format transformation. If you are integrating your custom-built or
legacy applications, XML-based tools to map data formats will be needed.
This issue becomes particularly important for
Data Interchange (EDI) established a set of standard business documents
that could be transmitted system-to-system without human intervention.
Trade vocabularies, essentially industry-specific syntaxes, built on XML
have extended EDI to include a much wider range of documents and processes.
Go to Bitpipe Research Guide: EAI and Web Services.