river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: MarshalledServiceItem
Date Tue, 01 Feb 2011 10:55:41 GMT

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, 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?

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.

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).

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.

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 

P.S. Hope you're feeling better after the coffee ;)



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,
 * 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 
 * 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 
 * 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[] 
        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();

View raw message