It's tempting for those with a background in distributed objects to look at the upcoming Web services standards as just another set of distributed object technologies, probably with some misgivings about reinventing the wheel. Conversely, with the advent of Web services it may be tempting to think that distributed objects are no longer important. After all, Web services have

• A transport protocol: SOAP (Simple Object Access Protocol)
• Something like an interface definition language: WSDL (Web Services Definition Language)
• A location service: UDDI (Universal Description, Discovery, and Integration)

The object-oriented platforms CORBA and J2EE have been tremendously successful for building and integrating applications within the enterprise. The document-oriented XML technologies associated with Web services are rapidly gaining popularity for business-to-business integration between enterprises. Total business integration needs to address both of these areas.

Object-Oriented vs Document-Oriented
To a distributed object veteran, a Web service looks like yet another distributed object system. Based on this comparison, it's tempting to simply expose existing CORBA or Java objects as Web services by mapping them to WSDL. However, XML has a different heritage. It's document-oriented, not object-oriented. Web services should be considered a medium for implementing document-exchange systems and not as simply a new flavor of distributed object systems.

How Document Exchange Is Different
In a document-oriented system, document design is key. Interfaces are just a way to pass documents. Contrast this with object-oriented design, where interfaces are key and data structures are just convenient packages of data for the operations on the interfaces.

Document-exchange systems have:

1. Larger, richer data structures: so much richer that we call them "documents"
2. Looser coupling between agents
3. More asynchronous communication

Object-oriented systems behave like people having a conversation. document-exchange systems behave like people sending old-fashioned paper documents to each other.

Suppose I want to buy a hat. The OO approach is to find a hat shop and talk to a salesperson (object). A request/response session follows: "Do you have a size 16 black fedora?" "We don't have that color." "What color fedoras do you have in size 16?" "Brown and beige." "I'll take a brown size 16 fedora." "That'll be $19.95."

Things to note:

• Simple data structures: hat type, quantity, list of colors, price
• Tight coupling: Replies are meaningless without the context of the question. The phrase "brown and beige" tells you nothing useful on its own. Also, I have to understand who I'm talking to (the interface). I have different conversations with hat salespeople than with waiters
• Synchronous communication: Because of tight coupling, I must be able to associate replies with requests. My subsequent requests often depend on a previous reply

Things to note about the document exchange:

• Complex, structured, self-describing data: I got an entire hat catalog. I knew it was a catalog by reading it, not by knowing that it was a response to my request.
• Loose coupling: I didn't need to directly associate the catalog and my previous request because the catalog is sufficiently self-describing to anyone who knows how to read a catalog (understands the schema).
• Asynchronous communication: Enabled by the self-describing data and loose coupling. I couldn't know directly that the envelope containing the catalog was a response to my request, I only knew that indirectly by opening it up and reading the catalog inside.

That doesn't mean you shouldn't map distributed objects to Web services! On the contrary, distributed object platforms are the ideal underpinning for an enterprise-grade Web service. It does mean you need to design some of your distributed objects with the knowledge that they're going to be Web services. These service objects will typically delegate their work to many smaller-grained distributed objects in a distributed system underlying the Web service and will typically pass larger chunks of data in a single call than the objects in that system.

To a distributed object veteran there's a strong analogy here. Consider CORBA or EJB objects in relation to nondistributed C++ or Java objects. You can expose just about any Java or C++ object as a distributed object, but good distributed system design dictates that the distributed objects are more service oriented than the fine-grained, non-distributed objects that they use internally to implement their interfaces. There is a natural progression: Web services are built on distributed objects, distributed objects are built on nondistributed programming objects. At each step the granularity becomes finer.

Where Does Each Approach Work Best?
The short answer is to use distributed objects to build high-performance systems with a well-defined architecture, and Web services to connect independent systems in a loosely coupled fashion based on shared business processes and documents.

Distributed Objects
Distributed objects are an extension of classic OO programming techniques familiar to developers. Well-designed distributed object systems can deliver very high performance and scalability, as has been proven many times in live deployed systems. Classic examples are manufacturing process control and telecom switch management.

A distributed object system requires a well-defined architecture with stable interfaces between components and some level of system-wide agreement on infrastructure technology. This requirement can be a problem for business-to-business integration because there may be no agreement on infrastructure and no system architecture shared between trading partners. Often the most you can hope for is a set of agreed-on business processes and document formats.

Document Exchange
Document exchange is an electronic version of the traditional paper-based processes familiar to business people. It works best in the business world, where it can reflect traditional business documents and processes. Web services are the natural way to implement document exchange because they build on XML and HTTP. These standards currently are pretty much the only choices for portable document representation and Internet communication respectively.

Web services are unlikely to perform adequately as high-performance system components due to the size and parsing overhead of XML documents. It's hard to imagine a telephone exchange being successfully implemented as a set of intercommunicating Web services. Yet it's easy to imagine some types of access to such a system as a Web service. For example, for regulatory reasons a telecom carrier might build a Web service that allows other carriers to request phone numbers on their network. Web services are ideal for this kind of interaction, where you can't assume that there'll be agreement on CORBA or EJB interfaces.

Bringing Them Together
Document-oriented Web services can be implemented on top of distributed object systems. Distributed objects are the building blocks of a robust, scalable, highly available service within an enterprise. Web services are highly accessible entry points to those systems. They enable automation of shared business processes between trading partners with very different internal systems.

A Web service can be built by directly mapping the interface of a distributed object. As we have mentioned, the interface should be designed to be document-oriented to make a good Web service. That means coarse-grained, data-oriented operations rather than the fine-grained, object-oriented operations typically found in a distributed object interface.

Alternatively, a Web service can be built on a more explicitly document-oriented and workflow-based model. The arrival of a document invokes a chain of events that may include calls to multiple distributed objects and other back-end resources, using data derived from the document. Outbound documents are constructed by composing data gathered from distributed object calls and other resources.

Conclusion
At first, Web services and distributed objects may seem to be just different flavors of the same kind of distributed computing. However, they have very different underlying paradigms, and are best suited to different types of integration tasks.

Distributed objects are best suited to building high-performance systems with a well-defined architecture. Typically, you find such systems inside an enterprise. It's difficult to create the technical agreement and coordination needed to build a distributed object system that spans between enterprises.

Web services are best suited for implementing shared business processes between enterprises. A Web service provides a common facade for enterprise-specific systems, making it easier to create the technical agreement needed for automated business-to-business integration.

The technologies work hand in hand: distributed objects provide the underpinning for the systems that run each enterprise; Web services provide the connectivity between the systems in independent enterprises.

Author Bio:
Alan Conway is a senior engineer at IONA Technologies and has been with the company for more than five years. He has extensive experience with both CORBA and J2EE. Conway has a keen interest in the emerging Web services area and how it complements established infrastructure technologies. alan.conway@iona.com