=> http://fabric.fusesource.org/
Kind regards,
Jean-Philippe
Quoting DEBROUX Lionel <[email protected]>:
Hello,
I have a use case for deploying bundles (which may have transitive,
versioned dependencies) accross several LAN nodes all installed with
the Felix framework.
The main goal is to have, for each node, the ability of:
- (1) acting as a server for bundles towards other nodes
- (2) downloading and installing bundles from other nodes, since all
nodes provide (1)
Each node would also be expected to:
- (3) have every downloaded and/or installed bundle automatically
appearing as available for download to other nodes.
Therefore, the use case is a step beyond the standard model, where
client nodes are in most cases constantly downloading from a known
and predefined "central" OBR.
The point is to:
- enhance robustness, in case remote OBRs are unreachable when the
need to deploy bundles to other nodes arise.
- favor deployments within local node neighbourhood, by exposing
bundles to a set of nearby nodes.
Example:
Nodes A, B and C belong to the same network neighbourhood N1
Nodes C, D and E belong to the same network neighbourhood N2
- C gets and deploys bundle Foo from E using (2)
- as a member of both N1 and N2, bundle Foo becomes then available
to all members of N1 and N2 because of (3) and (1)
- E dies
- A and B can get and deploy bundle Foo from C rather than from E.
I'd like hints on how to best use the OBR infrastructure to achieve
(1), (2) and especially (3). Maybe it needs to be modified ?
Or maybe there are better solutions than the OBR infrastructure ?
I looked at OBRs because the OBR client can download from multiple
OBRs, and transitive dependencies are handled.
However, I noticed that:
* updating OBR XML files takes some work. There's the Maven plugin,
but I'd rather not use that in production, there should be
something leaner;
* when deploying a bundle, ResolverImpl.deploy() calls
BundleContext.installBundle() but does not keep a separate copy
of the bundle, which I'd like to do;
* dumping the local repository to XML form, through
DataModelHelper.writeRepository(), is easy, but there are no
URIs for the bundles in there. As a consequence, even if I
exposed the local repository XML file on the network, OBR
clients wouldn't be able to install the bundles.
For demo purposes, I can build a custom solution, starting by exposing
through servlets directories containing bundles. In fact, I have been
given some code that does just that. From that point, I have made some
rough code to download and install individual bundles into the target
framework.
But for production use, I'll want to provide some higher-level
information (bundle symbolic names, dependencies, etc.) and handle
transitive dependencies... which brings me back to the already
invented OBR wheel :)
Thanks in advance for replies,
Lionel.
________________________________
Ce message et les pièces jointes sont confidentiels et réservés à
l'usage exclusif de ses destinataires. Il peut également être
protégé par le secret professionnel. Si vous recevez ce message par
erreur, merci d'en avertir immédiatement l'expéditeur et de le
détruire. L'intégrité du message ne pouvant être assurée sur
Internet, la responsabilité du groupe Atos ne pourra être engagée
quant au contenu de ce message. Bien que les meilleurs efforts
soient faits pour maintenir cette transmission exempte de tout
virus, l'expéditeur ne donne aucune garantie à cet égard et sa
responsabilité ne saurait être engagée pour tout dommage résultant
d'un virus transmis.
This e-mail and the documents attached are confidential and intended
solely for the addressee; it may also be privileged. If you receive
this e-mail in error, please notify the sender immediately and
destroy it. As its integrity cannot be secured on the Internet, the
Atos group liability cannot be triggered for the message content.
Although the sender endeavors to maintain a computer virus-free
network, the sender does not warrant that this transmission is
virus-free and will not be liable for any damages resulting from any
virus transmitted.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
