Get Acquainted With SOA and Indigo (Continued)

When you use objects instead of services to create a distributed system, little distinguishes a local object call from a remote object call: The whole idea of distributed objects is to make remote objects look like local objects. This can lead to an overuse of calls to distributed objects, where the expense is not obvious to a developer. In SO, you can't fall into this trap: Accessing a service is distinctly different from accessing a local object.

Distributed systems must tolerate change. Some systems are built in incremental stages, and services come online slowly over time. Any system might be subject to new requirements that result in the addition, upgrading, or removal of services. It should be possible to change a service without disrupting the overall system.

In SO, the topology of a distributed system is expected to change over time, and its services are designed to be deployed, managed, and versioned independently. There's no controlling authority to manage these changes, so services have to be robust enough to survive when other parts of the system are offline. Even though a service might depend on other services to perform its function, it should not fail when they are temporarily unavailable.

In a distributed object solution, the parts of an application often have to be deployed as an atomic unit, which can be terribly inconvenient in a production environment. Making a change to an application might require the entire solution to be rebuilt, redeployed, and restarted. Upgrading a server can require upgrading all clients. In SO, modifying a service's implementation doesn't cause a problem for the other services because they're loosely coupled.

It's important to keep in mind that services share schemas and contracts, not classes and types. SO maintains implementation independence between services by being careful about what they exchange. Services use agreed-upon schemas to pass data and contracts to specify behaviors. They don't pass classes or types. Services have no knowledge of each other's execution environment—and have no need to know—because the information they exchange is completely platform-neutral.

Contrast this to a distributed object solution, where types and classes are passed across end points, forcing the same type system on all parties. This makes for a tightly coupled system and holds all parties hostage to the same execution environment.

Services should expose data and behavior relevant to their capabilities, not their implementation. Business actions and business documents are likely to remain stable. A service's interface will be equally stable if that's what it models.

Compatibility is Policy-Based
Services don't just blindly access each other. They need to determine areas of compatibility and agree on how they will interact. Every service provides a policy—a machine-readable description of its capabilities and requirements. Policy allows services to find common ground.

Using policy allows the behavior of a service to be separated from the constraints of accessing the service. Imagine moving a service to a different environment where the parties allowed to access it are different. The policy changes to reflect this. The service behavior doesn't change at all.

When sophisticated services talk to each other, policy is used to determine the advanced capabilities that are mutual. When a limited service is in the mix, policy is used to find a reduced set of capabilities that both services can support. Policy is what allows services designed according to SO principles to interoperate with traditional Web services, which have limited capabilities in comparison.

In a service-oriented solution, services are loosely coupled, which means all parties make few assumptions about each other. Loosely coupled systems have excellent prospects for longevity, and they feature many compelling benefits. For example, services are isolated. Changing the internals of one service doesn't force matching changes, rebuilding, or restarting of other services. Services are also location-independent. Whether a service you need is on the same machine or halfway around the world, you access it in the same way. Services are also transport-neutral, protocol-neutral, and format-neutral. This means communication details between parties are flexible, not fixed.

Another key benefit: Services are platform-independent and implementation-independent. A service doesn't need to know anything about another service's execution environment in order to interact with it. Services are also scale-invariant, which means they scale well in all directions. For example, a service can be scaled out by fronting it with a router service that distributes traffic among a farm of services. You can also make services time-independent. If services make use of queue-based communication, they don't have to be online at the same time to interact. Another nice feature of services: They can be address-agnostic. If services employ a discovery mechanism, they can locate each other without any prior notion about where they reside. Finally, behavior is separated from constraints. This means that restricting, relocating, or outsourcing a service requires changes only in policy, not to the service itself.

You might wonder how services compare to Web services. They are related but not identical. You can think of services as the successor to Web services. Like Web services, services make use of SOAP, XML, XSD, WSDL, and other standard protocols. Unlike Web services, services aren't limited to HTTP request-reply communication: They're free to use other transports and other message-exchange patterns. Services are also more mature than Web services, providing enterprise-class features such as security, transactions, reliability, and performance. Services haven't forgotten their Web service roots, however. Through the use of policy, services and Web services can interoperate.