river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Date Tue, 28 Jul 2009 03:33:23 GMT
On Tue, Jul 28, 2009 at 3:19 AM, Gregg Wonderly<gergg@cox.net> wrote:

> It comes down to whether that logic really must live in the lookup, or in
> the client.  And, as many people have said before, you can write a new
> lookup "service" that uses these features and have your application lookup
> that lookup server by interface, and then call methods on it to find the
> matches.

Ok, let's examine such "Named Service Properties Lookup";

 1. It defines that each service can have N key-value pairs; No problems.
 2. It will have a service interface that allow the lookup in OSGi
syntax. No problems.
 3. It will either require;
   a. That the service explicitly register itself at it.
   b. That the NSPL lookup all other services on the federation and
extract the key-value pairs somehow, and possibly allow annotation of
it independently.

3a is to me equal -> Will not be promoted, therefor not used.
3b is possible but seems like a big hack, compared to complementing
the API with key-value mapped attributes and an expression language
not executed by unmarshalling any service proxies.

> Let me restate one thing, which I really don't think people appreciate.
> Unmarshalling services in a client is EXPENSIVE.  If you are picking 1, from
> 100 instances by executing some code that the service proxy provides, there
> will be problems.

Isn't the above a strong argument against "let the client do it"?
First do a general lookup, which provides 20 services, transport and
unmarshall those service proxies to the client, and then inspect
further. That can't be the way to do it, and I don't think you promote
that either with your "It comes down to whether that logic really must
live in the lookup, or in the client." statement, but it is how I
initially read it.

> The basic issue from my perspective is that if people don't talk about
> specifics, but only generalize about the issues, resolution doesn't happen
> very fast.  I try to talk about specifics,

Well, I agree that "actual usecases" are superior in discussions.
But there are psychological problems as well. Once you say "My
solution is superior because...", then the recipient will stop listen
and go into defense mode to find cracks in the armor (your argument),
and will counter (in this case), "Ha, rubbish. You can't even do
arithmetic lookup.". From then on the discussion is over and it
becomes a religious/political game of 'mine is longer than yours'...

I am not here anymore to try and get OSGi and Jini communities to
converge. That battle is long ago over, and both sides (IMHO) lost,
since they didn't get a single inch closer. OSGi has the "we can do it
all"-attitude at the moment, and the distributed solution (at API/SPI
level) has been formulated and solutions worked out. Jini community
can no longer become a 'contributing participant', and that is a
shame. River *could* choose to be 'conformist', i.e. take the RFC-119
spec and implement it with Jini technology, and in that process see
what 'new things' (detailed as you call it) would surface for Jini.

Organizationally, OSGi allows the public to write so called RFPs.
Those are "Requirement" docs which outlines the need, but don't touch
on the solution. The RFPs are expected to be extremely
usecase-oriented with hypothetical (or real) walk-thrus of what is
needed. Feel free to contribute the need for type hierarchies in
service lookups.

Personally, I like both Jini and OSGi, but regretfully I am currently
not working actively on either one of them (offers welcome ;-) )...
And I should be the last one to say what the communities should do to
move forward.


Cheers
-- 
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java

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

Mime
View raw message