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
