Re: Jini vs/and OSGi

richard nicholson wrote:
> +1
>
> For those of you that agree with Niclas and want to "learn" and
> "contribute", step up and join us  - newton.codecauldron.org.

One of the biggest things for me about packages of software, is what problem(s)
do they solve.  In my world, putting together many disparet packages into a
single container while maintaining some standard classloader separation is not
at the top of my list.  I understand classloaders and have no qualms about
deciding on a "platform" for a particular container, arranging classloading and
making it happen.

When I look at OSGi from a simple perspective, the classloading packaging is the
only thing that I see that it actually provides.  There are a wealth of bits
related to how you tell what to package and how it manages those packages
(including lifecycle). Those extra bits, are necessary only because of the basis
  of the system design.

In Jini, the primary thing we are assembling are distributed systems, not
packages of systems.  This means that we are typically more interested in code
mobility related classloading than we are packaging separation.

The JTSK includes the com.sun.jini.start package which includes the
NonActivatableServiceDescriptor which is all you need to create a container full
of classloading isolated, transient services in the Jini environment.  The
"packaging" problem is solved by this class, shall I say summarily?

In the client space, where there might be multiple serviceUIs active at the same
time, in the same JVM, you have a real need for security.  You need a platform
that all such serviceUIs can depend on being there as well.  Maybe it's just
J2SE classes, maybe it's a windowing environment with a standard interface such
as ServiceUI.

OSGi doesn't seem to take anything about mobile code and related authentication
and authorization into account.

So to me, there are huge voids between the thoughts and concepts around the
evolution of both.  I'm sitting here, solving the problems that I have (in my
work environment), with what I have access to in the Jini toolset (plus the
tools that you see in my projects on java.net).

I'm at a loss for how to further explain that, right now, I just don't see that
I can possibly get any benefit from OSGi.  I use netbeans for my IDE, so I don't
see OSGi as a piece of my environment as an eclipse user might.

As a final note, I'm neutral in my view of OSGi as a viable technology (for some
class of problems).

But practically, I have had a bad experience interacting with the IBM developers
working on eclipse.  They showed a "we know what you need, just shutup and use
it" kind of attitude to me, one too many times.  I don't have time for that kind
of stupidity in a technology industry.

When I think about eclipse using OSGi and the push to make people use it, I
can't help but feel unsure of what the real motivation is.

Considering that there are many others in the industry who are not all over it
as well, I sense that my feelings might have some validity to them.

So, right now, I'm just setting back and watching.  I'm not looking for a new
packaging system.  I am still evaluating Seven, and as Mark works through some
of the configurable behaviors that I need to have, I'll probably start using it
as my primary service deployment mechanism (don't get a big head yet Mark:-).

Could Mark wrap seven service packages up in an OSGi bundle?  Probably.  Would
that mean that now I could stick my service inside of eclipse and run it there?
  probably not.  It would need other shared infrastructure (the platform) that
includes thing that I'm not sure that OSGi will ever support.

Not trying to just say negative things, but just voice my opinion about why I am
where I'm at on this whole thing.  And I am sure that there is some ignorance
and misinterpretation on my part behind all of this...

Gregg Wonderly

--------------------------------------------------------------------------
Getting Started:     http://www.jini.org/wiki/Category:Getting_Started
Community Web Site:  http://jini.org
jini-users Archive:  http://archives.java.sun.com/archives/jini-users.html
Unsubscribing:       email "signoff JINI-USERS"  to [email protected]