river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Chance <sgcha...@gmail.com>
Subject Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Date Thu, 16 Jul 2009 22:16:26 GMT

That's more than reasonable! I wish I could go down to the details you
require, but I just can't.  Partly because I don't get that detailed in my
work, and partly due to sensitivities of my customer space.

The net-net of it in my mind is that it provides the basis for (re-)using
pre-built, pre-tested and *pre-approved* software modules.  From a software
acquisition point of view, I (really, my client space) can purchase only the
software required and not pay for the same things repeatedly and
unwittingly.  The standardized modularization allows me, as a systems
integrator, to better streamline the different levels of testing.  Similar
to auto parts, software "parts" become more commodotized and

>From a architecture perspective, OSGi provides a dynamic and *in-VM* SOA.
Instead of only exposing [XML Web] services around the periphery, entire
systems can (are) be(ing) built as a collection of [OSGi] services.  One can
also modularize bindings/protocols and use something like SCA to "wire them
into the system" [read: Paremus]. The dynamicity of OSGi allows for the idea
of "hot swapping".  In fact, it seems Oracle has gone to excess discussing
the ability to "hot swap" components.

A "practical reality" benefit is the wide-scale buy-in. Major companies
who've committed to it include Oracle/Sun, IBM, SAP, Red Hat, SpringSource,
TIBCO, Sprint, Progress, and on and on. Apache ServiceMix, Jetty, JonAS (I
think) and others are built on OSGi. Many vendors with whom I deal most are
OSGi powered or in the process. Apache Felix, Eclipse Equinox, Knoplerfish
are OSGi runtimes.  Paremus implements the *granddaddy* of them all though,
a distributed OSGi runtime. See
http://www.infoq.com/news/2008/02/infiniflow-12 for a "lightweight" intro.

Another benefit is the simplicity. The gist of it is a small amount of
metadata in the manifest file and a small state space for "deployed" bundles
(Started, Stopped, Active... a few more).

I learned today that a major "program" is migrating an entire, large system
to the OSGi technology platform.

All this isn't necessarily "technical", but I don't dwell exclusively in the
technical domain.  I have to span from electrons to executives.  It's just
the nature of my job. I will say my developers love me for introducing it.

Paremus is the company that saw the vision. They are the ones who made
[disributed OSGi] a reality. I'm simply spreading the flame inasmuch as I am

My purpose for bringing OSGi up in the context of River is because I feel
OSGi is a "local JVM" version of Jini. And it seems reasonable to believe
they are even better paired together.  At least one company, Paremus,

So, if one decides they like the idea, what should they build? I don't
know.  Maybe they could build a distribution framework that makes OSGi
bundles "visible" and "accessible" across the planet in one large repository
of functionality!

Next, they could extend the LookUp / query capability to semantic (i.e.
logical/contextual) lookup/discovery.  See the Semantic Web Technology space
for more info at http://www.w3.org/2001/sw/, http://linkeddata.org.

Thank you!

On Thu, Jul 16, 2009 at 3:59 PM, Gregg Wonderly <gergg@cox.net> wrote:

> Sam, I am at a loss for words...
> It's clear that I am not able to ask for help in understanding the benefits
> that you see, or perhaps you can't relate them to me.  I'm just looking for
> your experiences and the values you see.  I know what OSGi says it is.  I
> know how to read the documentation (again and again) to see what it
> currently supports in each new release.
> That's not what I am looking for.  I'm trying to get first hand reports and
> recommendations on what is valuable to those who have used it and deployed
> things using it.  I want to see which of the possible set of features that
> Jini could provide for OSGi inter-working would allow someone to get some
> benefits.
> For example, preferred class loading solves some class loading issues.
>  But, if some parts of OSGi have removed those benefits from your view and
> you don't need them any longer, I'd like to know more about that.
> Do you just like OSGi because it's a container that you drop things into
> and they work?
> I want to know the details of your experiences please.
> Gregg Wonderly
> Sam Chance wrote:
>> Gregg,
>> It is not my desire or intention to try to play "technology ping-pong."
>>  I'm
>> only introducing another viewpoint.  Frankly, I don't have time to read
>> long, verbose emails.  I've touted enough OSGi technology attributes to
>> intrigue those who might be interested in learning more.  The answers to
>> your questions can be found on the OSGi Alliance's web site - and I
>> promise
>> you there are solid answers.  Additionally, a number of books that provide
>> ample OSGi coverage are either recently published or nearing publication.
>> Oracle, Sun, IBM, SpringSource, JBoss, Progress, Paremus, ProSyst and
>> others
>> offer a lot of informative OSGi literature as well. Neal Bartlett also
>> provides a lot of OSGi resources.  Eclipse [Equinox] and Apache Felix are
>> great places as well.
>> Happy Learning! :-)
>> Sam
>> On Tue, Jul 14, 2009 at 6:49 PM, Gregg Wonderly <gregg@wonderly.org>
>> wrote:
>>  Sam Chance wrote:
>>>  In fact, OSGi does help a lot with "Classpath Hell".
>>>>  I didn't see a reply from my earlier request for more information on
>>> the
>>> issues that the OSGi experienced think OSGi helps the most with regarding
>>> this issue. I'd really like to see what issues you all have had and that
>>> OSGi has addressed.
>>> Is it just that packaging encloses the set of things you need to make
>>> things work and you don't have to worry about that, or is it something
>>> else?
>>>  Many containers use ClassLoader hierarchies of various shapes to isolate
>>> and "interrelate" different types of package structures.  I'm just
>>> interested in knowing more about the issues and benefits you all
>>> recognize
>>> from your experiences.
>>>  OSGi also adds another layer of security above the standard Java.
>>> What do you feel is important about this?  Authentication vs
>>> Authorization
>>> issues would be great to have your opinions and experience on.
>>>  Versioning is a "first-class function" in OSGi.
>>> This is a big deal for separating old and new.  I think we have a good
>>> bit
>>> of this in the PreferredClass mechanisms in Jini 2.x so that
>>> implementations
>>> can be  forced into use for bug fixing and interfacing with different
>>> versions of difference services.  Is there anything else beside
>>> classloader
>>> based separation that you all find important in what OSGi provides?
>>> Gregg Wonderly

Sam Chance
443-694-5293 (m)
410-694-0240 x108 (o)

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message