river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <ge...@cox.net>
Subject Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Date Mon, 27 Jul 2009 19:19:45 GMT
Niclas Hedhman wrote:
> On Thu, Jul 23, 2009 at 1:29 AM, Gregg Wonderly<gregg@wonderly.org> wrote:
>> The issue which I think is never fully considered is that lookup is based on
>> the Java type system, including complex types, and not based on string
>> matching.  If it was just string matching, we'd have RE support now.  But
>> there is no defined RE syntax for "derived from" or "implements X" etc.  The
>> Java type system provides that.
> Yes, that is the view of "Jini Zealot" ;-) 

It's view that takes versioning into account and some other issues that I think 
are under appreciated.  Sure, strings are simple and easy, right up to the point 
that you have to keep finding new ways to specify that you want to do something 
that a hierarchical type system lets you do with one name, and strings make you 
do with 10 values, 4 expressions and an extra "if" or two.  Then, strings seem 
kind of fragile and not so "cute".

 > and their argument is that Jini Lookup can't do algorithms and arithmetic.

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.

Whether that "mechanism" should be the primary service or not has always been 
the sticking point for the Sun team.  They always suggested (and I concurred) 
that "Jini" doesn't keep you from doing that if you need it, so from a 
"platform" perspective, it doesn't seem like something "Jini" should specify.

Instead, someone can write such a thing, make it available for others to use, 
and the community could take advantage of it as needed.

I consider RIO an example of such a thing.  The QOS facilities of RIO, some 
could argue, could be part of the lookup.  You could say:

o   I want a service that's been up for a week at least
o   I want a processor that is at least at 2.5ghz
o   I want a service instance that has 1TB of work space on disk

and other things.  But, this is such a specialized view of lookup, that it 
doesn't seem like it should be in the "API".  Some of that could be done in 
Entry objects, but it might be better to do it with a "service" that can do the 
analysis and make things happen that need to happen.

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 

> And as long as either
> side don't want to look for the converged solution, this status quo
> will remain, just like when I first brought this up 2-3 years ago. And
> Kriens & Co at OSGi will have the same 'we are so much better'
> attitude as well...

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, always, but there are people who just 
don't want specifics, they just want to hear "yes", "no", "that sucks", "won't 
do it", or "not invented here" kinds of things so they can ride the coattail of 
arguments instead becoming educated in the reasoning and history in a way that 
allows them to help the other party understand the differences they think are 

Detailed vs Concise are at opposite ends of the spectrum in most cases.  Many 
people are hard against one of these two terms without much desire to float 
between them as needed.  Detailed and Concise is usually only possible if all 
the "details" have already been explained.

>> I will concede that the mechanics of matching in reggie are a
>> reimplementation of the type system semantics, because code is not
>> unmarshalled (as a versioning, code corruption, and security measure, at the
>> least).
> This is just a result of the initial decision to have Entry and
> inheritance as the basis for service attributes. Another decision
> could have been made that we only allow named properties, where the
> name is a String and the Value is any one of the following immutable
> types... In retrospect, can you really claim that the way Jini chose
> is superior an alternate route? I am not so sure...

A type like system is needed for type hierarchies.  You can't match a type 
hierarchy out of a single string without all of the hierarchy present in some 
form, in that string.

It's interesting to talk about "values" and "named properties".  Types, in Java, 
are generally used to put groups of these pairs together.

It's the power of expanding a group, by amending it's contents that most 
application history revolves around.  Versioning in our brains and in practice 
cause us to use Types to "constrain" groups of things into logical sets with the 
type system providing a simple name/moniker for that group of items (and 
functions in the OO world).

Practically, "maps" are another way to do this grouping.  Maps don't have 
mechanisms which allow you to assert that a given set of properties are present 
at "compile time" without some specific qualities that are normally expressed in 
code that lives somewhere.  A name for those "semantics" has to exist to 
properly represent "everything" that is detailed.

With just a map and no name/moniker, you have to look for, or request, or 
enumerate all of them.  This means that simple names in a type system must be 
represented by a complex collection or list of "things".

Things like "corn flakes" are maps because every manufacturer has a specific 
recipe and quality part of the product.  "General Mills" or "Quaker" and other 
brand names are like "class names" or types.  They tell you a lot of specifics 
about the corn flakes.  To say everything about them without the brand name, you 
have a lot of enumerated parts to keep up with, understand and process, everywhere.

There are reasons, beyond the "initial implementation did it this way" that make 
the type system interesting from my perspective.

>> I'm more than willing to put together a new lookup service that does provide
>> "string only" lookup of Entry.toString() values.  It would be possible to
>> include new data, taken from the Entry values before they are marshalled for
>> transport.
>> My changes to reggie to support deferred downloading, include the packaging
>> of all class and interface names as part of the MarshalledInstance so that
>> you can ask if an Entry (or the service itself) "is a" without having to
>> unmarshall it.
> This proposal sounds like a hack. You are trying to work around
> marshalling, since you have made the choice that it should be
> marshalled. Be more bold and drop Entry, go with named attributes and
> see where it takes you.

I feel the type system matching that exists today needs to continue to be the 
primary service lookup for Jini.  It is what service lookup means when talking 
to "Jini" services.

If we wanted to provide lookup for another set of service types, and we want the 
ServiceRegistrar mechanisms to be used there so that non-jini clients do not 
care what the source of the service is, than it seems to me that there can be 
some duplicity of information made available in multiple formats in service 
registration so that each user can access the data which they need and find to 
be the most valuable for them.

I haven't really seen any other proposals (other than properties only), I'm just 
sharing what I've currently considered in my thoughts.

>> There are lots of things that I suspect the OSGi camp is only now
>> discovering to be necessary "evils".
> Perhaps... or not. I think the current stock of solutions are mostly
> WS-* related, and they just inherit the problems under the hood.

I'm not plugged into those conversations, so you are right, they may not be 
discovering anything new, or might not be after the same level of issues that 
I'm looking for solutions to be available for.

Did I shed any light on how I am thinking about things that might make you see 
something different about the two mechanisms?

Thanks for the continued conversation on these issues.

Gregg Wonderly

View raw message