Surety is performing system maintenance this weekend. Electronic date stamps on new Prior Art Database disclosures may be delayed.
Browse Prior Art Database

Dynamic dependency resolving based on contracts

IP.com Disclosure Number: IPCOM000238681D
Publication Date: 2014-Sep-11
Document File: 3 page(s) / 55K

Publishing Venue

The IP.com Prior Art Database


Typically, applications define dependencies to various external artifacts using static references. This approach has issues that can be addressed by dynamic dependency resolving based on contracts described in the article.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 01 of 3

Dynamic dependency resolving based on contracts

Typically, applications define dependencies to various external artifacts using static references, i.e. by specifying acceptable version ranges. At execution time, the container has to resolve required dependencies in order to initialize the application environment. Considering the straightforward version based dependency resolver, we find two basic issues:

1. If no applicable artifact version can be found for a given dependency, the application is not initialized, although there might exist an artifact which provides the expected functionality.

2. If multiple artifacts match the given range, only one (usually with the highest version) is chosen. Since this artifact does not have to be the best match in context of the expected application usage, the choice may not be optimal.

Glossary: · Container - an execution environment responsible for resolving and initializing application dependencies, e.g. the OSGI container, web containers, cloud services, etc.

· Artifact - a service implementation which may be referenced and used by an application, e.g. web services, database drivers, OSGI bundles, application libraries, etc.

We propose a new dependency description method using a contract pattern. Instead of defining an artifact dependency using acceptable version ranges, we provide a contract,
i.e. a subset of functionality we expect from the given artifact. This way, dependencies are not resolved using static artifact data, e.g. version ranges, but using actual functionality consumed by the application. Specific contract...