Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4B7531DA.20504@zeus.net.au>
Date: Fri, 12 Feb 2010 20:47:54 +1000
From: Peter Firmstone <jini@zeus.net.au>
User-Agent: Thunderbird 2.0.0.14 (X11/20080531)
MIME-Version: 1.0
To: river-dev@incubator.apache.org
Subject: Re: Dependencies - The Good, Bad & Ugly & Future Possibilities
References: <4B73743D.6050208@zeus.net.au> <4B739FD7.4010805@qcg.nl>
 <c5dcc791002110139uf3a8fc2sdfd93ae69a15b94c@mail.gmail.com>
In-Reply-To: <c5dcc791002110139uf3a8fc2sdfd93ae69a15b94c@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Tom Hobbs wrote:
> Maybe off topic, maybe not...
>
> Is there any mileage in setting up a River services repo.  Sort of link most
> Linux distributions have know sites and mirrors where you can browse for
> applications and receive application updates.
>   

Yes, I think that's a good idea.

> Think of "normal" HTTP/S codebase servers, service interfaces could be
> published there (somehow) and users can elect to download new versions of
> services as and when they become available.  Obviously, setting and managing
> the hosting of services would be expensive so we would only host the lookup
> services.
>   

We'll we could use an event notification service for updates?

The beauty of a new URL implementation would be the opportunity to 
discover the codebase location by the codes identity, rather than it's 
location, since that is likely to move over time, it also allows the 
opportunity to replicate the codebase servers cheaply with alternate 
services.  The code signer can be used to determine whether we trust the 
code.  Then we need to work out if we can trust the service, that must 
be based on the Principal of the Service.

> It raises an interesting (I think) question of if our lookup services trust
> the provider of the service, and the client code trusts our lookup service,
> can the client code implicitly trust the proxy we refer it to?
>   

Very true, there are some interesting and difficult trust implications, 
we need to think out.  Whether we decide to require the lookup service 
trust a Service provider? I'm not entirely certain, there's not such 
thing as a stupid question in this context.  Currently there is no such 
notion of trust, the ServiceRegistrar never unmarshal's a proxy, rather, 
it's the service that must trust the ServiceRegistrar (lookup service) 
because it runs the lookup service's proxy.  

Currently code originates from an httpmd codebase as advised by the 
Service Provider.  In all cases the code must be signed by someone 
trusted by the client, and marshaled state must be over secure 
channels.  The Service (a client to the lookup service) might require 
the lookup service principal to authenticate itself, I'm not sure, I 
thing these are valid questions and need more thought.

If we attach some Metadata in MarshalledObject that advised of the 
version and signer of the code the Service requires, then allowing the 
client to retrieve that code from where ever it pleases (the client 
might need a different signer to the Service).  During Proxy 
verification, the Service will get the opportunity to Verify it's 
unmarshalled Proxy, before the client can grant permissions to the code 
and the Service.

This would allow us to cache code anywhere around the world, in any 
codebase,  so code downloaded from one side of the world to the other 
would only do so once, potentially.

If cached code becomes outdated, we can tell from the MarshalledObject 
version metadata, the client could expand its search for the code in 
other codebases outside the local domain. The MarshalledObject might 
contain the preferred location of the code, however the client should 
check locally first.  Once we have verified a signer on code, we might 
upload it to our local codebase server or perhaps the codebase server 
could retrieve it for the client, that might be the preferred option.

I think these things will become clearer as we try to implement.

Cheers,

Peter.

> On Thu, Feb 11, 2010 at 6:12 AM, Sim IJskes - QCG <sim@qcg.nl> wrote:
>
>   
>> Peter Firmstone wrote:
>>
>>  The bad news is that ClassLoader's are memory hungry, so we'll soon
>>     
>>> run out of both network bandwidth and memory when downloading
>>> multiple duplicate codebases all providing similar services.
>>>
>>>       
>> How would an internet deployment work in practice? When you use a
>> service you need to know its interface. So how many interfaces are we
>> going to standardize? And those services are they similar, or the same? The
>> only benefit to service proxies would be to distribute an updated version,
>> or when its a big one that you only keep it in memory when you use it (and
>> i'm not sure classloaders easily give up codebases).
>>
>> Code needs to be deployed anyhow. Once at installtime, or when there are
>> updates, or with every invocation of the program. We have 'downloads', java
>> webstart, jini. With every step we gain extra agility(?). What real
>> scenario, use-case are we facilitating here?
>>
>> Shouldn't we make a few usecases and maybe create a few personas, so we all
>> get a feel for what problem we are solving here?
>>
>> Gr. Sim
>>
>> --
>> QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
>> Quality Consultancy Group b.v., Leiderdorp, Kvk Leiden: 28088397
>>
>>     
>
>