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. As such, multiple service implementations can use different smart proxy implementations as desired, or not. I believe that was what Jim Waldo was getting at with "The End of Protocols"; the client only knows about the interface, then downloads whatever proxy implementation the particular service dictates (and registers in the registrar), which might be a smart proxy or a plain proxy to implementation using whatever protocol it wants. I actually thought that was common practice, as I didn't imagine I was bright enough to have thought of it myself. 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. > (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 nicety) > > 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, then you avoid downloading it again just to see the service. It's a different story if you can unmarshall the proxy lazily, as per Gregg Wonderley's stuff. Cheers, Greg. -- Greg Trasuk, President StratusCom Manufacturing Systems Inc. - We use information technology to solve business problems on your plant floor. http://stratuscom.com
