At first glance, the OSID Specification reads as a set of services designed for use by an application as illustrated below. While the picture is simple, the Application in this case would be required to understand the dependencies among and within these Implementations as well as being responsible for shuttling data between them. The very knowledge the Application would require to accomplish this nails the Application and Implementations together. Thus, the organization of the OSIDs can make the difference between interchangeability and Fortran.

Consider the above example of a Repository Service whose Implementation includes a remote server that in turn requires user authentication. By making direct use of the Authentication OSID, the Application is deciding what form of authentication the Repository service requires. But the authentication mechanism is specific to the Repository Implementation and should be decided by the Repository Implementation. Also, by passing Authentication through the Application, the Application then ties itself to Repository Implementations that share the same Authentication mechanism (if this doesn't appear to be a problem, think about migrating to Kerberos v9).

The fact that Repository requires Authentication is an implementation specific characteristic that should be masked from the Application. It is the responsibility of Repository to do what it takes to implement the Service, just as it isn't your responsibility to bring your own drinks to a restaurant (unless you're in Utah). If the Repository Service requires certificates, then it is the Repository's responsibility for getting them, with a little help from an Authentication Implemenattion.

An Application wants to use the Repository. The figure below illustrates all the Application needs to know about that Repository. Not all of them may require Authentication. Some may require other Services such as Scheduling or Messaging. These OSIDs supporting Repository are loaded as part of its own Implementation. In this case, the Repository Implementation is in essence the Application of the Authentication OSID. The Authentication OSID is in turn the Application of the Agent OSID.

Figure 2: a better use of OSIDs

OSIDs can be layered. Implementations may make use of one or more OSIDs to fulfill their own service contract. In fact, it is this layering that is in a large part responsible for the flexibility achieved through interface design.

This layering is essential when an Application wants to access multiple Implementations of the same Service. Each Implementation may make use of different OSIDs to support itself. In the following example, an Application wants to simultaneously access multiple Repository Services whose Implementations depend on different Authentication Services and each Authentication in turn makes use of a different Agent Service. The fact that Authentication exists inside Repository is hidden from the Application while the existence of Agent is in turn is hidden from Repository.

Figure 3: an Application juggling multiple Implementations

Each Implementation should not always require its own custom OSID Implementations underneath. These are intercheangeable legos if designed properly. Blue Authentication may be the standard Authentication Implementation used inside an enterprise that always makes use of Blue Agent that implements PeopleSoft.

The red and green Repository Services are located at another site and require yellow Authentication. The person who implemented yellow Authentication likes to make use of Logging services. Red Logging differs from Blue Logging in that its messages are sent to a remote database oriented logging server that requires its own Authentication while blue Logging is a cover for syslog. Etcetera and etcetera.

The point is that the details of what an Implementation performs is not exposed to the Application. We as programmers, integrators, managers and supporters may need to understand these details intimately but they are not exposed to the Application code. An OSID like Authentication may get invoked many times within several other OSID Implementations. They may be the same Implementation or not. The variety of Implementations used depend on the variety of the jobs that need doing and the design goals of a given environment.