LibraryLink ToToggle FramesPrintFeedback

Repository Admin Service

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 service 1
Resolver resolver = repoAdmin.resolver(); 2
Resource resource = repoAdmin.discoverResources(filterStr);3
resolver.add(resource);
if (resolver.resolve()) 4
{
    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:

1

Gets the Repository Admin service.

2

Gets a resolver instance from it.

3

Discovers an available resource and adds it to the resolver.

4

Attempts to resolve the resource's dependencies.

If:

  • Successful, it deploys the resource to the local framework instance.

  • Unsuccessful, it prints the unsatisfied requirements

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:

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.