river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patricia Shanahan <p...@acm.org>
Subject Re: Towards Internet Jini Services
Date Thu, 30 Sep 2010 21:25:52 GMT
Peter Firmstone wrote:
> Zoltan Juhasz wrote:
>> Peter,
>>
>> I am (has been) interested in the Internet use of Jini. There are many
>> issues as you have noted below. More fundamental is the model of 
>> interaction
>> between services. Way back I was trying to talk about these issues in a
>> London Jini Meeting perhaps without much success. There are two main 
>> schools
>> of thought in service interaction; API vs messaging (aka document) based
>> models.
>> Messaging relies on a relatively simple send/receive interface, the real
>> thing is the content. Services are meant to be intelligent enough to
>> interpret these messages and deal with them accordingly. In the 
>> networking
>> world (and also in the Jini community) this is referred to as the 
>> world of
>> protocols. My personal belief is that these only work for simple and
>> well-defined services like ftp and the like. If you ask agent people they
>> will say the opposite I suppose.
>> The API approach that Jini takes requires up-front design work and 
>> same say
>> these systems will inherently be brittle. I think versioning is a 
>> problem in
>> both approaches.
> 
> Versioning - Service API is like an Interface, once it is widely in use, 
> it cannot change, the implementation can, but the API cannot, since it 
> is installed in the client.
> 
> However we can extend service API, just like we can extend an Interface.
> 
> Then, new clients utilise the extended Service API, while old clients 
> continue to use the original, I've suggested the extended service API 
> jar archive previously, but it's also possible to add any new API 
> classes to the proxy download codebase. In the old client it will be 
> loaded with the proxy's ClassLoader, but not utilised (unless the 
> Service UI uses it), but the new interface won't be loaded by the proxy 
> ClassLoader at the new client, because the new client has already loaded 
> the extended Service API, in a parent ClassLoader, since new clients are 
> compiled against the extended API.

The mailing list lambda-dev@openjdk.java.net contains discussion of
"defender methods", which are intended to make it possible to specify a
default implementation for an interface method. A class that implements
the interface without supplying an implementation for the interface
method would use its default implementation instead of being treated as
an error.

With that in place, it would be possible to add a method to an interface
as long as it can be given a default implementation, without resorting
to a new extension.

Does that have any effect on River direction? Do we want to aim for
similar flexibility?

Patricia


Mime
View raw message