river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Jini Spec API changes - ServiceRegistrar AND OR <> Entry comparison Filtering
Date Wed, 28 Apr 2010 20:20:14 GMT
Hi,

Have a look at the latest commit, while I haven't enabled anything other 
than exact matching for Entry's in Registrar, I have created some 
interfaces that:

    * Allows unmarshalling to be delayed by the client.
    * Allow selected Entry's to be unmarshalled for filtering, see
      MarshalledServiceItem, an abstract class that extends ServiceItem,
      see also StreamServiceRegistrar.
    * Created a new class that utilises multiple combinations or chains
      of  ServiceItemFilter filters, so these might be combined in a
      selectable user interface with AND OR logic.  Developers who have
      created ServiceItemFilter's over the years will be able to utilise
      them in new ways.  Filters that only compare Entries can be
      utilised prior to unmarshalling, those that require access to the
      proxy to apply MethodConstraints filters or Proxy Verification
      filters can be applied after unmarshalling.

I intend to enable very large result sets to be incrementally returned 
while also allowing filters and comparisons based on Entry's to be 
executed locally prior to unmarshalling the service, so that 
unmarshalling is reduced to the utmost minimum.

The existing Registrar unmarshalling semantics and proxy verification 
etc can be preserved, without exposing the implementation in River's 
Jini public API.

I would like comments from the Original Authors (if possible & time 
permitting), so that I can fully understand any implications of these 
changes.

These changes are intended to make it possible to implement lookup 
globally.  Result sets can be narrowed down significantly using 
filtering before unmarshalling and operations can be performed on 
batches of lookup results (services) that can be discarded after 
operation, allowing Garbage Collection to clean up de-referenced Class 
files and ClassLoaders during ongoing lookup result processing, while 
removing unnecessary codebase downloads. 

I'd also like to further reduce codebase downloads by allowing packages 
and codebases to be shared based on package versioning.  Security 
implications are that a codebase would have to be signed by a trusted 
party, treated separately from the service, which might need to 
authenticate itself if required by the client, I don't know how to 
enable the Service to specify a constraint on the signer of the 
downloaded codebase if not originating from the service, any ideas?

Note that this implementation is intended to not break backward 
compatibility.

Best Regards,

Peter Firmstone.

Mime
View raw message