The Open Service Interface Definitions (OSIDs) is a service-based architecture to promote software interoperability. The OSIDs are a large suite of interface contract specifications that describe the integration points among services and system components for the purpose of creating choice among a variety of different and independently developed applications and systems, allowing independent evolution of software components within a complex system, and federated service providers.

The OSIDs were initially developed in 2001 as part of the MIT Open Knowledge Initiative Project funded by the Andrew W. Mellon Foundation to provide an architecture for higher education learning systems. OSID 3K development began in 2006 to redesign the capabilities of the specifications to apply to a much broader range of service domains and integration challenges among both small and large-scale enterprise systems.

The osid package defines the building blocks for the OSIDs which are defined in packages for their respective services. This package defines the top-level interfaces used by all the OSIDs as well as specification metadata and the OSID Runtime interface.

Meta Interfaces and Enumerations

• OSID: an enumeration listing the OSIDs defined in the specification.
• Syntax: an enumeration listing primitive types
• Metadata: an interface for describing data constraints on a data element

Interface Behavioral Markers

Interface behavioral markers are used to tag a behavioral pattern of the interface used to construct other object interfaces.

• OsidPrimitive: marks an OSID interface used as a primitive. OSID primitives may take the form interfaces if not bound to a language primitive. Interfaces used as primitives are marked to indicate that the underlying objects may be constructed by an OSID Consumer and an OSID Provider must honor any OSID primitive regardless of its origin.
• Identifiable: Marks an interface identifiable by an OSID Id.
• Extensible: Marks an interface as extensible through OsidRecords.
• Browsable: Marks an interface as providing Property inspection for its OsidRecords.
• Suppliable: Marks an interface as accepting data from an OSID Consumer.
• Temporal: Marks an interface that has a lifetime with begin an end dates.
• Subjugateable: Mars an interface that is dependent on another object.
• Aggregateable: Marks an interface that contains other objects normally related through other services.
• Containable: Marks an interface that contains a recursive reference to itself.
• Sourceable: Marks an interface as having a provider.
• Federateable: Marks an interface that can be federated using the OSID Hierarchy pattern.
• Operable: Marks an interface as responsible for performing operatons or tasks. Operables may be enabled or disabled.

Abstract service Interfaces

• OsidProfile: Defines interoperability methods used by OsidManagers.
• OsidManager: The entry point into an OSID and provides access to OsidSessions.
• OsidProxyManager: Another entry point into an OSID providing a means for proxying data from a middle tier application server to an underlying OSID Provider.
• OsidSession: A service interface accessible from an OsidManager that defines a set of methods for an aspect of a service.

Object-like interfaces are generally defined along lines of interoperability separating issues of data access from data management and searching. These interfaces may also implement any of the abstract behavioral interfaces listed above. The OSIDs do not adhere to a DAO/DTO model in its service definitions in that there are service methods defined on the objects (although they can be implemented using DTOs if desired). For the sake of an outline, we'll pretend they are data objects.

• OsidObject: Defines object data. OsidObjects are accessed from OsidSessions. OsidObjects are part of an interface hierarchy whose interfaces include the behavioral markers and a variety of common OsidObjects. All OsidObjects are Identifiable, Extensible , and have a Type. There are several variants of OsidObjects that indicate a more precise behavior.
• OsidObjectQuery: Defines a set of methods to query an OSID for its OsidObjects. An OsidQuery is accessed from an OsidSession.
• OsidObjectQueryInspector: Defines a set of methods to examine an OsidQuery.
• OsidObjectForm: Defines a set of methods to create and update data. OsidForms are accessed from OsidSessions.
• OsidObjectSearchOrder: Defines a set of methods to order search results. OsidSearchOrders are accessed from OsidSessions.

Most objects are or are derived from OsidObjects. Some object interfaces may not implement OsidObejct but instead derive directly from interface behavioral markers. Other OsidObjects may include interface behavioral markers to indicate functionality beyond a plain object. Several categories of OsidObjects have been defined to cluster behaviors to semantically distinguish their function in the OSIDs.

• OsidCatalog: At the basic level, a catalog represents a collection of other OsidObjects. The collection may be physical or virtual and may be federated to build larger OsidCatalogs using hierarchy services. OsidCatalogs may serve as a control point to filter or constrain the OsidObjects that may be visible or created. Each OsidCatalog may have its own provider identifty apart from the service provider.
• OsidRelationship: Relates two OsidObjects. The OsidRelationship represents the edge in a graph that may have its own relationship type and data. OsidRelationships are Temporal in that they have a time in which the relationship came into being and a time when the relationship ends.
• OsidRule: Defines an injection point for logic. An OsidRule may represent some constraint, evaluation, or execution. While authoring of OsidRules is outside the scope of the OSIDs, an OsidRule provides the mean to identify the rule and map it to certain OsidObjects to effect behavior of a service.

The most basic operations of an OSID center on retrieval, search, create & update, and notifications on changes to an OsidObject. The more advanced OSIDs model a system behavior where a variety of implicit relationships, constraints and rules come into play.

• OsidGovernator: Implies an activity or operation exists in the OSID Provider acting as an Operable point for a set of rules governing related OsidObjects. The OsidGovernator represents an engine of sorts in an OSID Provider and may have its own provider identity.
• OsidCompendium: OsidObjects which are reports or summaries based on transactional data managed elsewhere.

Managing data governing rules occurs in a separate set of interfaces from the effected OsidObjects (and often in a separate package). This allows for a normalized set of rules managing a small set of control points in a potentially large service.

• OsidEnabler: A managed control point to enable or disable the operation or effectiveness of another OsidObject. Enablers create a dynamic environment where behaviors and relationships can come and go based on rule evauations.
• OsidConstrainer: A managed control point to configure the constraints on the behavior of another OsidObject.
• OsidProcessor: A managed control point to configure the behavior of another OsidObject where some kins of processing is implied.

Other Abstract Interfaces

• OsidSearch: Defines set of methods to manage search options for performing searches.
• OsidSearchResults: Defines a set of methods to examine search results.

• OsidReceiver: Defines a set of methods invoked for asynchronous notification.
• OsidList: Defines a set of methods to sequentially access a set of objects.
• OsidNode: An interface used by hierarchy nodes.
• OsidCondition: An input or "statement of fact" into an OsidRule evaluation.
• OsidInput: An input of source data into an OsidRule processor.
• OsidResult: The output from processing an OsidRule.
• OsidRecord: An interface marker for an extension to another interface. OsidRecord are negotiated using OSID Types.

• Property: Maps a name to a value. Properties are available in OSID objects to provide a simplified view of data that may exist within a typed interface.
• PropertyList: A list of properties.

Runtime

• OsidRuntimeProfile: The OsidProfile for the runtime OsidManager.
• OsidRuntimeManager: The OSID Runtime service.

Abstract Flow

Generally, these definitions are abstract and not accesed directly. They are used as building blocks to define interfaces in the OSIDs themselves. OSIDs derive most of their definitions from a definition in the osid package. The methods that are defined at this abstract level versus the methods defined directly in a specific OSID is determined by the typing in the method signatures. The osid package interfaces are a means of ensuring consistency of common methods and not designed to facilitate object polymorphism among different OSIDs. A language binder may elect to alter the interface hierarchy presented in this specification and a provider need not parallel these interfaces in their implementations.

The flow of control through any OSID can be described in terms of these definitions. An OsidManager or OsidProxyManager is retrieved from the OsidRuntimeManager for a given service. Both types of managers share an interface for describing what they support in the OsidProfile.

Administrative-oriented sessions create and update OsidObjects using the OsidForm interface. The OsidForm makes available Metadata to help define its rules for setting and changing various data elements.

A notification session provides a means for subscribing to events, "a new object has been created", for example, and these events are received from an OsidReceiver.

Meta OSID Specification

The OSID Specification framework defines the interace and method structures as well as the language primitives and errors used throughout the OSIDs. The OSID Specifications are defined completely in terms of interfaces and the elements specified in the meta specification.

Language Primitives

Ths meta OSID Specification enumerates the allowable language primitives that can be used in OSID method signatures. Parameters and returns in OSID methods may be specified in terms of other OSID interfaces or using one of these primitives. An OSID Binder translates these language primitives into an appropriate language primitive counterpart.

An OSID Primitive differs from a language primitive. An OSID Primitive is an interface used to describe a more complex structure than a simple language primitive can support. Both OSID Primitives and language primitives have the same behavior in the OSIDs in that there is no service encapsulation present allowing OSID Primitives to be consructed by an OSID Consumer.

Errors

OSID methods are required to return a value, if specified, or return one of the errors specified in the method signature. The meta package defines the set of errors that a method signtaure may use.

Errors should result when the contract of the interface as been violated or cannot be fulfilled and it is necessary to disrupt the flow of control for a consumer. Different errors are specified where it is forseen that a consumer may wish to execute a different action without violating the encapsulation of internal provider operations. Such actions do not include debugging or other detailed information which is the responsibility of the provider to manage. As such, the number of errors defined across all the interfaces is kept to a minimum and the context of the error may vary from method to method in accordance with the spceification.

Errors are categorized to convey the audience to which the error pertains.

• User Errors: Errors which may be the result of a user operation intended for the user.
• Operational Errors: Errors which may be the result of a system or some other problem intended for the user.
• Consumer Contract Errors: Software errors resulting in the use of the OSIDs by an OSID Consumer intended for the application programmer. These also include integration problems where the OSID Consumer bypassed a method to test for support of a service or type.
• Provider Contract Errors: Software errors in the use of an OSID by an OSID Provider intended for an implementation programmer.

Compliance

OSID methods include a compliance statement indicating whether a method is required or optional to implement. An optional OSID method is one that defines an UNIMPLEMENTED error and there is a corresponding method to test for the existence of an implementation.

OSID 3K Acknowledgements

• Tom Coppeto (Editor & Architect)
• Scott Thorne (Architect)

The authors gratefully acknowledge the following individuals for their time, wisdom, and contributions in shaping these specifications.

• Adam Franco, Middlebury College
• Jeffrey Merriman, Massachusetts Institute of Technology
• Charles Shubert, Massachusetts Insitute of Technology

• Prof. Marc Alier, Universitat Politècnica de Catalyuna
• Joshua Aresty, Massachusetts Institute of Technology
• Fabrizio Cardinali, Giunti Labs
• Pablo Casado, Universitat Politècnica de Catalyuna
• Alex Chapin, Middlebury College
• Craig Counterman, Massachusetts Institute of Technology
• Francesc Santanach Delisau, Universitat Oberta de Catalyuna
• Prof. Llorenç Valverde Garcia, Universitat Oberta de Catalyuna
• Catherine Iannuzzo, Massachusetts Institute of Technology
• Jeffrey Kahn, Verbena Consulting
• Michael Korcynski, Tufts University
• Anoop Kumar, Tufts University
• Eva de Lera, Universitat Oberta de Catalyuna
• Roberto García Marrodán, Universitat Oberta de Catalyuna
• Andrew McKinney, Massachusetts Institute of Technology
• Scott Morris, Apple
• Mark Norton, Nolaria Consulting
• Mark O'Neill, Dartmouth College
• Prof. Charles Severance, University of Michigan
• Cole Shaw, Massachusetts Institute of Technology
• Stuart Sim, Sun Microsystems/Common Need
• Colin Smythe, IMS Global Learning Consortium
• George Ward, California State University
• Peter Wilkins, Massachusetts Institute of Technology
• Norman Wright, Massachusetts Institute of Technology

O.K.I. Acknowledgements

OSID 3K is based on the O.K.I. OSIDs developed as part of the MIT Open Knowledge Initiative (O.K.I) project 2001-2004.

• Vijay Kumar, O.K.I. Principal Investigator, Massachusetts Insitute of Technology
• Jeffrey Merriman, O.K.I. Project Director, Massachusetts Insitute of Technology
• Scott Thorne, O.K.I. Chief Architect, Massachusetts Institute of Technology
• Charles Shubert, O.K.I. Architect, Massachusetts Institute of Technology
• Lois Brooks, Project Coordinator, Stanford University
• Mark Brown, O.K.I. Project Manager, Massachusetts Institute of Technology
• Bill Fitzgerald, O.K.I. Finance Manager, Massachusetts Institute of Technology
• Judson Harward, Educational Systems Architect, Massachusetts Institute of Technology
• Charles Kerns, Educational Systems Architect, Stanford University
• Jeffrey Kahn, O.K.I. Partner, Verbena Consulting
• Judith Leonard, O.K.I. Project Administrator, Massachusetts Institute of Technology
• Phil Long, O.K.I. Outreach Coordinator, Massachusetts Institute of Technology

• Cambridge University, O.K.I. Core Collaborator
• Dartmouth College, O.K.I. Core Collaborator
• Massachusetts Institute of Technology, O.K.I. Core Collaborator
• North Carolina State University, O.K.I. Core Collaborator
• Stanford University, O.K.I. Core Collaborator
• University of Michigan, O.K.I. Core Collaborator
• University of Pennsylvania, O.K.I. Core Collaborator
• University of Wisconsin, Madison, O.K.I. Core Collaborator

We would also like to acknowledge and thank the work of the Kuali Student ServicesTeam.

• Andy Bucior, Florida State University
• Jonathan Cook, Indiana University
• Tom Coppeto, Kuali Foundation & Boston College
• Cathy Dew, 2Plus2 Partners, Inc.
• Matthew Edgren, University of Utah
• SW Genis, OpenCollab Pty Ltd
• Charles Lin, University of Maryland
• Mezba Mahtab, University of Toronto
• Carol McDonald, Iowa State University
• Kamal Muthuswamy, University of Washington
• Michael O'Cleirigh, University of Toronto
• Sambit Patnaik, University of Southern California & University of Toronto
• Michael Riley, Indiana University
• Reza Sarijlou, University of Utah
• Sridhar Komandur, University of Washington
• Norm Wright, MIT & University of Southern California & Boston College