- The Problem: Sharing Data
- The Solution: Distributed Application Development
- The Web Architecture
- Modular Design
- Message Passing
- Error Handling
- The Web Service Architecture
- The Baseline Specifications of Web Service Architecture
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
The Solution: Distributed Application Development
Distributed application development is the art and engineering of getting data from one machine to another. This data can be of almost infinite variation: purchase orders, customer data, digits 100 through 200 of pi, and so on. There have been many technologies for building applications that can send data back and forth. CORBA (Common Object Request Broker Architecture), RMI (Remote Method Invocation), and DCOM (Distributed Component Object Model) are just a few.
However, all of these have had flaws, and none has ever caught on for ubiquitous and heterogeneous environments. Most haven't even tried to make that a design goal. For example, DCOM is based on COM (Component Object Model), which is a binary standard that has virtually no deployment outside of the Microsoft Windows platform. Although using DCOM across platforms is technically possible, it is wishful thinking to think that DCOM would ever be employed in such an environment. No one has ever really tried and succeeded in a stable and cost-effective manner.
Common Object Request Broker Architecture, or CORBA, is a distributed technology (actually, a specification of a technology) that can and does work in heterogeneous environments. However, for many reasons, including that many developers find it difficult to implement CORBA-based applications and services, CORBA has never really caught on.
Simple Object Access Protocol, or SOAP, is a new step in the world of distributed applications. Web service technologies such as SOAP have made much quicker inroads for distributed application development than did earlier technologies. Among the many reasons for SOAP's success, the most important are that it
Leverages the Web architecture where appropriate (e.g., XML and other Web standards such as HTTP).
Uses a modular design.
Creates a message-passing architecture that doesn't force a particular implementation, programming model, or language.
Assumes that failure will occur during processing, and allows for processes to detect this easily.
The sections that follow closely examine these reasons for SOAP's success.