Enterprise Application Integration (EAI) is one of the hot-button issues in Information Technology in 2000. Information Week's research survey of 300 technology managers showed nearly 75% of respondents said EAI is a planned project for their IT departments in the coming year. According to a study by Bank Boston, the market for EAI is expected to be $50 Billion USD by 2001.
Successful EAI requires a careful combination of a middleware framework, distributed object technologies, and custom consulting. Many vendors have evolved out of the middleware space, and some are coming from the Extract/Transform/Load space. It remains to be seen what approach will provide the most value for a new EAI product. Many of these products are refashioned middleware tools.
Vendors are attempting "out of the box" solutions, but there is immense complexity involved in integrating applications, particularly extended supply chain, e-commerce, and customer relationship management/sales force automation. The key to the entire puzzle is in the architecture of the integration, which must be carefully examined before any implementation is attempted.
EAI began at Goldman Sachs in New York nearly 10 years ago, where they funded the Teknekron Information Bus (TIB) to pump stock market quotes into different systems. The programmers who wrote Teknekron then left and founded TIBCO. Many of those same developers are now with Vitria.
The basic components required to achieve EAI are the following:
Business Rule Component: to allow the applications to understand your business processes
Business Logic Modules (i.e. supply planning, sales order processing. Methods for business process management.)
Transformation tools (to define how to map data from one system to another)
Data Acquisition Component: to allow access to the data
Data Source and Target Interfaces (i.e. Siebel, SAP, PeopleSoft, ODBC, Oracle, CICS, IMS) - note that the data acquisition component is crucial to EAI success. Most vendors refer to these interfaces as "adapters" -
System Development Component: to allow programmers to design and test custom requirements -
Design tools (for business process design, debugging, and testing)
A published API (Application Programming Interface) to the product so custom extensions can be written as needed
System Control Component: to allow the application to be monitored and controlled
Management tools (for application-specific monitoring), preferably with support for the Simple Network Management Protocol (SNMP) via a vendor-supplied SNMP agent
Directory tools (for locating other applications on different platforms), particularly support for the Lightweight Directory Access Protocol (LDAP)
ommitment control management mechanisms (for control of business-level logical units of work)
Strong support for metadata management, preferably distributed and bi-directionally synchronized
Message Brokers (to control transactions, control security, and perform event notification, i.e. IBM's MQSeries, or Microsoft's MSMQ for Windows NT). The product should also include the capability to "bridge" messages between different messaging systems (i.e., an IBM MQSeries mainframe application that needs to communicate with a Microsoft MSMQ application on Windows NT)
Scalability for high-volume transaction throughput. We cannot put enough emphasis on attention to scalability. It is almost impossible to know at implementation time what the data volumes will be in the future
Support for varying levels of fault tolerance, load balancing, and failover for mission-critical systems
Workflow enablement (via SMTP, publish/subscribe capabilities, etc.) is a key requirement to reduce latency between distributed processes. The product should also have links to workgroup products such as Lotus Notes
System Access Component:
A Web-based portal for transparent, integrated information access
The ability to work both inside and outside the corporate firewall
To attempt to explain EAI, an understanding of data-oriented middleware is necessary. In addition, the "portal" concept must be explained, as the web is the standard front-end to these distributed technologies. The topology of this type of application can be split into two parts; the first is the middleware that connects the disparate data sources, the second is the business logic that provides a unified view of the data. Given the complexity of this solution, consulting is required to integrate all the pieces, as there is no "out of the box" solution that can provide plug-and-play integration.
Much consideration must be given to the coupling of time and process. There are three basic communication types which may be required for the middleware solution:
Asynchronous: provided by products such as IBM's MQ Series, used in situations where the communicating applications don't need to be active at the same time. This allows applications to be "loosely coupled in time". An example of this would be a terminal application feeding a batch process.
Synchronous: provided by OMG's CORBA and Microsoft's COM, used where the business logic requires that the applications communicate in real-time. The requesting transaction waits until it receives the result set from the other application.
Transactional: using transaction monitors such as IBM's CICS or BEA's Tuxedo. This is required where the logical unit of work (defined as one business transaction) spans multiple systems.
The last major requirement for an EAI system is security, typically in the form of single sign-on (to provide access to all the required data without multiple passwords.) Using EAI provides a business with the ability to consolidate "stovepipes" of information from various transactional, legacy, relational, and other sources into a unified and secure view.
An additional challenge is the need to rationalize the data in the different data sources. For example, the definition and datatype of the "customer" field may vary from one database to another. These dimensions need to be conformed in order for any meaningful integration to take place. The integrator must also take into account how "real-time" the application's data needs to be. Event-based synchronous communications can be difficult to define, usually requiring database triggers or database log analyzers. When the data source is not a relational database (i.e., a text file), this process can become extremely complicated.
SOURCE:-
http://www.technologyevaluation.com/research/articles/enterprise-application-integration-the-latest-trend-in-getting-value-from-data-15210/
Successful EAI requires a careful combination of a middleware framework, distributed object technologies, and custom consulting. Many vendors have evolved out of the middleware space, and some are coming from the Extract/Transform/Load space. It remains to be seen what approach will provide the most value for a new EAI product. Many of these products are refashioned middleware tools.
Vendors are attempting "out of the box" solutions, but there is immense complexity involved in integrating applications, particularly extended supply chain, e-commerce, and customer relationship management/sales force automation. The key to the entire puzzle is in the architecture of the integration, which must be carefully examined before any implementation is attempted.
EAI began at Goldman Sachs in New York nearly 10 years ago, where they funded the Teknekron Information Bus (TIB) to pump stock market quotes into different systems. The programmers who wrote Teknekron then left and founded TIBCO. Many of those same developers are now with Vitria.
The basic components required to achieve EAI are the following:
Business Rule Component: to allow the applications to understand your business processes
Business Logic Modules (i.e. supply planning, sales order processing. Methods for business process management.)
Transformation tools (to define how to map data from one system to another)
Data Acquisition Component: to allow access to the data
Data Source and Target Interfaces (i.e. Siebel, SAP, PeopleSoft, ODBC, Oracle, CICS, IMS) - note that the data acquisition component is crucial to EAI success. Most vendors refer to these interfaces as "adapters" -
System Development Component: to allow programmers to design and test custom requirements -
Design tools (for business process design, debugging, and testing)
A published API (Application Programming Interface) to the product so custom extensions can be written as needed
System Control Component: to allow the application to be monitored and controlled
Management tools (for application-specific monitoring), preferably with support for the Simple Network Management Protocol (SNMP) via a vendor-supplied SNMP agent
Directory tools (for locating other applications on different platforms), particularly support for the Lightweight Directory Access Protocol (LDAP)
ommitment control management mechanisms (for control of business-level logical units of work)
Strong support for metadata management, preferably distributed and bi-directionally synchronized
Message Brokers (to control transactions, control security, and perform event notification, i.e. IBM's MQSeries, or Microsoft's MSMQ for Windows NT). The product should also include the capability to "bridge" messages between different messaging systems (i.e., an IBM MQSeries mainframe application that needs to communicate with a Microsoft MSMQ application on Windows NT)
Scalability for high-volume transaction throughput. We cannot put enough emphasis on attention to scalability. It is almost impossible to know at implementation time what the data volumes will be in the future
Support for varying levels of fault tolerance, load balancing, and failover for mission-critical systems
Workflow enablement (via SMTP, publish/subscribe capabilities, etc.) is a key requirement to reduce latency between distributed processes. The product should also have links to workgroup products such as Lotus Notes
System Access Component:
A Web-based portal for transparent, integrated information access
The ability to work both inside and outside the corporate firewall
To attempt to explain EAI, an understanding of data-oriented middleware is necessary. In addition, the "portal" concept must be explained, as the web is the standard front-end to these distributed technologies. The topology of this type of application can be split into two parts; the first is the middleware that connects the disparate data sources, the second is the business logic that provides a unified view of the data. Given the complexity of this solution, consulting is required to integrate all the pieces, as there is no "out of the box" solution that can provide plug-and-play integration.
Much consideration must be given to the coupling of time and process. There are three basic communication types which may be required for the middleware solution:
Asynchronous: provided by products such as IBM's MQ Series, used in situations where the communicating applications don't need to be active at the same time. This allows applications to be "loosely coupled in time". An example of this would be a terminal application feeding a batch process.
Synchronous: provided by OMG's CORBA and Microsoft's COM, used where the business logic requires that the applications communicate in real-time. The requesting transaction waits until it receives the result set from the other application.
Transactional: using transaction monitors such as IBM's CICS or BEA's Tuxedo. This is required where the logical unit of work (defined as one business transaction) spans multiple systems.
The last major requirement for an EAI system is security, typically in the form of single sign-on (to provide access to all the required data without multiple passwords.) Using EAI provides a business with the ability to consolidate "stovepipes" of information from various transactional, legacy, relational, and other sources into a unified and secure view.
An additional challenge is the need to rationalize the data in the different data sources. For example, the definition and datatype of the "customer" field may vary from one database to another. These dimensions need to be conformed in order for any meaningful integration to take place. The integrator must also take into account how "real-time" the application's data needs to be. Event-based synchronous communications can be difficult to define, usually requiring database triggers or database log analyzers. When the data source is not a relational database (i.e., a text file), this process can become extremely complicated.
SOURCE:-
http://www.technologyevaluation.com/research/articles/enterprise-application-integration-the-latest-trend-in-getting-value-from-data-15210/
No comments:
Post a Comment