Latest revision as of 13:43, 3 September 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 needs 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:

• common-gcore-stubs

interacts with the JAX-WS runtime in the Java platform to synthesise dynamic local JAX-WS proxies of remote gCore services.

• common-gcore-resources

contains an object-based implementation of the gCube Resource Model, i.e. a set of classes that represent known resource types.

• discovery-client

provides a generic API to formulate and submit queries for resource descriptions.

• ic-client

builds on the API of discovery-client to support resource discovery over the Information Collector service.

• registry-publisher

an API to publish resources with the Registry service.

Indirectly, the stack depends on:

• common-scope

provides base mechanisms for scope and scope map handling.

A Note on Logging

All the FWS components rely on SLF4J for logging, and include its API among their dependencies. To see these logs, however, the runtime environment must meet the following requirements:

• the classpath must include the SLF4J bridge that redirects logs towards the logging system used in the environment. For example, if the environment uses Log4j, the SLF4J bridge for Log4j - and only this bridge - must be included in the classpath;

• the logging system must be configured to show the output of loggers whose name starts with org.gcube.common.

The gHN runtime uses Log4j and already includes the required SLF4J bridge. Outside the gHN, clients are responsible for making the bridge available. For example to run a test from a Maven component, clients need to include this dependency:

<dependency>
  <groupId>org.slf4j</groupId>
  <artifactId>slf4j-log4j12</artifactId>
  <version>...</version>
   <scope>test</scope>
</dependency>