Wednesday January 30 2002

Integration Brokers and Web Services

Will Web Services Support be Just Another Feature?

Gunjan Samtani and Dimple Sadhwani

Printer-friendly HTML version

This article discusses the usage of Web Services with Integration Broker solutions. We look at the relationship between integration brokers and Web Services with the help of an elaborate example, and the return on investment in using integration brokers that support Web Services.

What is an Integration Broker?

An integration broker, built primarily on messaging middleware, provides an end-to-end integration platform addressing the critical business components required to completely automate business processes across the extended enterprise, which includes the trading partners. It provides wide-ranging, pre-built application adapters, and bi-directional connectivity to multiple applications, including packaged and mainframe applications.

An integration broker extracts data from the source node at the right time, transforms the data, converts the schema, and routes the data to the target node. Here, the node can be an application, a program, or a person - as defined in the business process workflow. Communication between applications and an integration broker occurs mostly in the form of messages. An integration broker also provides a repository for archiving, searching, and retrieving these messages.

An integration broker does not replace traditional middleware as MOM, RPC, or distributed TP monitors. It is rather built on top of existing middleware technology, most often on messaging middleware.

A few leading integration broker solutions include - IBM MQSeries Integrator; Extricity; BEA eLink; webMethods B2B Enterprise; Mercator Enterprise Broker, WebBroker, CommerceBroker; NEON eBusiness Integration Servers; SeeBeyond e*Exchange eBusiness Integration Suite; Tibco ActiveEnterprise, ActivePortal, ActiveExchange; Vitria BusinessWare; CrossWorlds Software; and Microsoft BizTalk Server.

Web Services and Integration Brokers

Web Services can potentially be used for two distinct domains - enterprise application integration (EAI) and business-to-business integration (B2Bi). EAI is the process of creating an integrated infrastructure for linking disparate systems, applications, and data sources within the corporate enterprise. B2Bi is the process of secured coordination of information among businesses and their information systems, enabling cross-enterprise business applications such as collaborative e-commerce, collaborative networks, supply chain management (SCM), and customer relationship management (CRM) across multiple channels of delivery including wireless devices and the Internet.

Will Web Services become just another service of Integration Brokers?

Yes, undoubtedly. Integration brokers should provide the ability to create, test, deploy, publish, and manage Web Services and subscribe to a business partner's Web Services as an out-of-the-box solution. This would enable enterprises to convert quickly their existing applications into Web Services. They would include an integrated development environment and framework for easily building and deploying Web Services and service components. This should include:

• Support for SOAP - An integration broker should be able to generate and exchange Web Services request and response SOAP-based messages.
• Support for Web Services Standards - An integration broker should provide complete support for Web Services standards including SOAP (as mentioned in the previous point), UDDI, WSDL, and XML.
• Security - An integration broker should be able to exchange Web Services request and response XML messages (based on SOAP) in a secured manner over multiple Internet protocols such as HTTP, HTTPS, FTP, and SMTP. It should provide easy and secured connectivity to private and public UDDI, or any other repository. Further, an integration broker should provide efficient security safeguards such as policy management and authentication, for the access and usage of Web Services.
• Transactional Integrity - Transactional integrity is one of the single most important factors that would determine the winners among the integration broker solutions that offer Web Services support.
• Auditing - An integration broker should provide an effective audit mechanism through which the access and usage of Web Services can be closely monitored.
• Monitoring - An integration broker should provide a monitoring solution to keep track of the current health of the Web Services network.
• Development - An integration broker should support easy development, deployment, publishing, finding, and dynamic binding for Web Services interfaces. It should provide a stable environment for rapid development of Web Services based applications.
• UDDI Connectivity - An integration broker should provide easy connectivity to internal (private) and external (public) UDDI registries. Based on the registry type, there may be a need of an adapter or multiple adapters.
• Workflow Management - Workflow management through which usage of Web Services in a business process can be defined is one of the key requirements of an integration broker.

Easy Connectivity with third-party Web Services Solution

Integration broker vendors may decide to use a third-party Web Services solution, instead of developing their own. In this case, the third-party solution would be a very lightweight application server that would implement support for Web Services protocols. The support for other protocols, such as DCOM, COM, COM+, and CORBA would continue to be provided by the integration broker. In order for this to work, the integration between integration broker solution and third-party Web Services solution has to be seamless, easy, secured, and robust, most likely using adapters. An example of such a third-party solution is Vitiris.

An Example of Integration Brokers and Web Services

Here we will take an example of using integration brokers and Web Services in both an enterprise application integration (EAI) and a business-to-business integration (B2Bi) scenario.

In this example, the integration broker of Company A invokes the Web Service (Product Shipment Status) of Company B over the Internet, gets the response from the Integration broker of Company B, and invokes Web Services published by SCM and ERP systems in-house to update the product shipment status information.

The sequence of steps is as follows:

Integration Broker and Web Service for B2Bi

• 1. Company A's integration broker gets information about Company B's Web Service (Product Shipment Status) by doing a look up in the private UDDI registry. This private UDDI registry is used for all external services, in this case, Web Services used for B2Bi.
• 2. The location of and WSDL binding information for the Web Service is sent to the integration broker of Company A.
• 3. The integration broker invokes the Web Service published by Company B to get the status of product shipment. The communication is based on SOAP over the Internet.
• 4. The integration broker of company B receives the Web Service request and gets the information of product shipment from its ERP system.
• 5. The integration broker of Company B sends the Web Service response. The communication is based on SOAP over the Internet.

It is worth mentioning here that this communication can be based on XML standards defined for business processes for the vertical industry to which Company A and Company B belong. As an example, if Company A and Company B belong to the electronic components industry, the request from Company A and the response from Company B can be based on RosettaNet's PIP. Other examples of B2B XML standards include ebXML and cXML.

Integration Broker and Web Service for EAI

• 6. On receiving the response, Company A's integration broker gets information about the ERP and SCM packages Web Services (Product Shipment Status) by doing a look up in the private UDDI registry. This private UDDI registry is used for internal services, in this case Web Services used for EAI.
• 7. The location of and WSDL binding information for the Web Services published by the SCM and ERP systems is sent to the integration broker of Company A.
• 8. The integration broker invokes the Web Service and updates the product shipment information in both SCM and ERP packages.

UDDI Registry for EAI and B2Bi

A point worth mentioning in this example is that we used two different UDDI registries - one for maintaining information of internal Web Services used for EAI and the second for external Web Services. It is important for companies not to mix information about Web Services used for two separate domains; EAI and B2Bi.

Existing Integration Broker Infrastructure and Web Services

If a company has invested millions of dollars to put their integration broker infrastructure in place, it makes absolutely no sense to abandon it and just embrace some other Web Services solution. Several integration broker vendors, such as TIBCO, Sybase/Neon, Vitria, webMethods, SeeBeyond, and Mercator are already providing support for Web Services in their products. Companies can now use the same integration broker technology to launch Web Services initiatives.

The addition of Web Services support to the existing integration broker solution would allow companies to easily integrate internal and external applications based on services that define and implement business flows and processes with internal groups within an organization, and external trading partners, customers and suppliers. Companies will be able to achieve faster and more efficient results, and a higher ROI, if the integration broker provides this functionality by enabling the design of internal and external business process transactions that directly call upon applications, databases, and systems without additional custom programming.

As a starting point, companies should identify areas where the usage of Web Services really makes sense. Just because it is a new technology that is being talked and written about everywhere is not a good enough reason to pour hundreds of thousands of dollars into it, especially when the Web Services standards are still evolving. Further, Web Services are not the fastest of solutions available for application integration, as, typically, they will require dynamic UDDI lookup and binding which are time consuming process for mission critical real-time applications.

It is very tough to maintain distributed transaction control even within disparate systems and applications within an enterprise. B2B transactions may be spread over disparate systems and applications across different enterprises, making them several times more difficult difficult to maintain and control.

Another point worth mentioning is that companies should first start using Web Services for their internal integration projects for business processes that are non-transactional in nature using existing integration broker technology, before they venture using Web Services in B2B integration projects.

Conclusion

Integration brokers offer a proven scalable and systematic middleware solution for both enterprise application and business-to-business integration. They offer a much neater, more manageable, and more scalable solution than traditional point-to-point application integration.

Web Services offers 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.

Leading integration broker solutions have already started supporting Web Services as one of their services. Companies will be able to lower their investment cost in implementing Web Services solution by building on top of their existing assets.

This article is an extract from Web Services Business Strategies and Architectures. Buy the book from Amazon.com

By the same authors:
EAI and Web Services
B2B Integration and Web Services
Web Services and Application Frameworks

Gunjan Samtani is Divisional Vice President, Information Technology at UBS PaineWebber, one of the world's leading financial services firms. He has several years of experience in the management, design, architecture, and implementation of large-scale EAI and B2B integration projects. He is the primary author of the upcoming book B2B Integration - A practical guide to collaborative e-commerce.
Dimple Sadhwani is Senior Software Engineer at Island ECN based in New York. She has many years of experience working for financial and telecommunication companies on large scale trading systems, CRM applications, Internet/Intranet portals, and client/server applications. She is co-author of the book B2B Integration - A practical guide to collaborative e-commerce. She has also authored several articles in the field of Web Services.

Printer-friendly HTML version

Keep up to date with all the new articles and features on Web Services Architect:
Register for e-mail updates