Difference between revisions of "Featherweight Stack"
(→Components) |
(→Components) |
||
| Line 60: | Line 60: | ||
* [[common-scope|'''common-scope-maps''']] | * [[common-scope|'''common-scope-maps''']] | ||
:per-scope configuration required to bootstrap discovery mechanisms. | :per-scope configuration required to bootstrap discovery mechanisms. | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
Revision as of 12:02, 15 January 2013
The FeatherWeight Stack is the collective name for a set of gCube components that enable interaction with gCube services. The featherweight nature of the stack is in the footprint of its components, which is very small in terms of code, dependencies, and overall usage requirements.
Motivations
The Featherweight Stack originates as a reaction to and a replacement of the client stack traditionally associated within the system. This legacy stack does not differentiate between services and clients, i.e. includes the same components which are required to develop and run the dominant class of gCube services. Since these services are based on the gCore runtime, clients and services share the same gCore stack.
The gCore Stack
As a client stack, gCore raises a number of problems:
- it cannot be embedded
- the stack assumes a physical installation on the file system, and the configuration of that installation (configuration files, environment variables, etc). This requirements is naturally addressed service-side, where the stack is installed along with the gCore service container. Client-side, however, this container need not be available in principle, as clients need not be gCube services, and when they are, they need not to be gCore services (i.e. may be running in a different container). In practice, the requirement is to manually download and install the gCore container client-side, even without starting it. Furthermore, the stack cannot be declaratively resolved at build time with modern dependency management systems, such as Maven, which are commonly adopted by target clients. Rather, clients are responsible for manually placing the required libraries on the classpath. Other benefits of using modern build technologies are denied in turn. Overall, the stack is cumbersome to adopt and complicates dynamic deployment of clients, which is a strong requirements when clients are hosted in the system or belong to it in their own right.
- it is large
- the stack counts about 140 dependencies, yet only a fraction of those are truly required for client-side interactions with gCube services. Together with other parts of the required installation, the dependencies contribute to a stack size of about 32 MB.
- it is ageing
- most components of the stack originate from legacy technologies, such as Axis 1.0 or Globus 4. Their 3rd party dependencies are often earlier releases of versions that are currently available, often within the Java platform itself (e.g. concurrency support, XML parsing) with which they can easily clash in the client runtime. The risk of version clashes increases further with libraries that are typically found in service-side environments (e.g. JNDI support).
Overall, gCore is poorly suited as a client stack and reduces the rate and the extent to which gCube can be exploited by external clients. Since gCube clients are often gCube services in turn, it also discourages developing new services against technologies and on platforms other than gCore itself. In this sense, the gCore stack threatens the uptake as well as the evolution of the system.
ghn-client-runtime
A recent attempt to address these issues has produced ghn-client-runtime, a single library that:
- minimises the size of the required installation to a few Kbs.
- embeds the minimal installation, performing it and configuring it dynamically.
- resolves dependencies from Maven repositories.
ghn-client-runtime eliminates some of the most visible drawbacks of the gCore stack, as outlined above. From the client perspective, standard expectations of resolving declaratively dependencies to the stack are restored.
However, ghn-client-runtime does not fully address issues of size (14MB), old dependency versions, and high clash factor. Even though it is reduced, embedded, and declaratively resolvable, the stack introduced by the ghn-client-runtime is qualitatively no different from the full gCore stack.
The Featherweight Stack solves the outstanding issues from the ground up, including only components that are outside the gCore stack and have zero dependencies on it. It achieves this by abandoning entirely the technologies upon which gCore is based, replacing them with modern technologies often embedded in the Java platform itself.
Components
The Featherweight Stack includes the following components:
- interacts with the JAX-WS runtime in the Java platform to synthesise dynamic local JAX-WS proxies of remote gCore services.
- contains an object-based implementation of the gCube Resource Model, i.e. a set of classes that represent known resource types.
- provides a generic API to formulate and submit queries for resource descriptions.
- builds on the API of
discovery-clientto support resource discovery over the Information Collector service.
- an API to publish resources with the Registry service.
Indirectly, the stack depends on the following gCube components:
- provides base mechanisms for scope and scope map handling.
- per-scope configuration required to bootstrap discovery mechanisms.
