OSID Flow
- Tom Coppeto
Summary
Instantiating an OSID Provider
OSID Providers are instantiated through the runtime using the osid.OsidRuntimeManager interface. You can think of the OsidRuntime as a service bus from which OSID Providers can be accessed. The three pieces of information getManager() requires are:
- OSID: this is an enumerated list of OSID Packages defined in osid.OSID
- implementation name: the name of the OSID Provider implementation (in Java, this is the class name of the OsidManager)
- version: the OSID Specification version required by the OSID Consumer (not the implementation version)
If successful, the OsidManager for the requested OSID will be returned. The OsidManager represents the principal service endpoint into the OSID Provider.
OsidManagers & OsidSessions
OSIDs are sliced into small clusters of functionality. These slices appear as sub-interfaces (not to be confused with sub packages) called OsidSessions. OsidSessions do the heavy lifting and are accessed through OsidManagers.
Accessing OsidManagers in Sub Packages
Sub Packages have their own service access through an OsidManager. The OsidManager of the sub package is accessed by way of the OsidManager in the parent package.
Terminology
osid.OsidManager and osid.OsidSession are defined as interfaces in the root osid package. Every OSID defines its own managers and sessions that implement these interfaces. For example, the Repository OSID defines osid.RepositoryManager and osid.RepositoryLookupSession for retrieving Repositories. The abstract framework is used when talking about how the framework is designed.
Casting, really?
The OSIDs are a heavily typed specification that tries to avoid casting of interfaces whenever possible. osid.OsidRuntimeManager.getManager() returns an osid.OsidManager that needs to be cast into the appropriate interface based on the value of osid.OSID given to it. Typically, this kind of method would not be allowed in the specification which would favor having a separate method for each type of manager returned.
This is somewhat historical. Also, in any non-trivial use of the OSIDs, we'll see later that there is generally only one OSID accessed through the runtime. We'll also see another exception to the no casting rule.
Where Does The OsidRuntime Come From?
The specification doesn't say. osid.OsidRuntimeManager is an interface to instantiate other OSID Providers, but the specification does not include a means for instantiating the provider of the runtime itself. That would be circular.
Where the runtime comes from is an issue of the runtime environment itself. Later, the Okapia OSID Runtime implementation will be explored in more detail and how it solves this problem.