Difference between revisions of "WP8-Tecnology Evolution Strategy"

Revision as of 14:11, 2 February 2012

A key goal in the design of the system is to broaden the class of managed resources, in particular the management functions that can be offered over independent resources. This is essentially a requirement for transparent resource management. In its ideal form, the requirement is for zerodependency management, though this in practice may be attained only for a small subset of management functions and, for some resources, it may not be attained at all. When zero-dependency management is unattainable for all or some management functions, we pursue transparency with solutions that minimise required dependencies.

In all cases, transparent management requires lightweight integration mechanisms with existing technologies. We consider requirements for service configuration (hence re-packaging) to fall within our zero-dependency management goal. For clients, configuration requirements may not arise at all. We prioritise integration with Java technologies and, within those, with formal and de-facto standards. We fall back to ad-hoc integration whenever standards are not available. Within standards, we prioritise those that, in theory or in practice, assume the HTTP protocol, leaving integration based on other protocols as a future goal.

Services

For services, we prioritise integration with resources deployed in Servlet containers, from interactive Web Applications to Web Services. In particular, we focus on plain HTTP services (REST services) and SOAP services (WS services). For Rest services, we prioritise integration with JAX-RS, but also consider Restlet and ReastEasy as de-facto standards. For WS services, we prioritise integration with JAX-WS. In all cases, we seek uniform integration solutions based on the listeners and filters defined by the Servlet specification, taking particularly advantage of the annotationbased configuration introduced in version 3.0.

Clients

For clients, the only Java standard at the time of writing is the API java.net, which is a low-level client API. Future versions of JAX-RS are expected to standardise a high-level client APIs. Apache’s HTTPClient is another low-level APIs that serves as a de-facto standard. Recently, the high-level client APIs offered by Jersey (JAX-RS’s RI), Restlet, and RestEasy are increasingly popular as configurable abstractions over java.net and/or Apache’s HttpClient APIs. Here, our integration strategy relies mainly on an embedded HTTP proxy server bootstrapped by an instrumentation agent of the JVM.