|
试用期
IT不歸人 - 积分
- 18
- 威望
- 0
- IT币
- 36 个
- 鲜花
- 0 朵
|
1#楼
大 中
小 发表于 2003-5-10 21:07 只看该作者
(分享)EAI and Web Services
EAI and Web Services
Easier Enterprise Application Integration?
Gunjan Samtani and Dimple Sadhwani
As companies move in the direction of collaborative business-to-business e-commerce, they will first have to look inward to their own internal systems, applications and processes. Several business processes span across multiple internal applications. These applications must be able to communicate dynamically in real-time before a company can effectively e-communicate with the outside world.
Most companies have an environment of disparate legacy systems, applications, processes, and data sources, which typically interact by a maze of interconnections that are poorly documented and expensive to maintain. Additional problems arise from market consolidation in the digital age, where mergers and acquisitions of companies can increase the complexity of system integration exponentially.
The segmentation of information systems was exacerbated with the introduction of commercial off-the-shelf applications such as enterprise resource planning (ERP), customer relationship management (CRM), supply chain management (SCM), and portals. Early on, these systems were designed as self-contained "black-boxes" with little or no means for accessing internal data or processes. Although many of these applications now provide better access to their underlying data and business logic, integrating them with other systems in the enterprise is still a challenge.
Each node in the above diagram maintains its own data, which may be shared among the nodes. Sharing of this data has been typically accomplished using data transfer methods including batch processes and data import/export jobs. Since the data of one node is not available in real-time to other nodes, the latter cannot analyze and make decisions while a transaction is being processed at the former.
What is Enterprise Application Integration?
As the need to meet increasing customer and business partner expectations for real-time information continued to rise, companies were forced to link their disparate systems to improve productivity, efficiency, and, ultimately, customer satisfaction. The need for IT systems to communicate within an organization led to the evolution of enterprise application integration (EAI). EAI is the process of creating an integrated infrastructure for linking disparate systems, applications, and data sources across the corporate enterprise. The very origin of EAI solutions can be linked to the need for providing a full duplex, bi-directional solution to share seamlessly and exchange data between ERP, CRM, SCM, databases, data warehouses, and other important internal systems within the company.
EAI is not an out-of-the-box solution, but rather an ongoing process of creating a flexible, standardized enterprise infrastructure that allows new IT-based applications and business processes to be easily and efficiently deployed. The new infrastructure allows applications throughout an enterprise to seamlessly communicate with one another in a real-time manner.
Types of EAI
EAI solutions can take on many forms and exist at many levels. The appropriate level of EAI can be dependent on many factors including company size, company industry, integration/project complexity, and budget.
There are four types of middleware solutions to EAI:
User Interface Integration
Data Integration
Business Process Integration
Method or Function Integration
As we look at these types of solution, bear in mind that we're discussing the pattern of the solution, not the implementation.
User Interface Integration (Refacing)
Refacing is the process of replacing the terminal screens of legacy systems and the graphical interfaces of PCs with one standardized interface, typically browser-based. Generally, the functionality of terminal screens applications can be mapped on a one-to-one basis with a browser-based graphical user interface. The new presentation layer is integrated with the existing business logic of the legacy systems or packaged applications such as ERP, CRM and SCM.
Enterprise business portals may also be considered a sophisticated refacing solution. A business portal consolidates the presentation of multiple applications into one customizable browser-based interface. The portal framework acts as a middleware solution in this type of EAI.
Data Integration
Data integration occurs at the database and data source level within an organization. The integration is achieved by migrating data from one data source to another. Data integration is the most prevalent form of EAI in existence today. One of the biggest problems with data integration, however, is that the business logic usually exists only within the primary system, limiting real-time transactional capabilities.
There are a bevy of data replication and middleware tools to facilitate data transfer between data sources in both real-time and batch modes. Some data integration methods include:
Batch Transfer
Data Union
Data Replication
Extract, Transform, and Load (ETL) Solution
The ETL solution (as in the diagram above), which is based on an ETL engine extracting, transforming, cleansing and loading data from various applications to data warehouses and/or data marts, has now become the preferred way for companies to achieve data integration.
Business Process Integration
While data integration has proved a popular form of EAI, it can present problems from a security, data integrity, and business process perspective. The vast majority of data within an organization is accessed and maintained through business logic. The business logic applies and enforces the required business rules, processes and security for the underlying data.
Business process integration occurs at the business process level, which spans multiple applications. It is often characterized by the use of advanced middleware such as message brokers, which standardize and control the flow of information through a bus or hub-and-spoke framework. The following diagram illustrates on a high level what an open business process consists of:
Method or Function Integration
Function or method integration involves the direct and rigid application-to-application (A2A) integration of cross-platform applications over a network. It can range from custom code (COBOL, C++, Java), to application programming interfaces (APIs), to remote procedure calls (RPCs), to distributed middleware such as TP monitors, distributed objects, common object request broker architecture (CORBA), Java remote method invocation (RMI), message oriented middleware (MOM), and Web Services (see Figure 5).
Function or method oriented integration is primarily synchronous in nature, that is, it's based on request/reply interactions between the client (requesting program) and the server (responding program).
Web Services
Web Services provide a distributed computing technology for revealing the business services of applications on the Internet or intranet using standard XML protocols and formats. The use of standard XML protocols makes Web Services platform, language, and vendor independent, and an ideal candidate for use in EAI solutions.
Web Services eliminate the interoperability issues of existing solutions, such as CORBA and DCOM, by leveraging open Internet standards - Web Services Description Language (WSDL - to describe), Universal Description, Discovery and Integration (UDDI - to advertise and syndicate), Simple Object Access Protocol (SOAP - to communicate) and Web Services Flow Language (WSFL - to define work flows, not yet a W3C standard).
EAI and Web Services
Web Services are not EAI in and of themselves. Rather, Web Services are just another technology that enables EAI, and it can significantly change the traditional point-to-point approach.
Using Web Services that loosely integrate applications, a company achieves just a subsection of EAI. EAI, on the other hand, takes a complete holistic approach of tightly integrating and connecting all applications and systems that support a company's business. EAI takes years of continued commitment and effort from different business and technical units within the company, high investment, and substantial resources.
Web Services, in their current form of loosely bound collections of services, are more of an ad hoc solution that can be developed quickly and easily, published, discovered, and bound dynamically. In this generation of Web Services, it is possible to achieve only function level integration between applications. They are not transactional in nature and provide basic "request/response" functionality. The next generation of Web Services, however, will be functionally and technologically advanced, offering user interface encapsulation and security. They will be able to package an application and embed it into another application.
The current EAI solutions that predominately focus on integrating applications will have to be changed significantly, as packaged applications in the future will expose their functions as services using technologies such as XML, SOAP, and UDDI. Thus, the EAI solutions will have to provide a broad support for service integration rather than application integration.
Salient Differences between Traditional EAI Solutions and Web Services
A few essential differences between traditional EAI solutions and Web Services are, as follows:
(Note: Some of these differences take into account the future enhancements proposed in Web Services)
Simple: There is no doubt that Web Services are much simpler to design, develop, maintain, and use as compared to a typical EAI solution which may involve distributed technology such as DCOM and CORBA. Once the framework of developing and using Web Services is ready, it will be relatively easy to automate new business processes spanning across multiple applications.
Open Standards: Unlike proprietary EAI solutions, Web Services are based on open standards such as UDDI, SOAP, HTTP and this is probably the single most important factor that would lead to the wide adoption of Web Services. The fact that they are built on existing and ubiquitous protocols eliminates the need for companies to invest in supporting new network protocols.
Flexible: Since EAI solutions may require point-to-point integration, changes made at one end have to be propagated to the other end, making them very rigid and time consuming in nature. Web Services based integration is quite flexible, as it is built on loose coupling between the application publishing the services and the application using those services.
Cheap: EAI solutions, such as message brokers, are very expensive to implement. Web Services, in the future, may accomplish many of the same goals - cheaper and faster.
Scope: EAI solutions, such as message brokers, integrate applications treating them as single entities, whereas Web Services allow companies to break down big applications into small independent logical units and build wrappers around them. For example, a company can write wrappers for different business components of an ERP application such as order management - purchase order acceptance, status of order, order confirmation, accounts receivable, and accounts payable.
Efficient: As mentioned in the previous point, Web Services allow applications to be broken down into smaller logical components, which makes the integration of applications easier as it is done on a granular basis. This makes Web Services solutions for EAI much more efficient than traditional EAI solutions.
Dynamic: Web Services provide a dynamic approach to integration by offering dynamic interfaces, whereas traditional EAI solutions are pretty much static in nature.
Example of Web Services for EAI
The following diagram shows an example of using Web Services within an organization. In this example, the portal application running within an application server aggregates information from multiple internal applications, providing a single point of entry into business processes spread across those applications. The portal application gets information about Web Services offered by internal applications using private UDDI registry and invokes these services over the intranet. Binding information for frequently used Web Services can be cached by the application, to avoid the resource intensive and time consuming dynamic binding. In this example, the Web Services loosely integrate portal with CRM and ERP applications.
The sequence of steps is as follows:
After logging on to the company portal, users request information.
The application supporting the portal framework gets information about Web Services made available by the CRM and ERP applications by doing a look up in the private UDDI registry.
The location and WSDL binding information of Web Services is sent to the application server.
The application invokes the Web Service published by the CRM application and retrieves the personal information, such as name, social security number, mailing address and email, of the user. The communication is based on SOAP.
The application invokes the Web Service published by the ERP application and retrieves the account information, such as account number, balance and transaction history, of the user. The communication is based on SOAP.
The information is then formatted and sent to the user.
Where to Start?
Companies should start using Web Services in internal application integration projects at the function, application programming interface (API), or remote procedure call (RPC) level (as shown in Figure 5). This will orient the IT staff with the technology issues involved in using Web Services, which would be very helpful in overcoming the challenges posed later when the company uses Web Services for external application integration (B2B integration) projects. It is much easier to control, manage, find, execute, and maintain Web Services within an intranet as compared to using them over the Internet across the corporate firewall. Further, it would help companies in identifying business opportunities of using standardized and relatively cheap Web Services solution as against expensive EAI broker solutions.
It would, however, be utterly naïve of companies to scrap existing EAI infrastructure and blindly march towards deploying Web Services to replace it. Companies cannot stop using the EAI middleware frameworks, which provide full transactional services, in lieu of Web Services, which don't (as yet). Instead, they should use Web Services to leverage existing infrastructure.
Web Services will gradually evolve from an EAI solution to B2Bi solution over a period of time.
Conclusion
Web Services offer a platform neutral approach for integrating applications, so that it can be used to integrate diverse systems, in a way supported by standards rather than proprietary systems. The ability of an enterprise to have access to real-time information spanning across multiple departments, applications, platforms and systems is one of the most important driving factors behind the adoption of Web Services. Companies should first start using Web Services for their internal integration projects for business processes that are non-transactional in nature, before they venture using Web Services in B2B integration projects
This article is an extract from Web Services Business Strategies and Architectures.
http://www.webservicesarchitect.com/book.asp
|
