river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Reedy <dennis.re...@gmail.com>
Subject Re: Codebase service?
Date Thu, 20 May 2010 16:01:08 GMT

On May 20, 2010, at 1136AM, Greg Trasuk wrote:

> Hi all:
> See comments interspersed...
> On Thu, 2010-05-20 at 11:05, Dennis Reedy wrote:
>> So this is what I'm understanding thus far:
>> Extend the jar conventions of service construction to include:
>> Implementation jar: service.jar
>> Specification jar: service-spec.jar
>> Download jar: service-dl.jar
> That's way I've been doing interfaces for years, except I call it
> 'service-client' rather than 'service-spec'.  Same thing.  The client of
> a service compiles against 'service-client.jar', which contains only the
> interfaces and possibly any classes used in parameters and return values
> on the interfaces.  Then the 'service-dl.jar' (containing things like
> smart-proxy code if there is any), along with 'service-client.jar' is
> included in the service's codebase annotation, and the 'service.jar' is
> used by the implementing container for the private implementation. 

Yep, this would just formalize what you're already doing.

> Along the same lines, I've always made it a habit to declare service
> methods to throw IOException rather than RemoteException, so as not to
> impose any dependency or implication of the RMI protocol.  Since
> RemoteException extends IOException, an RMI implementation compiles and
> works just fine, but the client doesn't then depend on RMI.

Good idea.

>> (I would love to see the jars also follow the convention of including the version
number as part of the jar name, makes it clearer what is being used. Not a mandate, just a
>> Clients would include direct dependencies on service-spec.jar, including that jar
as part of it's own classpath, and would also be able to provision the service-dl.jar. The
service-dl.jar has a dependency on service-spec.jar (but not the other way around), as does
the service.jar. Note that service-spec.jar may be project wide (like River) and include service
interfaces (specifications) for multiple services, or it may be service specific.
>> Provide a ServiceDLEntry (implements ServiceControlled) that includes the DL jar(s)
and accompanying message digests for the jar(s) allowing clients to optionally download and
install DL jars to avoid expensive http(md) based class loading. 
> Assuming that Reggie has to unmarshal the proxy in order to return the
> service item which includes your ServiceDLEntry, you could probably
> accomplish the same thing by creating a class loader that maintains a
> persistent cache of jar files.  Either way, you're going to download the
> jar file at least once,

Good point. 

View raw message