river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Creswell <dan.cresw...@gmail.com>
Subject Re: MarshalledServiceItem
Date Tue, 01 Feb 2011 11:40:53 GMT
Ah, I know Sim is gonna hate this but I feel the need to retain full context
for now....

On 1 February 2011 10:55, Peter Firmstone <jini@zeus.net.au> wrote:

> Dan,
> I've appended the updated class after our earlier discussion,
> MarshalledServiceItem, now only has one method as suggested.
> An option is to consider giving Entry's their own jar files, and to
> consider doing something about providing a new codebase URL Handler, for
> separating identity from location, so we can discover the same jar files in
> other locations,

I don't think I understand the separation of identity from location fully
yet so let's try a framing statement:

A Service's ID and it's type plus some minimum set of Entrys to identify
pertinent service details is enough isn't it?. And any client wishing to
identify such a service would require those minimal Entry's (agreed it
mightn't want the others, could filter that at Lookup Service side such that
it never gets to the client thus doesn't need downloading).

I don't see the need to play marshalling games so much as delay opening up
the proxy and limiting the Entry's a client sees to those it declares
interest in.

> similar to Codebase Services with message digests or Maven Provisioning as
> suggested by Dennis.  This doesn't mean I don't support the idea that the
> best location for a codebase is at the originating service node, just that
> it's likely that many service proxy's could share identical jar files, so
> why should the client re-download something it already has?
But, if service proxy's are sharing jar files, what does that mean? Someone
somewhere chose to package them all together like that for some reason. What
reason, what problem are they solving?

Again, I'm sitting here thinking as a deployer of services, if I want to
widget around and consolidate .jars I can do that ahead of time and then
tweak service codebases via config just prior to deploy.

> Jini's lookup service lack of AND / OR querying capability is due to
> security, the avoidance of instantiating foreign objects.
> Delayed unmarshalling of the service proxy allows service entry's to be
> compared as objects, without requiring a codebase download for the proxy if
> it's not the service we want, so it's not quite just returning a
> MarshalledInstance.  This should be done without compromising the good
> security features of the existing lookup service.
I don't follow - I could tweak ServiceItem to hold the proxy as a
MarshalledInstance and still expose all other "service identifying
information". That MarshalledInstance mightn't even immediately carry the
proxy code, could still be on the server and pulled down at point the
consumer actually wants the proxy. Feels like some simple

> Over the internet, we could potentially have very large lookup services, by
> allowing clients to remove unwanted services from their results before
> unmarshalling, we can reduce the resources required of the client:
>   * Network Bandwidth, clients don't need to download unwanted codebases.
>   * Memory (ClassLoader and unwanted classes are not loaded into memory).
If we were to go across internet have we squared away use of e.g. DNS-SD?
i.e. Is it a given we'll expose a classic JINI LUS?

> The intent behind MarshalledServiceItem, is the entry's available for
> comparison are only those required by the client, these can be loaded into a
> child classloader (if they don't exist on the classpath) and shared by all
> MarshalledServiceItem instances.  You wouldn't require the Entry for a
> ServiceUI without it's service proxy for instance.
I think I get the intent but I'm far from convinced that all these
marshalling games and such are necessary (see above framing comment).

> After the MarshalledServiceItem has been unmarshalled, the Entry's can be
> from the classpath and the proxy's classloader (meaning we might need to
> unmarshall some Entry's a second time).
> I don't doubt the requirement for more efficient and flexible means of
> service lookup, just the interfaces so far proposed, which is why I'm giving
> it lots of time & hoping for plenty of review, before setting it in stone.
> The reality is the line between private networks and the internet is
> blurring, in spite of router NAT.  The internet is the market most ready to
> try different ideas like Jini / River, the corporate intranet is the least
> likely place and for political reasons more than technical ones.  I'd like
> to take River where it hasn't been, where there are no users at present to
> justify such a feature.
> Yeah I know there are other issues that need solving, like firewall
> traversal.
> P.S. Hope you're feeling better after the coffee ;)
Ops mess hasn't cleared up so alas, no :)

> Cheers,
Thanks for tolerating my rantiness!

> Peter.
> Dan Creswell wrote:
>> So...
>> On 1 February 2011 01:29, Gregg Wonderly <gregg@wonderly.org> wrote:
>>> One of the important things for my use of my changes to the
>>> ServiceRegistrar interface was separating deserialization of the Entrys
>>> from
>>> the service object.  Ultimately, I wanted to not have to worry about how
>>> the
>>> "codebase" was structured in order to minimize downloading. Some Jini
>>> deployers have done things to put a small jar at the front of the
>>> codebase
>>> that just has the preferred.list in it.  Even that download, for me,
>>> would
>>> have been too much.  My customers' deployments have nearly 50 codebases
>>> visible when my client starts up.  Those 50 connections over a cellular
>>> or
>>> other high latency network would make service selection take way too
>>> long.
>> "deserialization of Entry's from the service object"? What does "service
>> object" refer to?
>> I think you _have_ to worry about how the codebase is structured. Anything
>> else is a hack and if we're going to do hacks there are better ones like
>> bundling up people's .jars for them etc so save on connections/add caching
>> and such. Doing it further downstream in the lookup mechanism is treating
>> a
>> symptom not the problem. Not the sort of thing that keeps a design clean
>> or
>> consistent.
>> Being able to defer downloading was also controlled by the changes to
>>> ClassLoading to include the "neverPrefer" settings on a class name.  I
>>> can
>>> do that now through the recent RMIClassLoaderSPI override capabilities.
>>>  But
>>> I still need to be able to control which Entry is deserialized.  I need
>>> to
>>> be able to ask what classes, by name, are in the namespace of each Entry
>>> object as my implementation allowed. I had made changes to Reggie
>>> marshalling to use reflection to get the class hierarchy, and then
>>> provided
>>> access to the list of classnames as part of the returned, marshalled
>>> value
>>> in my API.
>> Digging through classes belonging to a service implementation that is
>> designed to be encapsulated/not your concern? Does that sound right? I
>> gotta
>> say, it sounds horribly invasive, very hacky and speaks of an overly
>> complex
>> solution as the result of treating symptoms, not problems.
>> Which brings me to a point Peter made elsewhere: "delayed umarshalling and
>> selective unmarshalling of Entry's are very important features, missing
>> from
>> River."
>> Important to whom? How many people are in the category?
>> If it's a lot of people, we should spend some time evaluating whether the
>> default class resolution/download/lookup approach is the generic norm and
>> potential replacements.
>> Simplistically, delaying downloading is as simple as returning a
>> MarshalledInstance on which one can then call .get as and when one
>> desires.....
>> Now, I haven't had my coffee yet and I've got a pile of operational
>> worries
>> to attend to this morning which means I'm maybe a little shout'y,
>> nevertheless I for one am not convinced of the value of this and less
>> convinced we have the right solution which feels complex, exceptional and
>> clunky.
> /*
> * Licensed to the Apache Software Foundation (ASF) under one
> * or more contributor license agreements.  See the NOTICE file
> * distributed with this work for additional information
> * regarding copyright ownership. The ASF licenses this file
> * to you under the Apache License, Version 2.0 (the
> * "License"); you may not use this file except in compliance
> * with the License. You may obtain a copy of the License at
> *
> *      http://www.apache.org/licenses/LICENSE-2.0
> *
> * Unless required by applicable law or agreed to in writing, software
> * distributed under the License is distributed on an "AS IS" BASIS,
> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> * See the License for the specific language governing permissions and
> * limitations under the License.
> */
> package org.apache.river.api.lookup;
> import java.net.URI;
> import java.security.CodeSource;
> import net.jini.core.entry.Entry;
> import net.jini.core.lookup.ServiceID;
> import net.jini.core.lookup.ServiceItem;
> /**
> * MarshalledServiceItem extends ServiceItem and can be used anywhere a
> * ServiceItem can.  A MarshalledServiceItem implementation instance
> * contains the marshalled form of a Service and it's Entry's,
> * the corresponding superclass ServiceItem however contains null values
> * for the service and can exclude any Entry's, however where Entry
> * classes already exist at the client, that they be unmarshalled.
> *
> * The ServiceID shall be in unmarshalled form always in the ServiceItem
> super class.
> *
> * Since the ServiceItem.service is null, use of this class in existing
> software
> * will not return the service, however it will not break that software as
> * ServiceItem's contract is to set service or Entry's to null when they
> cannot
> * be unmarshalled.
> *
> * ServiceItem's toString() method will return a different result for
> * MarshalledServiceItem instances.
> *
> * If required, a new ServiceItem that is fully unmarshalled
> * can be constructed from this class's methods and ServiceID.
> *
> * @author Peter Firmstone.
> */
> public abstract class MarshalledServiceItem extends ServiceItem{
>   private static final long SerialVersionUID = 1L;
>   protected MarshalledServiceItem(ServiceID id, Entry[]
> unmarshalledEntries){
>       super(id, (Object) null, unmarshalledEntries);
>   }
>   /**
>    * Unmarshall the ServiceItem.  The returned ServiceItem may have a null
> service
>    * or entries , if unmarshalling is unsuccessful.
>    *
>    * @return ServiceItem, totally unmarshalled.
>    */
>   public abstract ServiceItem unmarshall();
> }

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message