The Fine Print

Summary

The concept of interoperability is nuanced.

Between Here and There

The OSID APIs are designed to be software interfaces where concerns of serialization and data store are notably absent as they are assumed to be handled under an interface as part of an OSID Provider.

From a system point of view, OSIDs appear to be high-level interfaces that leave a lot up to the imagination. This is because the interfaces face OSID Consumers. OSIDs do not describe how an OSID Provider ought to be implemented because it wants to allow for just about everything. From an application point of view, the OSIDs appear to be a disconnected set of low-level interfaces. The OSIDs are optimized for interoperability at the expense of the simplifying the specific needs of any particular application or development framework.

The Okapia development tools close some of these gaps through many canned implementation classes based on more common programming patterns.

Say More About This Interoperability

Interoperability, as the OSIDs use the term, can be thought of as the ability to swap among OSID Consumers and OSID Providers. OSIDs may also be extended in such a way to include interfaces and manage data not defined in its core specification. These two statements appear to be at odds.

Interoperability is not a yes/no issue in the OSID world. There are many shades of gray. OSIDs think of the degree of interoperability that can be achieved between an OSID Consumer and an OSID Provider and more importantly, and how can any interoperability gaps be identified and remedied by a third-party. 

Let's take a simple interoperability issue. One OSID Consumer is wired to use a Forum OSID and the desired OSID Provider implements a Blogging OSID. We don't have agreement on the service contracts in play. We do have something to go on. We know what the OSID Consumer expects and we know the contracts. An integration option is to add an OSID Adapter that connects these two contracts together. This may involve a little squinting and twisting, but forum posts are not very different from blog entries. This integration work is definable because we are working between two specifications at a high enough level where a third party can be effective. This integration work is non-destructive because it avoids changes to the code bases of either party.

OSID Adapters are typically easy to create unless the domains are so far off where such disagreements are more fundamental in nature. They also open the door to a broader set of interoperability possibilities that can create delightfully unexpected results with relatively little effort.

The extensible aspect also poses interoperability challenges though without extensibility, we'd never have the complete solution available for us. These out of band agreements should always be defined in specifications (OsidRecords) and these specifications properly identified (Types). More on these mechanisms to follow.

OSID interoperability is an issue at many levels. While plug-and-play is a noble goal, this level of interoperability cannot occur where unknown and required out of band agreements exist. The interoperability gap is measurable and often the integration involves OSID Adapters which can be reused in other scenarios.

Interoperability in itself is an abstract concept. In the physical world it is often related to things like shape. For example, Lego’s have a particular shape that allows them to fit together. The shape consists of a pattern of bumps. This pattern is very precise. The bumps are cylindrical with an exact diameter, height and distance apart. The fact that the bumps might be 2 mm high rather than 3mm, is not what is important about Legos. It’s the fact that they all have the same pattern. This mean any two Legos can fit together, and that two Legos can be pulled apart and a third inserted in between.

The same holds true for OSIDs. They do have a precisely defined pattern, but the details of this are less important, than what the effect of this pattern is. It allows two pieces of software that correspond to this pattern to easily fit together. It also allows for inserting an extra piece of software in between the original two without effecting either.

Hey, What if the Interfaces Change?

This is the compelling reason we want well thought out prefactored service models that go above and beyond what we need today provided we have some means of easing into it over time and why extensibility is important.

Currently, OSID 3K is in a release candidate cycle. New packages and contracts can be added after final release with minimal disruption. Package, interface and method additions can be mitigated with default code injected into the OSID Runtime. Changes to the service models and patterns around the contract methods will cause heartbreak and despair.  The OSID strategy is to evolve slowly and try and constrain post-release changes to additions.  Okapia has thousands of Java classes hanging off these OSIDs.