Maven Artifact's [Was]: Closing out release 2.2.0

[Peter Firmstone <ji...@zeus.net.au>]

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. 
>
>
>