In the physical world, enterprises use many intermediaries in the course of conducting business with one another. For example, the Federal Express package delivery network greatly simplifies the transport of goods and communications between organizations that, in lieu of substitutes, would have to establish custom point-to-point delivery systems. A web services network performs analogous intermediary duties by facilitating communications between web services operated by different enterprises. As in the physical case, the intermediary adds tremendous value by solving a number of hard problems that businesses would otherwise be left on their own to address. One startup, Grand Central, has been championing the web services network concept and has already fielded such a service. (See Resources.)

Web services for automated backend business-to-business integration

Before diving in, a few words are warranted on the subject of web services and inter-enterprise projects. A common image conjured by the term "web services" is of an enterprise portal that aggregates data and functionality from multiple sources into a single end-user view. Web services standards do support this sort of foreground integration, which eases the creation of end-user applications from distributed elements

Significantly, however, web services are also suited to background integration between applications. Here, I'll focus on this background scenario in which applications use web services interfaces to link to one another, server-to-server, for automatic execution of business processes.

This scenario presents particular challenges when the web services involved are operated by different organizations, and that is the case which I am concerned with here.

Back to top

Intermediaries provide context support missing from standards

Integration projects naturally tend to focus on explicit issues of data formats and procedure calls, but the context involved in the integration of components is of comparable importance.

Web services standards are powerful in their simplicity and openness. However, their scope currently does not extend beyond content-oriented issues of data format and service description to the context-oriented issues of the interaction between services. By way of physical analogy, standards for address format, packaging style, and description of the existence of "ship" and "receive" methods do not address the contextual matter of what to do when a package is delivered and the office is closed. Return to sender? Try to redeliver tomorrow? Leave at the door?

One way in which Federal Express adds value as an intermediary is by defining a common interface for package delivery. Each organization, with its own peculiarities regarding the hours, location, and policies of its shipping and receiving department, establishes a connection with Federal Express. In this way, N companies define N relationships, rather than the order N2 links that would otherwise be required. Tremendous efficiency results. A web services network brings the same orders-of-magnitude cost reduction to inter-enterprise web services projects. In both cases, the intermediary adds value by addressing context-oriented requirements. Returning to the analogy, Federal Express can allow either sender or receiver to make an independent context-oriented choice as to whether a package can be left without signature, freeing the parties from worrying about coordination on this point.

Back to top

Context-oriented requirements for inter-enterprise projects

Many web services projects to date have been intra-enterprise, executed behind the firewall where context is often implicitly understood. As veterans of inter-enterprise efforts using other technologies are well aware, however, the situation is considerably more challenging outside the firewall, where the operators of various components have little control over (or visibility into) each other's systems. Common contextual understanding cannot be taken for granted in this scenario.

Inter-enterprise web services projects present two broad categories of challenging context-oriented requirements:

I. Communication requirements:
Elements required for integration across firewalls over the Internet: asynchrony, encryption, reliability & non-repudiation, and polling.

II. Collaboration requirements:
Elements required to safely publish web services or to consume and integrate web services to form inter-enterprise business processes: access control, implementation abstraction, routing, and registry & discovery.

Delving deeper into each of these, we find these requirements are challenging to deal with on a direct enterprise-to-enterprise basis.

I. Communication requirements

• Asynchrony
  Inter-enterprise background integration projects are generally better off using asynchronous messaging, as it allows participants to operate with minimal interdependency. This is often a requirement of integrations that traverse firewalls, where the systems being connected may have different policies regarding responsiveness and autonomy. The asynchronous approach is particularly valuable in executing complex business processes between companies that may take minutes, hours, or even days to complete, where waiting or blocking on a response would be impractical and non-scalable. The logistics of asynchrony coordination are daunting, however, when considering a multi-company interaction. Who holds messages that can't be delivered?
• Encryption
  Security via encryption is a standard requirement of enterprise communication over the Internet. While this functionality is relatively easily accommodated using existing standards, use of different standards or imposition of different policies complicates multi-company business processes. In a multi-company integration, which organization has its standards and policies adopted by the others?
• Reliability & non-repudiation
  Like encryption, reliability and non-repudiation are standard requirements of business-to-business communications -- yet they are particularly difficult to handle in a direct business-to-business scenario. Who decides who is responsible if a message is not received? What authority provides for non-repudiation?
• Polling
  In a given web services communication, one party is naturally the sender, while the other is the recipient. However, the recipient may not wish to incur the costs of continuously listening for incoming messages, preferring instead to periodically poll the sender for them. Generally speaking, the web services model is appealing in that it can meet the requirement of no changes being made to an organization's firewall. However, that advantage can be lost if parties have to make adjustments in order to continuously listen for messages. Who gets to enjoy the luxury of polling while other parties have to listen?

II. Collaboration requirements

• Access control
  The exchange of sensitive data or exposure of proprietary services necessitates careful trust management among participating organizations. The challenge is that business processes often extend beyond two parties in a point-to-point relationship. Instead, the architecture must meet the requirements of managing dynamic many-to-many relationships. As a result, inter-enterprise projects require a trust management model that builds on access control provided by standards like certificate authentication. Who maintains this model in a multi-company integration?
• Implementation abstraction
  Adding a layer of abstraction to a system's interface greatly assists in meeting the requirement of minimizing service management costs. Creating separate public interfaces -- uncoupled from their backend implementation -- allows web services to be changed or upgraded without breaking the systems that may be dependent on them. On which side of the fence is this abstraction layer located in a business-to-business integration?
• Routing
  Implementation of a specific business process may require a chaining together or orchestration of multiple web services among different businesses. Inter-enterprise business process management is unique in that the specific processes being orchestrated are typically simpler than those found behind the firewall, yet by virtue of the fact that different companies and systems are executing them, they can be more difficult to implement and manage. As such, business process management components for web services must both provide visibility into a process as it executes, and also manage the state of a process as it brings disparate enterprise systems into play. Which party in an automated multi-enterprise business process manages the routing involved in such orchestration?
• Registry & discovery
  Inclusive of the well-known UDDI specification, registry & discovery cover the requirements associated with publishing and finding the location, binding, and access-control information for a web service. It is useful to differentiate between the requirements of private collaboration between a limited set of partners (typical of enterprises) and public advertisement of a service (typical of service providers). The difference between these two, and the requirements of enterprises specifically, has led to the notion of a private UDDI directory where registry & discovery can be controlled according to policy for a limited set of participants. Which party maintains such a registry?

Back to top

Using intermediaries to handle context-oriented requirements

The context-oriented requirements discussed above shout out the need for an intermediary in inter-enterprise projects. In lieu of an intermediary, organizations must engage in decision-making over who takes which roles, with both technical and business headaches resulting. The difficulty is amplified exponentially as the number of parties involved in the integration grows. Moreover, none of these intermediary functions are necessarily the specialty of the businesses seeking to integrate. Just as in the package delivery network analogy, there is a strong need for a specialized intermediary whose core competency is specifically in meeting these context-oriented requirements.

Back to top

Web services networks: powerful intermediaries

A web services network operates as a ubiquitously accessible service to meet the communication and collaboration requirements discussed in this article.

As a service operating on top of the Internet, a web service network's functionality can be easily incorporated into existing applications.

On the communications front, a web services network can queue messages for asynchronous delivery and provide for queue access via polling. Like a package delivery network, a web services network can be accountable for reliability and security, and provide Federal-Express-like message tracking as a non-repudiation mechanism. In terms of collaboration, an intermediary can act as a point of trust management between services. Furthermore, it is uniquely positioned to route messages between services in support of a multi-enterprise business process. Finally, by exposing their interfaces via a web services network, systems gain a layer at which to introduce an implementation abstraction.

In short, just as businesses enjoy significant efficiency by coupling their shipping and receiving departments to package delivery networks rather than tying them together directly, businesses can greatly simplify inter-enterprise web services projects by utilizing the functionality of a web services network. In both cases, intermediaries add great value by solving hard problems associated with context-oriented requirements, freeing enterprises to focus on their business. Grand Central has staked its claim to the space and merits the attention of developers working on inter-enterprise web services projects (See Resources).

Resources

• Grand Central is an intermediary for web services between companies.
  
  
• Federal Express is investigating web services for use in their systems.
  
  
• Intelligent EAI, a section of CMP's Intelligent Enterprise, covers integration issues regularly.
  
  

• Business-to-business integration with tpaML and a business-to-business protocol framework from IBM Systems Journal describes some of the challenges inherent in B2B integration, and proposes some solutions.
  
  
• Intermediaries: An approach to manipulating information streams, also from IBM Systems Journal, examines many different types of intermediary services in the real and virtual worlds, mainly (but not exclusively) as they apply to information streams.
  
  

About the author

Rate this article

Comments

Back to top

Table of contents

• Web services for automated backend B2B integration
• Intermediaries provide context support
• Context-oriented requirements
• Using intermediaries
• Web services networks
• Resources
• About the author
• Comments