Niclas Hedhman wrote:
On Thu, Jul 23, 2009 at 1:29 AM, Gregg Wonderly<[email protected]> 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
problems.
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
important.
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
