Re: [osgi-dev] Understanding OSGi Initial Provisioning and Deployment Admin

[Seth Lana]

Hi Peter,

many thanks for your inputs, it really helped us to defined the way our 
team should to go.


We had some difficulties defining the requirements of this pilot project 
due to, as you said, the large number of possibilities and combinations 
that we could have. But we are getting there...


One last doubt, we have found no reference about bundle start level on 
both Initial Provisioning and Deployment Admin specs.


In case of IP, we thought about two possibilities. One is to use IP 
archive's manifest file to hold the information and let the IP 
implementation bundle to use it after it install the bundle. for example:


   InitialProvisioning-Entries:
   org.apache.felix.scr;type=bundle;*startLevel=2*

Another one is to add a text entry on the IP zip. as that will be stored 
in the provisioning dictionary then the management agent can obtain that 
information using the provisioning service and use it to set the 
startLevel.


We are inclined for the option one. which would be the best approach for 
you?


best regards,

Seth

On 10-12-2015 11:48, Peter Kriens wrote:

On 9 dec. 2015, at 00:46, Seth Lana  wrote:
Hello,
I’m researching about the best ways to provide automatic remote provisioning 
for small devices and also for the servers that will provide content for such 
devices. Reading the OSGi compendium, some specs caught my attention: Initial 
Provisioning, Deployment Admin, Subsystems and Repository Services.

If I got it right, we can have a device with only the OSGi container(with a 
minimal deps) and the IP Agent bundle jars assembled at factory.

Yes. The core idea is that you deliver identical devices to all your customers 
except for the identity (serial number or so).


At first use, the IP agent will contact the remote provisioning service (using 
Http or another protocol) and will download one or more IP zip files containing 
one or more bundles and configuration files defined by the remote provisioning 
operator for that device. All bundles inside the IP zips will be installed by 
the IP agent. So, this process follows until all necessary bundles are 
installed, ending with the Management Agent bundle being started. Am I right?

Yup.


What I found strange was the fact that only one bundle can be started at each 
time (each zip can have only one start entry pointing to only one bundle). Why 
this restriction?

This allows this single bundle to verify the environment, do some checks, and setup 
security &  start levels for example.


Should the Management Agent uninstall the IP agent after it is fully 
operational? or the IP must run every time the device starts up ?

There is no obligation here. Personally, I would make sure that in certain 
situations the device can go back to initial mode so that the operator can 
regain control of the device after a catastrophic event. But again, there are 
not rules defined here.


But the biggest doubt is about that Management Agent itself. It seems that one 
needs to be developed, right?.

Yes. Something needs to provide YOUR policy, this is the management agent. You 
could buy one (this was ProSyst’s answer), there is open source (this was 
Marcel’s answer, or there is building it yourself. I prefer the latter because 
it allows you to provide your policy to the management operations. It is not a 
big deal because the management operations are part of the well defined OSGi 
API and are almost trivial to use.


Should the Management Agent to use a Deployment Admin service provided by 
another bundle or should it be itself the provider of such service?

There are no restrictions here. Make sure the Management Agent only provides 
policy so if you insist on using Deployment Admin then it is not a good idea to 
implement it yourself.


And about the Repository Service, should it be used by the Management Agent or 
Deployment Admin or both?

I think you are focusing too much on all potential possibilities. What are your 
requirements? OSGi is a bit like a box of Lego. Once you have a clear vision of 
how you want to manage your devices you find the components in OSGi. However, 
you can combine these components in infinite ways and exploring all 
combinations is not providing you with the right solution any time soon.


Can a Subsystem (.esa) be package inside a Deployment Package?

You can write your own Resource Processor with Deployment Admin so in principle 
yes. However, both Deployment Admin and subsystems struggle with sharing 
bundles. Deployment Admin took the easy way out and decided to not share 
bundles. Subsystems do allow sharing but struggles because of the complexity 
this creates.


Can the Deployment Packages (*.dp) or Subsystems (*.esa) also be provided by an 
OSGi repository ?

Again yes. You will need to write a Resource Processor and then you can install 
anything anywhere with Deployment Admin.

You might get more useful advice from this group if you provide us with the 
actual use case.

Kind 

[osgi-dev] How to correctly use bean validation in OSGi

[Christian Schneider]

There is currently a pull request in CXF to integrate with Hibernate 
Validator to provide bean validation support in OSGi.

See https://github.com/apache/cxf/pull/102

I am pretty sure the approach with a ValidationHelper class is not 
really ideal. The question is though what would be a good way?


I can imagine that either a ValidationFactory or ValidationProvider 
could be registered as a service by hibernate or by some karaf or aries 
provided adapter.


Does anyone have experience with using javax.validation in OSGi. Is 
there maybe even some work on a spec around this already or some best 
practices?


Christian

--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Understanding OSGi Initial Provisioning and Deployment Admin

[Peter Kriens]

NO startlevels is best … :-)

If you really need start levels (and after thinking again) then you can your 
set start levels by your management agent. One more reason why only one bundle 
is started.

Though start levels can be helpful to make it look like the systems boots 
faster, it is too often used to mask bad bundles that are not properly handling 
their dependencies. Those bundles will give you pain in the future so it is 
better to fix them from the start. And then they do not need start levels.

Kind regards,

Peter Kriens




> On 14 dec. 2015, at 17:02, Seth Lana  wrote:
> 
> Hi Peter,
> 
> many thanks for your inputs, it really helped us to defined the way our team 
> should to go.
> 
> We had some difficulties defining the requirements of this pilot project due 
> to, as you said, the large number of possibilities and combinations that we 
> could have. But we are getting there...
> 
> One last doubt, we have found no reference about bundle start level on both 
> Initial Provisioning and Deployment Admin specs. 
> 
> In case of IP, we thought about two possibilities. One is to use IP archive's 
> manifest file to hold the information and let the IP implementation bundle to 
> use it after it install the bundle. for example:
> InitialProvisioning-Entries: org.apache.felix.scr;type=bundle;startLevel=2 
> Another one is to add a text entry on the IP zip. as that will be stored in 
> the provisioning dictionary then the management agent can obtain that 
> information using the provisioning service and use it to set the startLevel. 
> 
> We are inclined for the option one. which would be the best approach for you?
> 
> best regards,
> 
> Seth
> 
> On 10-12-2015 11:48, Peter Kriens wrote:
>>> On 9 dec. 2015, at 00:46, Seth Lana  
>>>  wrote:
>>> Hello,
>>> I’m researching about the best ways to provide automatic remote 
>>> provisioning for small devices and also for the servers that will provide 
>>> content for such devices. Reading the OSGi compendium, some specs caught my 
>>> attention: Initial Provisioning, Deployment Admin, Subsystems and 
>>> Repository Services.
>>> 
>>> If I got it right, we can have a device with only the OSGi container(with a 
>>> minimal deps) and the IP Agent bundle jars assembled at factory.
>> Yes. The core idea is that you deliver identical devices to all your 
>> customers except for the identity (serial number or so).
>> 
>>> At first use, the IP agent will contact the remote provisioning service 
>>> (using Http or another protocol) and will download one or more IP zip files 
>>> containing one or more bundles and configuration files defined by the 
>>> remote provisioning operator for that device. All bundles inside the IP 
>>> zips will be installed by the IP agent. So, this process follows until all 
>>> necessary bundles are installed, ending with the Management Agent bundle 
>>> being started. Am I right?
>> Yup.
>> 
>>> What I found strange was the fact that only one bundle can be started at 
>>> each time (each zip can have only one start entry pointing to only one 
>>> bundle). Why this restriction?
>> This allows this single bundle to verify the environment, do some checks, 
>> and setup security &  start levels for example.
>> 
>>> Should the Management Agent uninstall the IP agent after it is fully 
>>> operational? or the IP must run every time the device starts up ?
>> There is no obligation here. Personally, I would make sure that in certain 
>> situations the device can go back to initial mode so that the operator can 
>> regain control of the device after a catastrophic event. But again, there 
>> are not rules defined here.
>> 
>>> But the biggest doubt is about that Management Agent itself. It seems that 
>>> one needs to be developed, right?.
>> Yes. Something needs to provide YOUR policy, this is the management agent. 
>> You could buy one (this was ProSyst’s answer), there is open source (this 
>> was Marcel’s answer, or there is building it yourself. I prefer the latter 
>> because it allows you to provide your policy to the management operations. 
>> It is not a big deal because the management operations are part of the well 
>> defined OSGi API and are almost trivial to use.
>> 
>>> Should the Management Agent to use a Deployment Admin service provided by 
>>> another bundle or should it be itself the provider of such service?
>> There are no restrictions here. Make sure the Management Agent only provides 
>> policy so if you insist on using Deployment Admin then it is not a good idea 
>> to implement it yourself.
>> 
>>> And about the Repository Service, should it be used by the Management Agent 
>>> or Deployment Admin or both?
>> I think you are focusing too much on all potential possibilities. What are 
>> your requirements? OSGi is a bit like a box of Lego. Once you have a clear 
>> vision of how you want to manage your devices you find the 

Re: [osgi-dev] Understanding OSGi Initial Provisioning and Deployment Admin

[Guillaume Nodet]

Have you looked at Karaf features ? those do support bundle start levels.

Cheers,
Guillaume Nodet

2015-12-14 17:02 GMT+01:00 Seth Lana :

> Hi Peter,
>
> many thanks for your inputs, it really helped us to defined the way our
> team should to go.
>
> We had some difficulties defining the requirements of this pilot project
> due to, as you said, the large number of possibilities and combinations
> that we could have. But we are getting there...
>
> One last doubt, we have found no reference about bundle start level on
> both Initial Provisioning and Deployment Admin specs.
>
> In case of IP, we thought about two possibilities. One is to use IP
> archive's manifest file to hold the information and let the IP
> implementation bundle to use it after it install the bundle. for example:
>
> InitialProvisioning-Entries: org.apache.felix.scr;type=bundle;
> *startLevel=2*
>
> Another one is to add a text entry on the IP zip. as that will be stored
> in the provisioning dictionary then the management agent can obtain that
> information using the provisioning service and use it to set the
> startLevel.
>
> We are inclined for the option one. which would be the best approach for
> you?
>
> best regards,
>
> Seth
>
>
> On 10-12-2015 11:48, Peter Kriens wrote:
>
> On 9 dec. 2015, at 00:46, Seth Lana  
>  wrote:
> Hello,
> I’m researching about the best ways to provide automatic remote provisioning 
> for small devices and also for the servers that will provide content for such 
> devices. Reading the OSGi compendium, some specs caught my attention: Initial 
> Provisioning, Deployment Admin, Subsystems and Repository Services.
>
> If I got it right, we can have a device with only the OSGi container(with a 
> minimal deps) and the IP Agent bundle jars assembled at factory.
>
> Yes. The core idea is that you deliver identical devices to all your 
> customers except for the identity (serial number or so).
>
>
> At first use, the IP agent will contact the remote provisioning service 
> (using Http or another protocol) and will download one or more IP zip files 
> containing one or more bundles and configuration files defined by the remote 
> provisioning operator for that device. All bundles inside the IP zips will be 
> installed by the IP agent. So, this process follows until all necessary 
> bundles are installed, ending with the Management Agent bundle being started. 
> Am I right?
>
> Yup.
>
>
> What I found strange was the fact that only one bundle can be started at each 
> time (each zip can have only one start entry pointing to only one bundle). 
> Why this restriction?
>
> This allows this single bundle to verify the environment, do some checks, and 
> setup security &  start levels for example.
>
>
> Should the Management Agent uninstall the IP agent after it is fully 
> operational? or the IP must run every time the device starts up ?
>
> There is no obligation here. Personally, I would make sure that in certain 
> situations the device can go back to initial mode so that the operator can 
> regain control of the device after a catastrophic event. But again, there are 
> not rules defined here.
>
>
> But the biggest doubt is about that Management Agent itself. It seems that 
> one needs to be developed, right?.
>
> Yes. Something needs to provide YOUR policy, this is the management agent. 
> You could buy one (this was ProSyst’s answer), there is open source (this was 
> Marcel’s answer, or there is building it yourself. I prefer the latter 
> because it allows you to provide your policy to the management operations. It 
> is not a big deal because the management operations are part of the well 
> defined OSGi API and are almost trivial to use.
>
>
> Should the Management Agent to use a Deployment Admin service provided by 
> another bundle or should it be itself the provider of such service?
>
> There are no restrictions here. Make sure the Management Agent only provides 
> policy so if you insist on using Deployment Admin then it is not a good idea 
> to implement it yourself.
>
>
> And about the Repository Service, should it be used by the Management Agent 
> or Deployment Admin or both?
>
> I think you are focusing too much on all potential possibilities. What are 
> your requirements? OSGi is a bit like a box of Lego. Once you have a clear 
> vision of how you want to manage your devices you find the components in 
> OSGi. However, you can combine these components in infinite ways and 
> exploring all combinations is not providing you with the right solution any 
> time soon.
>
>
> Can a Subsystem (.esa) be package inside a Deployment Package?
>
> You can write your own Resource Processor with Deployment Admin so in 
> principle yes. However, both Deployment Admin and subsystems struggle with 
> sharing bundles. Deployment Admin took the easy way out and decided to not 
> share bundles. Subsystems do allow sharing but struggles because 

Re: [osgi-dev] Understanding OSGi Initial Provisioning and Deployment Admin

[Ferry Huberts]

On 14/12/15 20:45, chris.g...@kiffer.be wrote:

If I want the log service to start first then I make every service depend
on the log service, mandatorily.  And then if the log service restarts
then so does everything else, but so what?  Just make sure the log service
doesn't restart halfway through boot ...


except that the log service often is optional, which results in your 
option being a lot of work, as opposed to simply setting the start level 
of that single bundle





On 14/12/15 18:29, Peter Kriens wrote:

NO startlevels is best … :-)

If you really need start levels (and after thinking again) then you can
your set start levels by your management agent. One more reason why only
one bundle is started.

Though start levels can be helpful to make it look like the systems
boots faster, it is too often used to mask bad bundles that are not
properly handling their dependencies. Those bundles will give you pain
in the future so it is better to fix them from the start. And then they
do not need start levels.




As a valid use-case I see the very early starting of a log bundle...
(as an example)


Kind regards,

Peter Kriens





On 14 dec. 2015, at 17:02, Seth Lana > wrote:

Hi Peter,

many thanks for your inputs, it really helped us to defined the way
our team should to go.

We had some difficulties defining the requirements of this pilot
project due to, as you said, the large number of possibilities and
combinations that we could have. But we are getting there...

One last doubt, we have found no reference about bundle start level on
both Initial Provisioning and Deployment Admin specs.

In case of IP, we thought about two possibilities. One is to use IP
archive's manifest file to hold the information and let the IP
implementation bundle to use it after it install the bundle. for
example:

 InitialProvisioning-Entries:
 org.apache.felix.scr;type=bundle;*startLevel=2*

Another one is to add a text entry on the IP zip. as that will be
stored in the provisioning dictionary then the management agent can
obtain that information using the provisioning service and use it to
set the startLevel.

We are inclined for the option one. which would be the best approach
for you?

best regards,

Seth

On 10-12-2015 11:48, Peter Kriens wrote:

On 9 dec. 2015, at 00:46, Seth Lana  wrote:
Hello,
I’m researching about the best ways to provide automatic remote
provisioning for small devices and also for the servers that will
provide content for such devices. Reading the OSGi compendium, some
specs caught my attention: Initial Provisioning, Deployment Admin,
Subsystems and Repository Services.

If I got it right, we can have a device with only the OSGi
container(with a minimal deps) and the IP Agent bundle jars assembled
at factory.

Yes. The core idea is that you deliver identical devices to all your
customers except for the identity (serial number or so).


At first use, the IP agent will contact the remote provisioning
service (using Http or another protocol) and will download one or
more IP zip files containing one or more bundles and configuration
files defined by the remote provisioning operator for that device.
All bundles inside the IP zips will be installed by the IP agent. So,
this process follows until all necessary bundles are installed,
ending with the Management Agent bundle being started. Am I right?

Yup.


What I found strange was the fact that only one bundle can be started
at each time (each zip can have only one start entry pointing to only
one bundle). Why this restriction?

This allows this single bundle to verify the environment, do some
checks, and setup security &  start levels for example.


Should the Management Agent uninstall the IP agent after it is fully
operational? or the IP must run every time the device starts up ?

There is no obligation here. Personally, I would make sure that in
certain situations the device can go back to initial mode so that the
operator can regain control of the device after a catastrophic event.
But again, there are not rules defined here.


But the biggest doubt is about that Management Agent itself. It seems
that one needs to be developed, right?.

Yes. Something needs to provide YOUR policy, this is the management
agent. You could buy one (this was ProSyst’s answer), there is open
source (this was Marcel’s answer, or there is building it yourself. I
prefer the latter because it allows you to provide your policy to the
management operations. It is not a big deal because the management
operations are part of the well defined OSGi API and are almost
trivial to use.


Should the Management Agent to use a Deployment Admin service
provided by another bundle or should it be itself the provider of
such service?

There are no restrictions here. Make sure the Management Agent only
provides policy so if you insist on using Deployment Admin then it is
not a good idea to implement it 

Re: [osgi-dev] Understanding OSGi Initial Provisioning and Deployment Admin

[Ferry Huberts]

On 14/12/15 18:29, Peter Kriens wrote:

NO startlevels is best … :-)

If you really need start levels (and after thinking again) then you can
your set start levels by your management agent. One more reason why only
one bundle is started.

Though start levels can be helpful to make it look like the systems
boots faster, it is too often used to mask bad bundles that are not
properly handling their dependencies. Those bundles will give you pain
in the future so it is better to fix them from the start. And then they
do not need start levels.




As a valid use-case I see the very early starting of a log bundle...
(as an example)


Kind regards,

Peter Kriens





On 14 dec. 2015, at 17:02, Seth Lana > wrote:

Hi Peter,

many thanks for your inputs, it really helped us to defined the way
our team should to go.

We had some difficulties defining the requirements of this pilot
project due to, as you said, the large number of possibilities and
combinations that we could have. But we are getting there...

One last doubt, we have found no reference about bundle start level on
both Initial Provisioning and Deployment Admin specs.

In case of IP, we thought about two possibilities. One is to use IP
archive's manifest file to hold the information and let the IP
implementation bundle to use it after it install the bundle. for example:

InitialProvisioning-Entries:
org.apache.felix.scr;type=bundle;*startLevel=2*

Another one is to add a text entry on the IP zip. as that will be
stored in the provisioning dictionary then the management agent can
obtain that information using the provisioning service and use it to
set the startLevel.

We are inclined for the option one. which would be the best approach
for you?

best regards,

Seth

On 10-12-2015 11:48, Peter Kriens wrote:

On 9 dec. 2015, at 00:46, Seth Lana  wrote:
Hello,
I’m researching about the best ways to provide automatic remote provisioning 
for small devices and also for the servers that will provide content for such 
devices. Reading the OSGi compendium, some specs caught my attention: Initial 
Provisioning, Deployment Admin, Subsystems and Repository Services.

If I got it right, we can have a device with only the OSGi container(with a 
minimal deps) and the IP Agent bundle jars assembled at factory.

Yes. The core idea is that you deliver identical devices to all your customers 
except for the identity (serial number or so).


At first use, the IP agent will contact the remote provisioning service (using 
Http or another protocol) and will download one or more IP zip files containing 
one or more bundles and configuration files defined by the remote provisioning 
operator for that device. All bundles inside the IP zips will be installed by 
the IP agent. So, this process follows until all necessary bundles are 
installed, ending with the Management Agent bundle being started. Am I right?

Yup.


What I found strange was the fact that only one bundle can be started at each 
time (each zip can have only one start entry pointing to only one bundle). Why 
this restriction?

This allows this single bundle to verify the environment, do some checks, and setup 
security &  start levels for example.


Should the Management Agent uninstall the IP agent after it is fully 
operational? or the IP must run every time the device starts up ?

There is no obligation here. Personally, I would make sure that in certain 
situations the device can go back to initial mode so that the operator can 
regain control of the device after a catastrophic event. But again, there are 
not rules defined here.


But the biggest doubt is about that Management Agent itself. It seems that one 
needs to be developed, right?.

Yes. Something needs to provide YOUR policy, this is the management agent. You 
could buy one (this was ProSyst’s answer), there is open source (this was 
Marcel’s answer, or there is building it yourself. I prefer the latter because 
it allows you to provide your policy to the management operations. It is not a 
big deal because the management operations are part of the well defined OSGi 
API and are almost trivial to use.


Should the Management Agent to use a Deployment Admin service provided by 
another bundle or should it be itself the provider of such service?

There are no restrictions here. Make sure the Management Agent only provides 
policy so if you insist on using Deployment Admin then it is not a good idea to 
implement it yourself.


And about the Repository Service, should it be used by the Management Agent or 
Deployment Admin or both?

I think you are focusing too much on all potential possibilities. What are your 
requirements? OSGi is a bit like a box of Lego. Once you have a clear vision of 
how you want to manage your devices you find the components in OSGi. However, 
you can combine these components in infinite ways and exploring all 
combinations is not providing 

Re: [osgi-dev] Understanding OSGi Initial Provisioning and Deployment Admin

[chris . gray]

If I want the log service to start first then I make every service depend
on the log service, mandatorily.  And then if the log service restarts
then so does everything else, but so what?  Just make sure the log service
doesn't restart halfway through boot ...

> On 14/12/15 18:29, Peter Kriens wrote:
>> NO startlevels is best … :-)
>>
>> If you really need start levels (and after thinking again) then you can
>> your set start levels by your management agent. One more reason why only
>> one bundle is started.
>>
>> Though start levels can be helpful to make it look like the systems
>> boots faster, it is too often used to mask bad bundles that are not
>> properly handling their dependencies. Those bundles will give you pain
>> in the future so it is better to fix them from the start. And then they
>> do not need start levels.
>>
>
>
> As a valid use-case I see the very early starting of a log bundle...
> (as an example)
>
>> Kind regards,
>>
>> Peter Kriens
>>
>>
>>
>>
>>> On 14 dec. 2015, at 17:02, Seth Lana >> > wrote:
>>>
>>> Hi Peter,
>>>
>>> many thanks for your inputs, it really helped us to defined the way
>>> our team should to go.
>>>
>>> We had some difficulties defining the requirements of this pilot
>>> project due to, as you said, the large number of possibilities and
>>> combinations that we could have. But we are getting there...
>>>
>>> One last doubt, we have found no reference about bundle start level on
>>> both Initial Provisioning and Deployment Admin specs.
>>>
>>> In case of IP, we thought about two possibilities. One is to use IP
>>> archive's manifest file to hold the information and let the IP
>>> implementation bundle to use it after it install the bundle. for
>>> example:
>>>
>>> InitialProvisioning-Entries:
>>> org.apache.felix.scr;type=bundle;*startLevel=2*
>>>
>>> Another one is to add a text entry on the IP zip. as that will be
>>> stored in the provisioning dictionary then the management agent can
>>> obtain that information using the provisioning service and use it to
>>> set the startLevel.
>>>
>>> We are inclined for the option one. which would be the best approach
>>> for you?
>>>
>>> best regards,
>>>
>>> Seth
>>>
>>> On 10-12-2015 11:48, Peter Kriens wrote:
> On 9 dec. 2015, at 00:46, Seth Lana  wrote:
> Hello,
> I’m researching about the best ways to provide automatic remote
> provisioning for small devices and also for the servers that will
> provide content for such devices. Reading the OSGi compendium, some
> specs caught my attention: Initial Provisioning, Deployment Admin,
> Subsystems and Repository Services.
>
> If I got it right, we can have a device with only the OSGi
> container(with a minimal deps) and the IP Agent bundle jars assembled
> at factory.
 Yes. The core idea is that you deliver identical devices to all your
 customers except for the identity (serial number or so).

> At first use, the IP agent will contact the remote provisioning
> service (using Http or another protocol) and will download one or
> more IP zip files containing one or more bundles and configuration
> files defined by the remote provisioning operator for that device.
> All bundles inside the IP zips will be installed by the IP agent. So,
> this process follows until all necessary bundles are installed,
> ending with the Management Agent bundle being started. Am I right?
 Yup.

> What I found strange was the fact that only one bundle can be started
> at each time (each zip can have only one start entry pointing to only
> one bundle). Why this restriction?
 This allows this single bundle to verify the environment, do some
 checks, and setup security &  start levels for example.

> Should the Management Agent uninstall the IP agent after it is fully
> operational? or the IP must run every time the device starts up ?
 There is no obligation here. Personally, I would make sure that in
 certain situations the device can go back to initial mode so that the
 operator can regain control of the device after a catastrophic event.
 But again, there are not rules defined here.

> But the biggest doubt is about that Management Agent itself. It seems
> that one needs to be developed, right?.
 Yes. Something needs to provide YOUR policy, this is the management
 agent. You could buy one (this was ProSyst’s answer), there is open
 source (this was Marcel’s answer, or there is building it yourself. I
 prefer the latter because it allows you to provide your policy to the
 management operations. It is not a big deal because the management
 operations are part of the well defined OSGi API and are almost
 trivial to use.

> Should the Management Agent to use a Deployment Admin service
> provided by another bundle or should it