On 9 dec. 2015, at 00:46, Seth Lana<sethlanag...@gmail.com> 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 regards,
Peter Kriens
thanks for any opinion.
regards, Seth.
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
