Motivations

Experience tells us that, as far as complex programming activities are concerned, Web Service development must rank pretty high.

First, service programming is a high-level form of distributed programming and as such reflects the challenges and opportunities of the network, an inter-network in this case. It is multiprogramming, often in the presence of shared state. It is performance-aware programming against the latencies and bandwidth fluctuations of the internet-work. It is programming for resilience to the wide range of partial failures that may be observed across the network. Move from 'Hello World' to production-level requirements, and it is time for reckoning.

Then we look at the enabling technologies, and find that the noble goal of promoting loose coupling leaves developers with an ever growing number of dis-integrated technologies and multi-generation standards for building, deploying, hosting, configuring, describing, validating, querying, publishing, etc. Coordination between them comes late, at linking time in the best case, and right at the point of usage in the worst case. They are averagely poorly documented - both inside and outside the source - and are often inconsistently implemented.

And when it comes to developing gCube services, there could be way more unpleasantness to suffer. The infrastructure promises to manage services but can only deliver if services make themselves manageable. A gCube service needs to comply with a host of infrastructural requirements on how the service builds, is profiled, manages its own lifetime, models, publishes, and persists its own state, handles scope and security, retrieves information about other resources in the infrastructure and reacts to key events that occur in it. And there is more as you can see from our overview.

There could be even more unpleasantness to suffer, and there is some indeed. The good news is that there is much, much less than there could have been. The reason is that gCube developers can rely on the gCF to abstract away most of the requirements raised by the infrastructure. This is the first and foremost rationale for gCF: to deliver transparencies for compliance with infrastructural requirements, to all gCube services and at little or no cost. As a bonus, the future evolution of gCube requirements will be deployed with new versions of gCF and remain hidden to its users.

In this spirit of simplification, there is in fact more that could be done. gCF includes (and in fact makes use of) tools that have little to do with gCube requirements but are likely to help increase the quality of service implementations: abstractions for event-based programming and dynamic proxying, for sequencing, parallelisation and scheduling of local processes, for the application of best-effort strategies to interact with other services. A second goal for gCF is thus to promote the adoption of best practices in distributed programming.

Finally, we set out to document these facilities properly. This document is our main account of the framework and pairs up with the Primer and the in-source documentation [1] to describe design concepts, illustrate functionality, and exemplify usage.