Featherweight Stack

From Gcube Wiki
Revision as of 13:08, 23 November 2012 by Fabio.simeoni (Talk | contribs) (Created page with ' The '''FeatherWeight Stack''' is the collective name of a set of gCube components that enable interaction with gCube services from within client runtimes. The featherweight natu…')

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

The FeatherWeight Stack is the collective name of a set of gCube components that enable interaction with gCube services from within client runtimes. The featherweight nature of the stack is in the footprint of the 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 for the client stack traditionally available within the system. The 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 has a number of properties:

  • it 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. This is a major drawback of using the gCore stack for clients, as it is cumbersome 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.
  • 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 accordingly very early versions with


Components