13-06-2014, 04:43 PM
Application of Integration
Application of Integration.docx (Size: 21.81 KB / Downloads: 8)
Introduction
Enterprise application integration 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. Supply chain management applications, customer relationship management applications , business intelligence applications, and other types of applications typically cannot communicate with one another in order to share data or business rules. For this reason, such applications are sometimes referred to as islands of automation or information silos. This lack of communication leads to inefficiencies, wherein identical data are stored in multiple locations, or straightforward processes are unable to be automated.
Purposes
Data integration: Ensures that information in multiple systems is kept consistent. This is also known as enterprise information integration . Vendor independence: Extracts business policies or rules from applications and implements them in the EAI system, so that even if one of the business applications is replaced with a different vendor's application, the business rules do not have to be re-implemented. Common facade: An EAI system can front-end a cluster of applications, providing a single consistent access interface to these applications and shielding users from having to learn to use different software packages.
Federation (inter-communication)
In this case, the EAI system acts as the overarching facade across multiple applications. All event calls from the 'outside world' to any of the applications are front-ended by the EAI system. The EAI system is configured to expose only the relevant information and interfaces of the underlying applications to the outside world, and performs all interactions with the underlying applications on behalf of the requester
Application connectivity
The bus/hub connects to applications through a set of adapters also referred to as connectors. These are programs that know how to interact with an underlying business application. The adapter performs two-way communication, performing requests from the hub against the application, and notifying the hub when an event of interest occurs in the application. Adapters can be specific to an application or specific to a class of applications. The adapter could reside in the same process space as the bus/hub or execute in a remote location and interact with the hub/bus through industry standard protocols such as message queues, web services, or even use a proprietary protocol. In the Java world, standards such as JCA allow adapters to be created in a vendor-neutral manner.
Data format and transformation
To avoid every adapter having to convert data to/from every other applications' formats, EAI systems usually stipulate an application-independent (or common) data format. The EAI system usually provides a data transformation service as well to help convert between application-specific and common formats. This is done in two steps: the adapter converts information from the application's format to the bus's common format. Then, semantic
Integration modules:
An EAI system could be participating in multiple concurrent integration operations at any given time, each type of integration being processed by a different integration module. Integration modules subscribe to events of specific types and process notifications that they receive when these events occur. These modules could be implemented in different ways: on Java-based EAI systems, these could be web applications or EJBs or even POJOs that conform to the EAI system's specifications.
Communication architectures
Currently, there are many variations of thought on what constitutes the best infrastructure, component model, and standards structure for Enterprise Application Integration. There seems to be consensus that four components are essential for a modern enterprise application integration architecture:
1. A centralized broker that handles security, access, and communication. This can be accomplished through integration servers (like the School Interoperability Framework (SIF) Zone Integration Servers) or through similar software like the enterprise service bus (ESB) model that acts as a SOAP-oriented services manager.
Implementation pitfalls
In 2003 it was reported that 70% of all EAI projects fail. Most of these failures are not due to the software itself or technical difficulties, but due to management issues. Integration Consortium European Chairman Steve Craggs has outlined the seven main pitfalls undertaken by companies using EAI systems and explains solutions to these problems.
1. Constant change: The very nature of EAI is dynamic and requires dynamic project managers to manage their implementation.
Conclusion
EAI technologies are still being developed and there still is no consensus on the ideal approach or the correct group of technologies a company should use. There are many ongoing projects that provide support to design EAI solutions. They may range from proprietary projects like Microsoft BizTalk Server, IBM WebSphere Message Broker or open projects like Mule ESB, Apache Camel, Niklas Integration Platform and Spring Integration to academic projects like Guaran DSL. The future is to provide technologies that allow the design of EAI solutions at a high level of abstraction and use MDA to automatically transform the design into an executable solution. A common pitfall is to use other proprietary technologies that claim to be open and extensible but create vendor lock-in.