Using Technology to Cross Organizational Boundaries, part 4

XML Middleware

In contrast to classic middleware which seeks to closely bind the enterprise systems and processes of several organizations into a single closely coordinated virtual organization, cross-organization business systems can be built using exchange of XML documents to bind together the multiple organizations. Ideally, such an approach would combine the strengths of EDI with the rich interactions supported by classic middleware systems. And an XML middleware approach offers the possibility of addressing some of the tight coupling issues associated with classic middleware systems.

webMethods Inc. offers a system built using such an XML middleware approach. This system uses the webMethods B2B Integration Server and their Web Interface Definition Language (WIDL). webMethods started its development efforts after observing that many ecommerce websites function essentially as web-based interfaces to company business services. The websites are intended for use by humans, rather than for automated access. But if a way could be found to automatically access the services behind the website, then the site itself could be used as the basis for automated electronic business.

webMethods's first product is called the Web Automation Server. Using it, developers at a business can examine the websites of the business's partners and create WIDL descriptions of the interfaces and business functionality available on those sites. After creating those descriptions, the developers run webMethods's WIDL tools on the description to produce client proxies and Web Automation Server rules. The client proxies are callable routines that applications can use to access the services available at the remote website. The Web Automation Server rules work in concert with the client proxies and tell the server how to process application calls to the proxies.

The developers then create a client application that issues calls to the client proxies generated from the WIDL description. The proxies in turn send the requests on to the Web Automation Server. The server, using the rules generated from the WIDL description, then makes the appropriate web requests directly to the website in order to implement the requested operation. In this way, remote websites become available from applications, rather than requiring a human to manually interact with the site.

While the Web Automation Server enables easy access to the functionality that partners expose on their websites, it does not enable more complicated and rich interactions. For example, if a website does not provide an easy way to check on inventory stock, there is no way to use the Web Automation Server to do such a check. However, because the Web Automation Server relied on document exchange between partners, it avoids many of the security issues and lets partners work in a loosely coupled fashion. Partner system upgrades, process changes, and so forth, do not need to be coordinated and managed together. In fact, a business can create an application that accesses another business's services without needing any support from that business.

The next step for webMethods was to address the functionality limitations of the Web Automation Server while building on the document exchange foundation. To do this, webMethods extended WIDL so that it could describe any available business service. Organizations can now write WIDL descriptions of the business services they provide, describing how a service is accessed, what kind of data it returns, and what parameters are needed to access the service. For example, a supplier can write a WIDL description of its stock inventory. The description specifies how a particular part must be described to check its stock and specifies how the stock quantity will be returned (e.g. in thousands, by weight, etc.). The supplier can then put this WIDL description up on its website and potential buyers now understand how to query inventory stock at the supplier.

A developer at another organization copies the WIDL description from the supplier's website and processes it using webMethods tools. There are several outputs as the WIDL is processed. First, just as with WIDL for automating websites, a set of proxies for use by client applications are generated. These proxies relay client requests to the B2B Integration Server. Second, rules for the B2B Integration server are created. These rules tell the server how to translate a client call into an XML (Extensible Markup Language) message containing all the information needed to satisfy the client request. Finally, a set of server stubs is generated. These stubs represent the starting point for integrating with backend servers that can actually implement the requests.

Once the WIDL is processed, the developer uses the client proxies to build a client application. For example, the client application may support inventory queries to a partner organization. WIDL provides bindings to the popular application development environments, enabling the client application to be written in C/C++, Java, JavaScript or Visual Basic. When a user enters a new query, the client application calls the appropriate WIDL service. This call is passed to an instance of the B2B Integration Server running locally at the originating organization. This server uses the rules generated from the WIDL to create an XML message containing the order request. This message is sent over the Internet to the receiving partner.

A second instance of the B2B Integration Server running at the receiving partner processes the message. Based on the message and the rules generated from the WIDL, the receiving partner's server then makes a call to the appropriate server stub. This stub in turn accesses custom integration code that connects it to the backend server that actually implements the inventory query.

Figure 3. Accessing remote business services using webMethods B2B Integration Server.

Despite the fact that the webMethods system uses document exchange to integrate the partner organizations, this exchange is essentially carrying object level API calls wrapped inside XML documents. Clients at the originating site are programmed to an API generated from the definitions in the WIDL at the receiving site. And servers at the receiving site are integrated with a server API generated from the same WIDL. By using XML documents to pass information between organizations, webMethods avoids the security issues associated with other object level electronic business systems. But, because the two business partners are tied together at an API level, webMethods does not avoid the integration costs and deployment costs associated with object level electronic business systems. In essence, webMethods has enabled the use of XML document interchange as the distributed object system.

Because webMethods has addressed the security issues and lets organizations partner in a loosely coupled manner, the system is appropriate to use in cross-organization deployments. The barriers to deployments present in SanFrancisco and CrossWorlds solutions have been addressed. And because webMethods is wrapping object level API calls inside XML documents, the system can support much richer interactions than an EDI-based system. At the same time, these rich capabilities mean that partner organizations must coordinate system deployment and evolution.

Because WIDL is written to describe the services offered by a business, each business is likely to expose completely different business services. This means that each time an organization needs to access the services of a new partner, the organization will need to do custom integration work. And very little of that work will be reused when the organization wants to work with a new partner. It's easier for the business offering the services: it can describe the services once and then put the burden of accessing those services on its partners. This burden poses a barrier to businesses looking for short term and dynamic partnerships.

Finally, WIDL remains a proprietary technology foundation. webMethods has submitted WIDL to the World Wide Web Consortium (W3C) for standardization, but the W3C has undertaken no activity related to WIDL. And there are no products available from vendors besides webMethods that make use of WIDL. Thus, despite the fact that WIDL is built on XML, companies that use webMethods's products are using a technology that is just as proprietary as the other middleware systems.

The webMethods system is thus appropriate for the same kinds of relationships as EDI and Extricity: long-term, coordinated business partnerships. It offers more extensibility and potentially lower integration costs than EDI and it lacks the process focus of Extricity. However, it is not appropriate for supporting new, more dynamic, Internet business opportunities.



Previous: Cross Organization Electronic Business System Approaches		Next: Approaches: CBL