The Management Agent...

[Marcel Offermans <ma...@luminis.nl>]

Within ACE, we have a management agent that is very flexible and modular, which is nice because it allows you to customize it any way you want. The ace-target-devgateway project supplies such a modular agent and can be used during development.

On the other hand, once you've composed a management agent out of different bundles, it is more convenient to have it packaged in a single, self-contained bundle. That is exactly what the ace-managementagent project supplies.

Finally, we can go even further and provide a Java executable that contains both an OSGi framework and embedded management agent. This is the ace-launcher project.

With this management agent, we have created an OSGi framework that can be updated dynamically. The management agent itself, although present, should probably be hidden from the other bundles that are installed (so they do not interfere with them). Within our launcher and the single bundle, we could simply not export anything that is contained within. At first, that sounds like a tempting solution, but it also means it becomes impossible to communicate with this agent, which has two important drawbacks:

1) There are a few configurable aspects in the management agent that use Configuration Admin so they can be dynamically reconfigured at runtime. If you cannot access this service, you cannot (re)configure anything.

2) The Deployment Admin specification, which can be extended by using resource processors, won't be able to actually use those resource processors since they need to be able to interact with Deployment Admin.

Especially the second drawback is not acceptable (we could find a way around the first, possibly by using getAllServiceReferences() and some reflection).

On the other hand, we don't want to expose all these packages and services to everybody.

The proposed solution, which was previously discussed on the Amdatu website (an open source project that uses Apache ACE and ran into these same issues) and summarized on there [1].

The solution involves using mandatory attributes on the imports and exports that are part of the management agent to create a "name space" for every bundle that is part of it. These attributes prevent other bundles from seeing these packages and getting wired to them accidentally. Resource processors can use these attributes to explicitly bind to the right packages.

I propose to start using these attributes in ACE. Because we use the Auto Configuration resource processor from Felix, we probably need to repackage it so it supports these attributes. I would like your feedback on this. Especially, can you think of an even better solution?

Greetings, Marcel

[1] http://www.amdatu.org/confluence/display/Amdatu/AMA+issues+in+combination+with+resource+processors

Re: The Management Agent...

[Carsten Ziegeler <cz...@apache.org>]

Hi,

I don't have that much experience in this area, but on a first look
the suggested solution looks good to me. We can give it a spin and see
how it turns out.

Carsten

2012/3/20 Marcel Offermans <ma...@luminis.nl>:
> Within ACE, we have a management agent that is very flexible and modular, which is nice because it allows you to customize it any way you want. The ace-target-devgateway project supplies such a modular agent and can be used during development.
>
> On the other hand, once you've composed a management agent out of different bundles, it is more convenient to have it packaged in a single, self-contained bundle. That is exactly what the ace-managementagent project supplies.
>
> Finally, we can go even further and provide a Java executable that contains both an OSGi framework and embedded management agent. This is the ace-launcher project.
>
> With this management agent, we have created an OSGi framework that can be updated dynamically. The management agent itself, although present, should probably be hidden from the other bundles that are installed (so they do not interfere with them). Within our launcher and the single bundle, we could simply not export anything that is contained within. At first, that sounds like a tempting solution, but it also means it becomes impossible to communicate with this agent, which has two important drawbacks:
>
> 1) There are a few configurable aspects in the management agent that use Configuration Admin so they can be dynamically reconfigured at runtime. If you cannot access this service, you cannot (re)configure anything.
>
> 2) The Deployment Admin specification, which can be extended by using resource processors, won't be able to actually use those resource processors since they need to be able to interact with Deployment Admin.
>
> Especially the second drawback is not acceptable (we could find a way around the first, possibly by using getAllServiceReferences() and some reflection).
>
> On the other hand, we don't want to expose all these packages and services to everybody.
>
> The proposed solution, which was previously discussed on the Amdatu website (an open source project that uses Apache ACE and ran into these same issues) and summarized on there [1].
>
> The solution involves using mandatory attributes on the imports and exports that are part of the management agent to create a "name space" for every bundle that is part of it. These attributes prevent other bundles from seeing these packages and getting wired to them accidentally. Resource processors can use these attributes to explicitly bind to the right packages.
>
> I propose to start using these attributes in ACE. Because we use the Auto Configuration resource processor from Felix, we probably need to repackage it so it supports these attributes. I would like your feedback on this. Especially, can you think of an even better solution?
>
> Greetings, Marcel
>
> [1] http://www.amdatu.org/confluence/display/Amdatu/AMA+issues+in+combination+with+resource+processors



-- 
Carsten Ziegeler
cziegeler@apache.org