...
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.
| Gliffy | ||||
|---|---|---|---|---|
|
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.
See Also
osid.OsidRuntimeManagerAnchor osid.OsidRuntimeManager osid.OsidRuntimeManager
osid.OSIDAnchor osid.OSID osid.OSID