Re: Jini vs/and OSGi

On Saturday 31 March 2007 02:37, you wrote:
> Niclas Hedhman wrote:

> I must say I'm somewhat surprised by your view of this thread. If I read
> the thread back I don't see any camps and you make it look like some
> OSGi bashing took place. Ok, every person has its own style of writing,
> but I think most of the people agreed they are complementary (although I
> added that the combination may not be without its problems).

The "bashing" happens in both directions, but since OSGi seems to "take off", 
Jini is the one who has the most to loose (market wise). OSGi "just" loose a 
great solution to (for OSGi Alliance) a yet to be defined problem.

> The remarks were with regard to this particular paper and as I said in
> my posting I don't know in which direction the enterprise working group
> is thinking.

I do. I am in the EEG. There is no "direction" yet. A phase of requirements 
gathering is happening. Anyone is free to submit a so called RFP which 
describes the problem domain, use-cases and requirements for a solution.
And here is your chance. Express Jini in these terms, and I'll help push that 
requirement into the RFC (the solution) in a format that makes Jini the most 
obvious choice of implementation. Spring is doing the pain-staking RFP of a 
solution where the spec is almost done.

> As far as I'm concerned there is no closing of doors, but I also don't
> see the (personal) need to try to educate them in particular or to treat
> them differently then J2EE e.g. or any other platform.

No comment.

> The thing is that in essence Jini (and I'm not talking about the JTSK)
> only describes how services are exposed to the network (through Java
> interfaces) and defines the basic required infrastructure and concepts.

Well, yes and no.
Once you include mobile code, you enter the realm of classloading and 
security.
I think if you educate Kriens, I think he would withdraw his remarks of 
security in Jini 2.x. But classloading is an achilles heal for Jini.

On Saturday 31 March 2007 02:27, Gregg Wonderly wrote:
> 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. 

Here is the essence of why Jini is a marginal technology. The "what can X give 
to Jini" instead of "what can Jini give to X". Purely egoistic, for obvious 
reasons. People who need Jini, must use Jini due to the nature of their 
business, automatically restrict themselves in how the "environment" will 
look like.

Back to Mark...

> The great thing was that as such it could be the friend of every
> platform, container, etc, etc. built on top of Java, if and only if they
> all could agree about the basic infrastructure to be there (and then it
> helps to be part of J2SE). A long time ago there was a grand idea that
> the foundation for this infrastructure would be brought to J2SE and you
> through JSR 76 and 78 and we know what happened with them
> (http://www.jcp.org/en/jsr/results?id=325 and
> http://www.jcp.org/en/jsr/results?id=328).

Yes, I was part of the spectacle. Politics from all over the place, including 
the RMI team in Boston, who IMHO pushed the EG to go for public review before 
the specification was satisfactory from a technical perspective, since it HAD 
TO be part of Java 1.3 (or was it 1.4?) release, soon around the corner.

> Personally I would love to see the ability to write Jini services as
> part of a J2EE container, OSGi Platform, fill in a name and to consume
> it as client from any other platform because that was the whole
> magical idea behind Jini.

Writing a Jini service and deploying it on OSGi is probably possible without 
too much headaches. Not really talking about that.

The Service layer in OSGi has a huge conceptual overlap with the service 
notion in Jini. The dynamic properties of things coming and going are the 
same. Notifications via events are essential in both. Security is central.
I can create a LookupCache in Jini or a ServiceTracker in OSGi to be notified 
of changes in the service, such as the meta-data (properties) of it.

OSGI recognized that total transparency for networked services are not 
feasible, but just like RMI, make it very simple for the programmer to handle 
the distinction. Why shouldn't it be a matter of setting a property in the 
OSGi service to have it exposed as a Jini service? And vice versa. Why 
wouldn't it be totally natural that the Jini services are visible as OSGi 
services? 
Sure there are things that can't be done, due to constraint in one platform or 
the other. BUT that is not the point. It is not "What can it give me?", 
but "what can I give to it?"...

> > hmmmm... Is there any will? Or just the will to criticize, feeling proud
> > and "they don't get it"??
> Niclas it requires a very strong spinal cord these days to feel proud
> and to publicly admit you are using Jini, as it was in the past, so I
> just don't understand this last remark.

Yeah, not speaking of "publicly" as in going into a sales position, but I was 
refering to 'here'. Gregg says; "OSGi can't give me anything" and I have 
heard Dan, you and others essentially saying that "Here is a list of 
scenarios where OSGi can't be used, and here is another list of stuff I would 
loose out on if I deploy on OSGi, and here is a list...."
"Proud" as in "I have the answers to my questions, and not interested in 
sharing..."

Gregg; I agree that the Eclipse folks are obnoxiously proud. The lower level 
guys (Equinox) are more humble and always open to discuss technology.


Cheers
-- 
Niclas Hedhman, Software Developer

I  live here; http://tinyurl.com/2qq9er
I  work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug

--------------------------------------------------------------------------
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]