Search Our Catalog of Articles

  Web Services for the Extended Enterprise
 
As Web Services start to move from theory to reality, I/T managers are struggling with how to best fit them into their enterprise architectures. Part of the difficulty in determining where Web Services fit into the enterprise is that they do not really fit. Web services are fundamentally designed for extended enterprise integration. Specifically, they are designed for integrating with unfamiliar external systems.
 
Web Services are primarily intended for what is called "rapid integration" or "loose coupling". They are designed to tie disparate computer systems together that normally would be too expensive to connect; but offer advantages if the integration can be done cheaply and quickly. Contrast this to other forms of system integration, such as CORBA, DCOM, and RMI that rely on a detailed knowledge of the target system, as well as deep interoperability across the network.
 
Within a single enterprise, deep interoperability and detailed system knowledge are not egregious or demanding requirements. Since both systems are most likely housed behind the corporate firewall, specialized system connectivity is not prohibitive. Confidential documentation and privileged system access help educate system integrators on the details of the target systems. And of course, if all else fails, direct access to the system developers is usually available.
 
Between organizations these same requirements scale to more difficult proportions. Corporate firewall penetration requires special encrypted tunnels, or conduits, to enable the necessary system interoperability. Access to secure systems is not easily granted, and detailed knowledge of proprietary systems is often considered a security risk for non-employees. System engineers and developers are often reluctant to discuss detailed information with outsiders causing vital information to be withheld from integrators.
 
Against this backdrop, Web Services promises to ease extended systems integration through mechanisms embedded in the Web Services standard. To start, Web Services are based on Web serving (HTTP) protocols transporting XML. This means they are accessible through any firewall that allows web traffic - which is most of them. Web Services also have a built in language for discovering the parameters and data required for a transaction. The Web Services Definition Language (WSDL) acts as a self-publishing mechanism to expose technical details for interested integrators. Finally, a library of available Web Services is being compiled to allow automated and manual searches for applicable providers. Provided by Microsoft and IBM, the Universal Description, Discovery, Definition and Integration (UDDI) repository is designed to allow rapid identification of existing Web Services and provide details for usage.
 
Within retail, the business to business community has awakened to the cost saving potential of rapidly integrating Web Services and is busy tying distributors, shippers, and merchants together in ways that would be impossible if a large investment was necessary. Additionally, the low cost and ease of implementation is allowing companies to expose Web Services to partners that normally would not qualify for more expensive integration techniques.
 
As an example, Amazon is now offering Web-Services-based shopping carts, search, and inventory to their affiliates for integration into the affiliates' web sites. Primarily targeting lightly staffed ecommerce providers, Amazon's offering would be prohibitively expensive (both to Amazon and the prospective affiliate) if based on traditional integration techniques. Web Services, however, allow Amazon to reach thousands of affiliates and offer a simple, effective transactional interface for sales and product fulfillment.
 
Interestingly, the architecture that makes Web Services ideal for extended enterprise integration creates limitations that make them unsuitable for intra or single enterprise integration. As mentioned, Web Services are based on the HTTP protocol so they are "compatible" with most Firewall configurations. However, there is an overhead associated with encoding transactional logic in XML as is required by Web Services. For internal integration efforts where firewall issues are not critical, this inherent overhead makes Web Services a poor choice for transactional connectivity.
 
Another limitation of Web Services stems from the component of the Web Services standard called the Simple Object Access Protocol (SOAP). SOAP allows transactional calls to be embedded in XML documents and transported by the Web Service. The limitation stems from the 'Simple' aspect of SOAP. Complex transactions, such as those associated with an internal billing system, will not translate into SOAP calls. A complex, intra-enterprise system would be better served through traditional integration techniques.
 
Web Services are a new instrument in the I/T manager's integration suite. Designed for a new form of rapid integration, the combination of HTTP, XML, and SOAP frees developers to access transactional interfaces across corporate firewalls with much less effort than traditional techniques. Once accessed, self-publishing description interfaces educate developers on the transactional details for the unfamiliar Web Services.
 
This new form of loose coupling enables the creation of ad-hoc affiliate networks and transactional partnerships at a speed and efficiency not possible with yesterday's Internet. In the extended enterprise, the power is in the transaction. Now Web Services are bringing the transaction to the network.