Web services are not distributed objects

One of the most important concepts to understand about the web services framework (WSF) is that it is not a distributed object system. Web services communicate by exchanging messages -- it's more like JMS than RMI. The WSF doesn't support remote references, remote object garbage collection, or any of the other distributed object features developers have come to rely upon in RMI, CORBA, DCOM, or other distributed object systems.

The fundamental purpose of the WSF is to enable interoperability across dissimilar systems that don't necessarily understand concepts such as method overloading, object inheritance, and polymorphism. Hence web service interfaces should not expose these OO concepts.

A service should expose a document-oriented interface rather than an object-oriented interface. The basic best practices are:

• Flatten object graphs. Don’t expose language-specific object collections, such as maps, lists, or datasets. Instead convert all collections into arrays.
• Don’t use overloaded methods. Each method should have a different operation name.
• Expose a "chunky" interface rather than a "chatty" interface. In other words, don’t expose getter and setter operations for every member in the object class.
  

These best practices relate back to the differentiation between message exchange versus distributed object systems. When using distributed objects, the object resides on the server side, and the client invokes operations on the object using a proxy. The client does not have its own copy of the object. When using a message exchange system, the client side application should have its own object -- not just a proxy. (And – by the way – the client’s object may be different from the server's object.) When the client communicates with the server, it simply passes data, not behavior. It's much more loosely coupled.

It may be necessary to build an abstraction layer between the WSDL interface and the application that implements the service. This abstraction layer performs the necessary mapping between the document-oriented WSDL interface and the application's object model. It also provides much better insulation for flexibility and change.

For best interoperability, developers should use document/literal with the “wrapped” programming convention. .NET uses the “wrapped” style by default. The JAX-RPC specification also requires support for the “wrapped” style. The "wrapped" style supports a programming model that makes document/literal feel like RPC style. "Wrapped" style is very similar to RPC/literal, except for two important distinctions:

1. .NET supports "wrapped" style, but it doesn't support RPC/literal
   
2. "Wrapped" style defines a schema of the full soap body (which makes it very easy to validate), while RPC/Literal only defines type information rather that the full schema of the message elements (which makes validation slightly more complicated).

Please see my previous blog entry on the "wrapped" style for more information.