Traditional distributed object models use the concept of interfaces to model interactions. This is a useful technique because the language in which an interface is defined can be completely independent of any language used to implement that interface. However, most traditional distributed object infrastructures were designed for distributed systems whose deployments were limited to within a single enterprise. They are thus suited to deploying services across organizational boundaries due to the following inherent characteristics of the inter-enterprise web services:

Web services are loosely coupled: Changes to a web service should not require re-installation of software components by the users of the web service.

Web services require dynamic binding: Typically, application designers bind software components to one another at development time. Web services, on the other hand, are likely to be implemented and provided by different service providers. In addition, we must enable easy changes to the services we are using, easy discovery of new services, of new capabilities of existing services, and of new binding or location information of services.

Web services communication is based on a Document Exchange Model: Traditional component frameworks support a network-object model of interaction in which objects of strictly defined types are transferred between components using a request-response interaction pattern. Cross-organizational business interactions do not fit this framework well for two reasons. The interfaces of services may need to be changed in ways that cannot be captured by simple extensions. This precludes the use of object inheritance to support the inter-operability in presence of change. Secondly, interactions can be long lived. Therefore, asynchronous exchange of XML documents is better suited for cross-organizational business transactions.

Web services in different enterprises are likely to use different semantics. The interpretation of the data communicated among enterprises is different for each enterprise. For instance, the address field of a purchase order may have different significance for the parties. If a uniform object model is used, the semantics of data often tends to be similar or homogeneous contributing to tighter coupling.

Web services in different enterprises require a distributed model of security. Security responsibilities are split amongst the enterprises. Each enterprise manages its end of the security infrastructure independently.

Web services from different enterprises may be built using heterogeneous technology stacks. Each enterprise decides on the computing infrastructure independently taking into consideration many factors.

Web service interactions must be able to traverse corporate firewalls. Traditional distributed systems are tuned for applications that are deployed within the enterprise; Web services may be deployed from behind Firewalls.

It is our position that in the web-services world, there needs to be a clear distinction between the public interface supported by a service and its private process that implements the public interface. This distinction enables flexible and dynamic inter-operability between Web services; for example, a service implementor can re-implement a service as long as it still supports the public interface. We base the definition of these public interfaces on the document exchange model, meaning that service interaction points are defined in terms of the documents that are exchanged with the service rather than method signature definitions.

In addition to defining service interaction points, an enterprise deploying a web service also needs to specify the valid sequences of message exchanges (interactions) that the service supports. For instance, RosettaNet PIPs define the interaction sequences that are specific to supply-chain like interactions amongst enterprises. However, RosettaNet does not support loosely coupled web services, and thus does not provide a generic mechanism for defining new interactions among services running in different enterprises. We identify that a generic, open ability to define the valid interaction sequences as part of the interface definition is necessary for enabling loose coupling amongst web-services. Such definitions would enable clients to determine dynamically the relative order in which the documents are to be exchanged to perform any unit of work with the service.