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 Overview.)

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 Enterprise 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 check request.

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 B2B integration. Electronic 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.