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.
Cheers,
Peter.
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.
