Download (direct link):
Why Soap Services Are Better
CORBA, DCOM, and RMI are based on the RPC paradigm with tight coupling between what the client sends and what the server expects. The type and order of passed parameters are rigorously enforced because the parameters are marshaled and unmarshaled (the standard computer language for sending parameters across a network). This is a tighter coupling than required with soap services because soap services allow both an RPC and message paradigm (see the discussion about SOAP in this chapter). The RPC style of soap services is a mapping of the RPC paradigm onto the architecture of soap services: placing the XML encoding of the parameters into a SOAP envelope. The message-passing model is based on the exchange of messages and is far more flexible because of its looser coupling between client and server. Previous generations of distributed computation environments did not display the flexibility that soap services do.
Table 12.1 Distributed Computing Summary
I METHOD VENDOR RPC MESSAGING ACCEPTANCES
CORBA Consortium X Limited
DCOM Microsoft X Limited
RMI Sun X Limited
Soap services Consortium X X Everybody
Web Applications and Services 225
Many big players in the pre-soap service days are leading the push to soap services. A vendor's soap services development environment is aligned with its history regarding other distributed environments it has supported. The vendors agree on the big picture of soap services; however, they have different ideas about how soap services should be implemented. The biggest players have business models that play to their strategic business advantages: Microsoft  believes in using the Windows platform, while Sun  is focused on the Java language. There are also other, less restrictive environments, such as Axis from the Apache Group . Each system has advantages and disadvantages — the best choice depends on the particular attributes of your organization and what you want to do. The major vendors agree about what counts the most — it's not how you build soap services, but rather, it's what users can do with these services that creates value. Soap services have emerged as the best choice from the many different experiments in the realm of distributing computing environments. For the first time, industry agrees on a common method for access to remote resources across heterogeneous networks and systems. This is a good example of how learning from many generations eventually leads to a solution acceptable to most of the players — not an easy feat.
One powerful attribute of soap services that encourages innovation is the loose coupling between clients and servers. By agreeing on standards such as SOAP and XML, transferring data between all heterogeneous systems becomes easy. These standards explain how typed data is exchanged between systems that disagree about how data is represented. This loose coupling implies easy replacement of one soap service for another, if the defined interfaces of both soap services are identical. This loose coupling between the client and server with soap services gives consumers and developers tremendous flexibility in building and evolving these services because it promotes experimentation.
Why Implementation Platforms Don't Matter
Users and developers have very different views about how soap services are implemented: Users don't care, developers do. If you are developing soap services, choosing the development environment is a complex and difficult decision to make, but if you are the consumer of these services, you don't care at all. As discussed in this chapter, each vendor's solution has pluses and minuses; other open source solutions don't have as many features; there is no clear path to the future. Developers care about the total cost of development, which is dependent on the development environment. Different firms will find varying solutions that are the most
226 Chapter 12
cost-effective for them, depending on their in-house expertise. For example, financial organizations with strong Unix backgrounds will find Sun's J2EE and Unix/Linux the preferred platform on which to build soap services, while other firms without Unix skills will find Microsoft .NET the better solution. There is no best development environment because the choice is contingent on the organization's capacities and goals.
Most debate about soap services is about the best development and hosting platform, not the key points that make soap services valuable. Remember that the importance of soap services depends on who can use them and what the users do with them. Soap service clients are independent of the server platform and depend only on implementation of accepted protocols (XML, SOAP, . . .), thus the value to the client is independent of how the service is performed. The future looks bright for soap services because the vendors disagree only about implementation details, and users don't care about these details because clients can consume services regardless of the platform on which a service is hosted.