Refactor (HTTP monitoring) proxy to decouple architecture

[mdutoo]

• As much as possible, remove static / singleton and let it be instantiated by FraSCAti instead
• separate MonitoringService in 2 impls for each mode, having the same interface
• study architecture for a unified proxy stack ("Light", fuse, monitoring) assembled and instantiated in a single composite, ex. by wrapping Fuse intent in a Message API and composing it with Monitoring proxy using a ComposedProxyImpl also implementing the Message interface
• and / or write tests showing how to conf the archi by SCA to embed a client (ex. Light proxy), HTTP monitoring and server (ex. mock) using SCA binding & tunneling (possibly addressing ?) rather than HTTP proxying
• write a wiki page about this architecture, Jasmine's probe architecture and how they could match or complete each other

[JGuillemotte]

1. & 2. OK, studying 3.

[mdutoo]

Also refactor & decouple to support discovery process, see #31 https://github.com/easysoa/easysoa-model-demo/issues/31 .

About 4. : that would need a client (reference) binding.http in FraSCAti, which only supports it as a server (service) for now.

About 3. Message API signature : For now it's basically MonitoringService.listen(Message). To support all proxy use cases, "listen" should become something like the following methods : preForward (ex. SLA), postForward (ex. async), preReturn (ex. translate), postReturn (ex. record log including return OK), and also handle errors and aborts (ex. SLA).

About 3. Object-oriented Message API : That's another version of the Message API. SCA Intents are an example of it. It corresponds to a java interface (in the SCA sense) rather than a ws one. So could there be a message / text oriented version of SCA Intents, maybe using the Servlet interface (consistent with previous comment) ?