> -----Original Message-----
> From: Marcel Offermans [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 23, 2008 4:29 PM
> To: [email protected]
> Subject: Re: Java Sandbox and OSGi
>
> Hello Sam,
>
> On May 23, 2008, at 21:08 , Kass, Samuel-P58051 wrote:
>
> > I'm investigating converting our large codebase to a
> modular system.
> > However, one of the requirements is the ability to run as
> an applet or
> > webstart application. In addition, some of our customers are
> > extremely security-concious and prefer to limit us to the most
> > restrictive possible Java security settings.
>
> Would these restrictions then apply to the OSGi framework
> implementation itself or the bundles that are deployed inside
> the framework? I mean your users probably trust the Java
> Virtual Machine, so where exactly does their trust end?
The trust ends at the JVM. The OSGi framework implementation and
everything inside it all have to run in the sandbox.
> If you want to run the bundles in secure sandboxes, you can
> run the OSGi framework with security. See the Conditional
> Permission Admin part of the spec for more information on
> what this brings you. In short, you can create security
> policies for each individual bundle.
I was hoping that OSGi could integrate a little better with existing
Java methodology. Since the OSGi framework implementation(s) would need
extensive security reviews, but the JVM has already had such a review,
it's not really viable to switch to OSGi security anytime soon.
> > I assume the ability to create a new classloader is at
> the top of the
> > list. But if even that was restricted,...
> ...
> Something similar, although a bit different, is currently
> being discussed within the SIP Communicator community
> (they're also using Apache Felix). They are trying to make
> their application run as an applet and have all persistence
> on the server.
I'll check out the SIP Communicator stuff, thanks. It sounds like
they're attempting something fairly similar.
> Caching the bundles and their state actually is a requirement
> of the OSGi spec, which basically says that if a frameworked
> is stopped and started again, all bundles should still be
> there and in the same state as when you stopped the
> framework. Of course you could deviate from the spec here...
Whether or not I deviate from the spec, I have other ways to serialize
information over the network... That may be a more significant change to
Felix, though. (Again, I'll check out the "SIP Communicator" thing you
mention.)
>
> > Since much of our codebase is in the form of a
> re-usable engine that
> > is shared from server to applet, without this possibility
> pushing OSGi
> > into our core codebase is an extremely hard sell. Thoughts?
>
> If your codebase is modular, then it should not be too hard
> to use OSGi in such a way that the modules themselves have no
> knowledge of being bundles. In other words, you can probably
> make sure your components are POJO's that somehow get their
> dependencies injected. At Felix we have several utilities
> (Dependency Manager, Declarative Services and iPOJO) that
> help you with that. In that case, if you don't need
> modularity at runtime (when the code runs in an applet) you
> can simply package the code differently.
The latter sounds like the approach I was thinking of. I would
definitely want to use all the OSGi goodness of enforced versioning and
encapsulation when our engine is used in an enterprise setting. But I'd
like to be able to take the same back-end code and stuff it all into a
jar and run it as an applet. I'm concerned if I start using OSGi
services to implement inter-module communication that my core engine
will start to depend on being written on top of an OSGi framework
implementation, and it will lose the ability to support applet
development.
For example, if I wanted to replace our command-line arguments and XML
settings files with some usage of ConfigAdmin to configure code, I'll
need to run on a system that understands ConfigAdmin, right? And if I
want to use an OSGi activator for initialization, I'll need to run on a
system that calls the start() method of my activators.
I guess I'm just asking how to get the power of OSGi when I need it, but
be able to degrade gracefully into deployments that are too limited for
OSGi.
>
> Is it true that you sometimes need modularity at runtime,
> being able to install or upgrade certain modules without
> bringing down the whole system, whilst sometimes you don't
> need it (in an applet)?
Being able to upgrade and install without bringing down the system is a
"nice to have". What's got me sold on OSGi is the enforcement of loose
coupling between bundles, the ability to deploy capabilities selectively
without having to worry about unknown interdependencies, being able to
explicitly version third-party dependent libs and my compatibility with
them, the ability of third parties to have an explicit mechanism to add
functionality to our system, and its level of maturity and community
support above other similar solutions to these problems. Being able to
stop, load, and unload at runtime is a minor feature addition to me,
that if it were omitted would barely affect my desire to go with OSGi.
--Sam Kass
Systems Engineer, Command Post Of the Future (CPOF)
General Dynamics C4 Systems
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
