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 (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. On May 20, 2010, at 324AM, Peter Firmstone wrote: > I like & get what your saying, I'd like to add something too. > > Can we separate the Service Interface from the Smart Proxy? So they're in > separate artefacts /downloadable jar's? > > Then the Client depends on the Service Interface artefact, but not the proxy > implementation-dl.jar artefact, leaving the Service to use any proxy-dl.jar > artefact it likes. (Via Entry) > > Then the Client chooses the ServiceInterface artefact, which dictates the > Service, while the Service implementation dictates the proxy artefact, for a > total separation of concerns. Both the client and Proxy then depend on the > ServiceInterface-dl.jar artefact, but not each other directly. > > If we don't grant ServiceInterface-dl.jar any permissions whatsoever and > place it in a Parent ClassLoader, then it can be visible to both the client > and the proxy, and the Proxy and the Client will be otherwise isolated from > each other, with their own permissions and avoid any risk of namespace > conflicts. > > That probably helps to make more sense of my previous message too. > > Once the required classes are in place, after the proxy has been > unmarshalled, the Remote calls marshalled streams can be annotated with the > ServiceID, so the client platform knows which classloaders to use. Why is this important? Why do you need to annotate the marshalled streams with the serviceID? > > The separation of concerns, the Service Interface, from the proxy > implementation, would allow us to provide a runtime dynamic service that > advertises available Service Interfaces, in a GUI browser, including Javadoc > for developers to discover and explore new and different Service Interfaces > as they are created. This might be useful for Groovy script developers too, > I might be getting ahead of myself here. Realize that if something like a maven repository is used you can browse available services as artifacts, which can also include source code, docs, etc ... Also, each of the conventions outlined above would manifest themselves as follows (as an example lets version 1 of use org.foo.bar.example): org.foo.bar:example:1.0 org.foo.bar:example:spec:1.0 org.foo.bar:example:dl:1.0 If I want to use the service as a client during development, I declare a dependency on org.foo.bar:example:spec:1.0
