Getting OSID Providers
- Tom Coppeto
Summary
OSID Providers are accessed through the OSID Runtime.
Getting OSID Providers
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.
From Within OSID Providers
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;
}
....
}
Breaking the Chain
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.
- accessing an implementation of OSID Runtime to access OSID Providers and their configurations remotely
- accessing an implementation of OSID Runtime that changes the search path and/or configuration location
In both these cases, you probably want to preserve the "chain" by falling back to the current OSID Runtime.