OSID Providers are accessed through the OSID Runtime.
OSID Providers are accessed through the OSID Runtime.
org.osid.repository.RepositoryManager repositoryManager = (org.osid.repository.RepositoryManager) getManager(org.osid.REPOSITORY,
"net.tom.impl.FunRepositoryManager",
net.okapia.osid.kilimanjaro.Versions.LATEST.getVersion());
org.osid.tracking.TrackingProxyManager trackingManager = (org.osid.tacking.TrackingProxyManager) getManager(org.osid.TRACKING,
"net.tom.impl.TrackingProxyManager",
net.okapia.osid.kilimanjaro.Versions.LATEST.getVersion()); |
However, the puppet strings between the OSID Consumer and OSID Provider increase as more OSID Providers are named and requested through the OSID Runtime. The Orchestration OSID is a useful tool to minimize this touch point in OSID Consumers.
org.osid.orchestration.OrchestrationManager orchestration = (org.osid.orchestration.OrchestrationManager) getManager(org.osid.Orchestration,
"net.tom.impl.MyOrchestrationManager",
net.okapia.osid.kilimanjaro.Versions.LATEST.getVersion());
org.osid.repository.RepositoryManager repositoryManager = orchestration.getRepositoryManager();
org.osid.tracking.TrackingProxyManager trackingManager = orchestration.getTrackingProxyManager(); |
The Orchestration OSID provides a single touchpoint to access OSID Providers encapsulating a number of issues such as identity of the other OSID Providers and the reusability of an OSID Provider instance. Even if every application had it's own customized Orchestration OSID Provider, this extra insulation is worth it whenever there is more than one OSID in play. OSIDs should have only permitted Orchestration OSID Providers to be instantiated through its runtime. This is the useful consumer-facing service bus and moves the configuration of other OSID Providers out of the OSID Consumers.
The OsidRuntimeManager passed to an OsidManager's initialize() method should be used to instantiate other OSID Providers.
public class MyCalendarManager
implements org.osid.calendaring.CalendaringManager {
private org.osid.logging.LoggingManager logger;
@OSID @Override
public void initialize(org.osid.OsidRuntimeManager runtime)
throws org.osid.ConfigurationErrorException,
org.osid.OperationFailedException {
try {
this.logger = (org.osid.logging.LoggingManager) runtime.getOsidManager(OSID.LOGGING, "my.calendar.impl",
net.okapia.osid.kilimanjaro.Versions.LATEST.getVersion());
} catch (org.osid.NotFoundException nfe) {
throw new org.osid.ConfigurationErrorException("calendaring impl not found", nfe);
}
return;
}
....
} |
The Jamocha AbstractOsidManager simplifies this a bit using it's own OSID Version and wrapping NotFoundExceptions. However, there's nothing wrong with rolling your own to deal with specific compatibility issues.
public class MyCalendarManager
extends net.okapia.osid.jamocha.calendaring.spi.AbstractCalendaringManager
implements org.osid.calendaring.CalendaringManager {
private org.osid.logging.LoggingManager logger;
@OSID @Override
public void initialize(org.osid.OsidRuntimeManager runtime)
throws org.osid.ConfigurationErrorException,
org.osid.OperationFailedException {
super.initialize(runtime);
this.logger = (org.osid.logging.LoggingManager) getOsidManager(OSID.LOGGING, "my.calendar.impl");
return;
}
....
} |
Use the OsidRuntimeManager passed through the OsidManager's initialize() method. Kilimanjaro is essentially a souped up ClassLoader. However, there might be special circumstances where loading OSID Providers through other OSID Runtime Providers is warranted.
In both these cases, you probably want to preserve the "chain" by falling back to the current OSID Runtime.