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: Jini Spec API changes - Design Decision
Date Sun, 02 May 2010 05:39:31 GMT
net.jini.core.lookup.ResultStream<T> is a simple interface for 
simulating an object stream, it has two methods

T get(); returns one object.
void close(); allows the implementer to close any resources, threads 
file handles, remote objects, etc before the user nullifies the reference.

There's are new utility classes too (pseudo code):

net.jini.lookup.ServiceResultStreamFiler implements 
ResultStream<ServiceItem> {
    // Constructor:
    public ServiceResultStreamFilter(ResultStream<ServiceItem> rs, 
ServiceItemFilter[] sf)
    public ServiceItem get()

Unlike ServiceDiscoveryManager's use of ServiceItem[] arrays for return 
results, ServiceResultStreamFilter allows you to chain multiple filter 
implementations to the results from StreamServiceRegistrar.

Some filters, may just allow through those ServiceItem's with a desired 
set of method constraints, such as utilising a secure communication. 
Other filters might only be allowing the services with a greater than 
method applied to an Entry attribute.

Chained filters represent AND statements, while nested (those passed 
into the constructor) filters represent OR statements.

This utility class only concerns itself with unmarshalling any 
MarshalledServiceItems in the ResultStream, any unmarshalled 
ServiceItem's pass through untouched.

net.jini.lookup.ServiceResultStreamUnmarshaller implements 
ResultStream<ServiceItem> {
    public ServiceResultStreamUnmarshaller(ResultStream<ServiceItem> rs)
    public ServiceItem get()

Previously a ServiceFilter only had one bite of the cherry, so different 
concerns had to be combined in one filter, now your Entry filters need 
not be tied to your constraint filters, constraint filters can be shared 
among many lookup queries, and other operations that might query the 
service directly can be performed after all the other filters have been 
applied so unmarshalling is reduced to the bare minimum.

Oh you can utilise all your existing filters too.



Peter Firmstone wrote:
> When I wanted a way of returning marshalled or semi marshalled 
> ServiceItem results from StreamServiceRegistrar, I chose to extend 
> ServiceItem, and add two methods:
> Object getService()
> Entry[] getEntries()
> I called this class MarshalledServiceItem.
> Here's a new method from StreamServiceRegistrar:
> ResultStream<ServiceItem> lookup(ServiceTemplate tmpl,
>        Class<? extends Entry>[] unmarshalledEntries, int maxBatchSize) 
> throws RemoteException;
> The array of unmarshalledEntries is to request these entry classes be 
> unmarshalled and available in ServiceItem.attributeSets.
> ServiceItem.serviceID is always unmarshalled.
> ServiceItem.service is null, if delayed unmarshalling is supported.
> I chose to make MarshalledServiceItem abstract, the reason: 
> ServiceItem implements Serializable, which would cause the Registrar's 
> implementation to be published in Jini's API, so while 
> MarshalledServiceItem extends ServiceItem, none of its methods are 
> mutator methods and only return the unmarshalled service and complete 
> Entry's.
> I have another utility class that constructs an unmarshalled 
> ServiceItem, from MarshalledServiceItem.
> Check out the code.
> Cheers,
> Peter.

View raw message