Since Maven Artifacts don't allow a URL to be used to uniquely tie the
Codebase to a location, specific to a particular service, we need
another way to prevent different Services from sharing the same
Namespace and to determine which ClassLoader to use for the Service.
I propose we create a new ClassLoader, perhaps called ProxyClassLoader,
that contains the Service's Principal for smart proxy's
This Principal can be used in equals comparisons for ProxyClassLoaders
with identical CodeSources.
The incoming remote thread's Subject can be queried for the Service's
Principal to assist in determining the correct ProxyClassLoader.
Furthermore, the Public Key Certificate can be used as the name for the
Service Principal in large distributed environments.
However there is one more thing I realised, that is Services with
identical signatures (from the same Subject), may serve up different
proxy versions. A ClassLoader can only contain one instance of two
separately versioned proxy CodeSources, this also applies to any
additional CodeSources the proxy depends on, that are also loaded into
the same ClassLoader.
So the other thing that identifies the ClassLoader is the version of the
proxy CodeSource and any additional CodeSource dependencies. Preference
should be given to the proxy version.
Different Proxy versions should have their own namespace (ProxyClassLoader)
Application classes shouldn't be visible to the proxy, only the Service
API, Jini and Java Platforms. (To minimise security risks from
application developers).
Since the locally installed Service API doesn't change, all instances
communicate using the Service API, Jini and Java platform classes.
Thoughts?
Regards,
Peter.
Dennis Reedy wrote:
On Aug 26, 2010, at 725PM, Peter Firmstone wrote:
Yes, thanks Dennis, that's what I was trying to say ;)
Seeing as we've touched on Maven again, is anyone with some Maven experience
able to help out with an implementation of Maven Provisioning of proxy jar
artifacts. Seeing as everyone is starting to do this I'd like to see a
standard way adopted. The proxy jar's can themselves depend on other Jar's
since maven can provision those. By provisioning artefacts, it reduces the
risk of denial of service.
I dont think we should be concerned about this right now, furthermore, this is
generally out of scope [1] for what I think River should be focusing on now,
and for the foreseeable future.
What would be more helpful is conventions on how developers that use River and
Maven should create their projects. We have had discussions on this in the past
(so this is mostly a review), I hope that we can agree on the conventions,
document them and eventually create a River archetype that generates a default
project structure that produces the requisite artifacts.
We had started out using a Maven-ized classdepandjar
(http://www.rio-project.org/classdepandjar-mojo.html), allowing the creation of
multiple artifacts from a single project (service.jar, service-dl.jar,
service-ui.jar, etc....). While this worked, the pom became overly complicated,
the approach became confusing, especially if one of the artifacts had
dependencies that the others didnt.
What we have moved to (and I think this is common across other developers) is
to create a multi-module project that reflects the basic architectural elements
of a River service. Basically, a River service is composed of the following
modules:
some-service\
api\
*proxy\
*ui\
service\
* = optional
The api module contains all the classes (interfaces and other classes) that is
needed to communicate with the service
The proxy module (optional), depends on the api module, and provides smart
proxy support
The ui module (optional), depends on the api module and provides support for a
service user interface
The service module, depends on the api module (or proxy module if used) provides the backend service implementation.
Using this approach produces an easy to use and understandable model, doesnt
require classdepandjar, and dependency management is handled quite cleanly.
Some will argue on the names of the modules, it doesnt really matter what the
names are, as long as the project has its constituent elements broken out.
Maven groupId and artifactId conventions we adopted are as follows:
com.foo:some-service:version
com.foo.some-service:api:version
com.foo.some-service:proxy:version
com.foo.some-service:ui:version
com.foo.some-service:service:version
Additionally, if I wanted to use a service (as a client) I would declare a
dependency on com.foo.some-service:api:version
I hope this helps, and I do think if we can agree on conventions like this,
document them, and produce a simple example that uses them, it will help
developers use River and Maven.
Dennis
[1] Higher level frameworks like Rio have this capability.
