Introduction to Integration(EAI and B2B) Print E-mail

Written by Sashi   
Thursday, 04 April 2013 16:36


Enterprise Application Integration (EAI) is an application of technology defined as the integration of data and services between applications. It’s the unrestricted sharing of data and business processes among any connected applications and data sources in the enterprise. The patterns of modern day EAI are usually attributed to Enterprise Integration Patterns that categorizes and explains many of the integration patterns common to integration solutions.

It is an integration framework composed of a collection of technologies and services which form a middleware to enable integration of systems and applications across the enterprise.

Examples include Integrating Supply chain management, Customer Relationship Management, Business Intelligence and Human Resources applications within an enterprise.

List four types of integration styles:


Integration styles


File Transfer: two systems produce files whose payload is the message to be processed by the other system. An example of this is polling a directory or an FTP directory for a file and processing it.


Shared Database: two systems query the same database for data to be passed. An example of this is when you have two EARs deployed whose entity classes (JPA, Hibernate, etc.) shared common tables.


Remote Procedure Call: each of two systems expose services that the other can call. An example of this is EJB services, or SOAP and REST services.


Messaging: two systems connect to a common messaging system and exchange data and invoke behavior using messages. An example of this is the familiar hub-and-spoke JMS architecture.


Integration Architectures

The first and foremost step in understanding integration architectures is to understand the different topologies existing in integration arena, and to appreciate the vital difference between them. Let us now understand the basic integration architectures that are listed as follows:

  1. Point-to-Point solution
  2. Hub-and-Spoke solution
  3. Enterprise Service Bus Integration

Point-to-Point Solution 
In point-to-point, we define an integration solution for a pair of applications. Thus we have two end points to be integrated. We can build protocol and/or format adapters, or transformers at one or either end. This is the easiest way to integrate, as long as the volume of integration is low. We normally use technology-specific APIs like FTP, IIOP, remoting or batch interfaces, to realize integration. The advantage is that between these two points, we have tight coupling, since both ends have knowledge about their peers.


EAI and_B2B1 


Hub-and-Spoke Solution
Hub-and-spoke architecture is also called the message broker and is similar to point-to-point architecture in that it provides a centralized hub (broker) to which all applications are connected. When multiple applications connect in this manner,  Another distinguishing feature of the hub-and-spoke architecture is that each application connects with the central hub through lightweight connectors. The lightweight connectors facilitates for application integration with minimum or no changes to the existing applications.

 EAI and_B2B2


 Enterprise Service Bus Integration
ESB is a collection of middleware services which provides integration capabilities. These middleware services sit in the heart of the ESB architecture upon which applications place messages to be routed and transformed. Different applications will not communicate directly with each other for integration; instead they communicate through this middleware Service Oriented Architecture (SOA) backbone. The most distinguishing feature of the ESB architecture is the distributed nature of the integration topology. Most ESB solutions are based on Web Services Description Language (WSDL) technologies, and they use Extensible Markup Language (XML) formats for message translation and transformation.


EAI and_B2B3



Business-to-business (B2B)

The term business-to-business, B2B for short, refers to all commerce transactions between businesses. Examples of B2B transactions include canned goods manufacturers buying wholesale produce farmers or middle men. Another example would be a company that pays an advertising firm to handle the advertising campaign of their different product lines.

Businesses engage in multiple B2B transactions on a daily basis in order to provide their products and services to their customers. For the example given above, after buying fresh produce the canned goods company need to contract the service of trucking companies (assuming they don’t have their own fleet) to bring the produce to their warehouse, they also deal with wholesale and retail vendors of their products as well as advertising firms that help them promote their canned goods. A lot of other B2B transactions overlooked by the example would also ensure that there’s always a continuous supply of raw materials and processed goods. 

Due to the need for suppliers and service support, many businesses have other businesses as their main customers. Examples of such businesses are farmers that are under exclusive contract to a specific company, advertising firms, and business process outsourcing firms (BPOs).



 EAI and B2B Basic concepts: 


1. Focused on transactions and messages.

2. Standardize and leverage objects/data across systems.

3. Process management automates business processes across systems.

4. High-speed communications provide reliability, availability, and speed.

5. Routing table is used for routing between applications.

6. Route between applications.

7. Look-up and cross-reference is easy.

8. Recovery from lost messages is critical but manageable.

9. Solution must be robust for scalability, reliability, etc.

10. One integration takes one to six months, depending on the tools and system.

11.Implementation timeframes depend on applications and supporting adapters.

12. Reuse is at the event/data layer.

13. Each application requires specialization but there is significant value in architecture to leverage reuse. 


1. Focused on documents.

2. Work with numerous data definitions and standards.

3. Process automation tends to be point-to-point and fragmented.

4. Internet communications may be error-prone and slow.

5. Trading partner profile database is used for routing to each partner.

6. Route between partners and between partners’ multiple applications.

7. Look-up and cross-reference is difficult.

8. Recovery from lost messages is even more critical and difficult.

9. Solution must be good enough to communicate with partners.

10. One integration could take as little as two weeks.

11. Implementation timeframes depend on applications, supporting adapters, and overall e-readiness of an organization.

12. Reuse is at the XML/EDI document layer.

13. Each partner needs specialization so there is significant value in openness/easiness of the tools that are used.