Transit provides a flexible framework for dynamically retrieving system and application resources, constructing classloaders and management of plugins via an abstract resource identifier referred to as an artifact. As a resource management system Transit provides the foundation for building repository-enabled applications.
One of the more difficult tasks when building Java applications is classloader management. Often, when combining various projects together into an enterprise application, the application is not able to load the right classes at the right time, causing the application to fail in mysterious and sometimes subtle ways. Although a fundamental issue, classloading has remained a rather obscure topic. When combined with component-based development the classloader management concern can become a major configuration management concern. Transit provides a solution to this problem.
At the core of Transit is a URL protocol handler and a framework for custom content handlers. Content handlers provided by DPML include a deployment system that encapsulates a classloader defintion and deployment strategy, together with a handler supporting the establishment of a Java runtime process. Based on these, Transit is able to manage classloaders, not only effectively and nearly invisible to the casual user, but in a location independent way. That means, applications don't need to be concerned over where the jars and other resources are located, whether on the local file system, on LAN servers or somewhere on the Internet. This allows an application to provide extendability, hot-redeployment and more advanced services.
Each artifact has a unique identifier conforming to the Transit artifact protocol specification. Using a standard extension to the java.net.URL class in the Java API, Transit accesses an artifact through an artifact URI. The artifact URI logically identifies a resource and the Transit system provides the means for resource retrieval.
The artifact URI describes the:
- type of resource (JAR, meta, template...)
- group to which the artifact belongs
- name of the artifact
- version
The purpose of the group is to avoid naming conflicts in the artifact name space. The top level group should be a distinguishable and well accepted name of the organization, and any sub groups to be decided by the organization itself to further avoid name clashes. It is recommended that the bottom level group is the release level, i.e. all resources within the 'release' shares the same version and are meant to be working in a group within that version, and not mixed between versions.
Transit promotes strong version management. The underlying concern is that many parts of the system are dependent on particular versions of another part or resource, and can not be freely mixed. To ensure that all dependencies are resolved against the proper versions, it is paramount that a version management system is in place, and policies are established. From Transit's point of view, the version is an opaque identifier without any in-built semantic meaning.
These identifiers disassociate the definition of an application from the source of the resources needed to build and deploy the application. Meaning, it is only in the interest of the user of the resources, be it built tools or running applications, that the correct resources are provided, and not from which server these were downloaded. The task of resolving the location is transferred from each application to Transit itself, which is configured to know about which servers are available in its running environment.