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 Wed, 02 Feb 2011 00:11:49 GMT
Dan Creswell wrote:
> 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.
>   

Clarification:  Separate the location and identity of a jar file or 
archive containing class files:

We have integrity constraints, which rely on message digests to confirm 
files have not been tampered with.

The message digest (although now considered a weak form of encryption), 
is the identity of a jar file, well we use this type of information to 
identify it's the jar we expect.

For httpmd, we use a URL string annotation (which could be an IP address 
and port, or a DNS hostname and port), a path and file name, followed by 
the message digest.

The IP address or dns hostname , port and path represent the location of 
the jar file, while the file name and message digest represent it's 
identity.

If we separate the location + port, it can be discovered using DNS-SRV 
records, allowing redundant codebase servers, while the identity is 
limited to the file name and message digest.

Then the RMI codebase property only needs to be a domain in which a 
suitable codebase can be discovered and queried.


>
>   
>> 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?
>   
Deployment reasons.

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

But it would be faster for the client to receive unconsolidated jar's, 
since other services might use some of these jars also.

What matters is the proxy gets the correct class files, in its own 
private namespace that are not shared with other proxy's (except for 
service api, which may include Entry's), but we can save duplicate 
downloads.

Maven provisioning is interesting.

This is why I'm interested to investigate separating jar file identity 
from location, to simplify deployment and redundancy.  I'm putting my 
thoughts out on the list, to gather responses, to see if there's a 
better way.

>
>
>   
>> 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
> interface/sub-classing.
>   

This is true for cases where the service types don't matter to the 
client, I think Gregg wanted to elimate all codebase downloads until he 
was sure he had the correct service. Use of a MarshalledInstance could 
be an acceptable compromise, if Entry's have their own codebase 
annotations.  How would this affect the lookup semantics if we're 
looking for particular service types though?

>
>
>   
>> 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 semantics of DNS-SD make it well suited to discovery of a lookup 
service.  I think Sim highlighted earlier that its difficult to get 
domain administrators to do Dynamic Updated DNS-SD, they're comfortable 
with DNS-SRV records, so it would appear easier to rely on DNS-SD as a 
lookup locator / domain browser, not as a lookup service replacement.

Cheers,

Peter.

Mime
View raw message