The Case for Interoperability

Summary

The goal of the OSIDs is to promote interoperability among a wide variety of service consumers and providers.

Interoperability

What the OSIDs call interoperability is not just the communication between two parties where we worry about the over-the-wire protocols and their associated APIs. The concern of the OSIDs is the ability to change the components of a software system. This includes the application components as well as the underlying system components.

Interoperability is the ability to swap service implementations (OSID Providers) as well as the ability to swap application components (OSID Consumers).

Many To Many Interoperability

OSIDs are interface specifications designed to separate software components along consumer and provider boundaries. By doing so, OSIDs enable other OSID consumers to interoperate with other OSID Providers. Note the emphasis is on separating software components, not what ought to be delivered and accessible to remote clients. OSIDs can be used for both internal and external consumption. In fact, there's no difference in the OSID world.

The goal of the OSIDs is to achieve many-to-many interoperability.

Many-to-Many interoperability is the use of the same contract among many OSID Consumers and OSID Providers. Each OSID Consumer and OSID Provider does the work of mapping to an OSID once, opening the door for interoperability among many other systems and components. This is opposed to the model where My Web Site needs to support many different APIs and ways of doing things for each system integration.

Interoperability is more than a one-way street. The most expensive part of any system is its applications. The amount of work, creativity, and resources spent far outweigh the infrastructure behind it. This investment deserves some protection. Protection from changing underlying technologies. The OSIDs define neutral interfaces that can be used to cover any number of technologies. They can also be used to isolate changes around an application where such changes typically impact the lifetime of the application.

Internal System Design

OSIDs are blind whether this integration is internal or external. Internal integration issues plague us all the time. This is especially true in larger systems that have evolved over time or developed piecemeal by different parties. By using the same separation techniques, OSIDs enable different pieces of a system to evolve independently or be developed in parallel. Change is inevitable, and we don't want to throw away or refactor a large investment because a change in technology rippled through an entire system.

Choice

Fundamentally, OSIDs promote choice. The choice to change select components of a system. The choice among service providers. The choice among applications. The choice to combine services together. The choice to implement your way of doing things. 

This works. We've used it.