- Defining .NET
- .NET Goals
- .NET Services
- .NET Affects the IT Professionals
- .NET Affects the User
- The Loose Coupling of Web Services
- .NET Infrastructure
- Summary
- Q&A
The Loose Coupling of Web Services
Now that we have explored .NET goals and its effects on developers and the IT community, we turn our attention to an idea presented earlier in this chapterloose coupling. At a basic level, the notion of loose coupling means that applications or services are not tightly tied to functions. This means that Web Services can perform a variety of different actions with different languages through different applications on different platforms. Obviously, that is a tall order to fill.
The idea of loose coupling isn't new. Programmers and developers have spent time working with the idea of loose coupling in terms of distributed networking through the Distributed Component Object Model (DCOM), as well as other distributed application models such as CORBA and RMI. These models enabled networks to run services on remote systems and bring more power to the local network.
The idea of distributed transactions on the Web, however, is new. DCOM and other application models do not scale to the Internet because they are typically built on similar infrastructure. In other words, you can't change the server interface without also changing the client interface. This model clearly does not work on the Internet.
Through loose coupling, process and services are not tied to one specific infrastructure. This feature enables applications to adapt to the current need without expecting an exact interface. To achieve this goal, XML is used to present data in a non-application-specific way. In this manner, loose coupling is accomplished because the data is not tied to one specific source or structure. Along with XML, HTTP (or even SMTP) is used so that applications and interfaces communicate with each other via messages, rather than through a component interface. Using this approach, the sender of the message makes no assumptions about how the receiver will accept and process the message, as would occur in a typical transaction model. Rather, the sender is not concerned with the differences between recipients because the data exchange is message based.