The Repository Admin service provides access to one or more repository files. This service ensures that a resource is included only once and handles any circular references between repositories. By defining a bundle repository service that provides access to bundles' metadata, you can facilitate remote bundle provisioning.
A client can access a federated set of repositories using the Repository Admin service, as shown in Figure 3.2:
Typically, OBR service clients only have to interact with the Repository Admin service, which provides the mechanisms necessary to discover available resources. The Repository Admin interface is defined as follows:
public interface RepositoryAdmin { public Resource[] discoverResources(String filterExpr); public Resolver resolver(); public Repository addRepository(URL repository)? throws Exception; public boolean removeRepository(URL repository); public Repository[] listRepositories(); public Resource getResource(String respositoryId); }
A resolver object takes a set of bundles that should be added to a system as input. The resolver calculates the set of required bundles and tracks optional bundles.
To resolve and deploy available resources, the Repository Admin service provides
resolver
instances that are defined as follows:
public interface Resolver { public void add(Resource resource); public Requirement[] getUnsatisfiedRequirements(); public Resource[] getOptionalResources(); public Requirement[] getReason(Resource resource); public Resource[] getResources(Requirement requirement); public Resource[] getRequiredResources(); public Resource[] getAddedResources(); public boolean resolve(); public void deploy(boolean start); }
When desired resources are discovered via the query mechanisms of the Repository
Admin service, they are added to a resolver
instance, which can be
used to resolve all transitive dependencies and to reflect on any resolution
result.
The following code snippet depicts a typical usage scenario:
RepositoryAdmin repoAdmin = ... // Get repo admin serviceResolver resolver = repoAdmin.resolver();
Resource resource = repoAdmin.discoverResources(filterStr);
resolver.add(resource); if (resolver.resolve())
{ resolver.deploy(true); } else { Requirement[] reqs = resolver.getUnsatisfiedRequirements(); for (int i = 0; i < reqs.length; i++) { System.out.println("Unable to resolve: " + reqs[i]); } }
This code:
Gets the Repository Admin service. | |
Gets a | |
Discovers an available resource and adds it to the
| |
Attempts to resolve the resource's dependencies. If:
|
The OBR deployment algorithm is complex because of the nature of deploying independently developed bundles. For example, if an update for a bundle is made available, the updates for all of the bundles satisfying its dependencies might not be made available. In this case, the deployment algorithm might have to install new bundles during an update to satisfy either new dependencies or updated dependencies that can no longer be satisfied by existing local bundles. In this scenario, the OBR deployment algorithm favors updating existing bundles, if possible, instead of installing new bundles to satisfy dependencies.
If you use a proxy for web access, OBR will not work in its default configuration. You must set the following system properties to enable OBR to work with a proxy:
http.proxyHost
— Name of the proxy host.
http.proxyPort
— Port of the proxy host.
http.proxyAuth
— User name and password to use when
connecting to the proxy. This string should be the user name and password
separated by a colon, for example, myname:mypassword
.
You can set these system properties directly on the command line when starting
the JVM using the standard
-D<prop>=<value>
syntax or put them in
the \fuse-esb-4.x\etc\system.properties
file in your FUSE ESB
installation. See Managing the Container for more
information on configuration.