Niclas Hedhman wrote:
On Tue, Jul 28, 2009 at 3:19 AM, Gregg Wonderly<[email protected]> 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.
I said a lot of different things in different ways that didn't help me make the
point, sorry for that.
1. You can't take the existing LUS mechanism and extend the API for
registration without making something visible in lookup.
2. You can't take the existing, marshalled values, and unmarshall them to look
at "strings" or other "data" for matching, so the new registration data has to
be represented as a "special" case and not part of what already happens.
3. Specialization can happen by using method signature changes, special Entry
types, or by layering lookup into something that uses the existing mechanisms in
ServiceRegistrar, but does something with the registration data.
For example, what if we created maps for each Entry that were
"com.my.company.package.EntryClass.fieldName" ==> "The string value"
for all fields that were native types? If we then transported that data
inside of the existing MarshalledInstance as separate data that was made
available on (my reef impl's) ServiceLookup interface, then a new RFC-119 lookup
could be implemented by looking for ServiceLookup on the ServiceRegistrar proxy,
and then getting the map of values and doing string comparisons.
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.
I believe that neither side really had any productive conversations other than
"why don't you do XXXX it's what we need to integrate these technologies".
We needed to have the "why did you do it that way" conversations to help
everyone appreciate each others perspectives.
Supporting RFC-119 means we need a new lookup mechanism that doesn't cause
unmarshalling. I have in mind one way to implement that on top of reggie so
that existing service registrations don't have to change what the do, only what
version of reggie they register with.
The use of type based lookups and supporting a new API for string based lookups
with expressions etc doesn't mesh well with marshalled data unless you segregate
what should be used from what is not interesting. Jini Entry objects can have
very complex values in them, and unmarshalling is the "most robust" way to see
those types for "user code". For the Reggie internals, the details are more
visible because of how the "MarshalledInstance" is created. Exposing those
details in a way that doesn't cause "downloading" or "unmarshalling" (which can
lead to codebase contamination because of local class uses) is what is left to do.
Gregg Wonderly
