Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4BF46D30.4010808@zeus.net.au>
Date: Thu, 20 May 2010 08:58:56 +1000
From: Peter Firmstone <jini@zeus.net.au>
Organization: Zeus Project Services
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: river-dev@incubator.apache.org
Subject: Re: Codebase service?
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Dennis,

I like Gregg's ideas about *-dl.jar caching, it's obvious Gregg has had to overcome serious issues with bandwidth, this is also very relevant to the internet.

Why cant the client express a dependency on that associated service's -dl.jar file(s)?

The client depends on the Service Interface, not the -dl.jar, what you probably meant was Marshalled Objects depend on the -dl.jar during Unmarshalling.

Yours and Patrick's ideas are good, including the codebase Entry idea, as you suggest a Service could pre-empt installation of the correct version *-dl.jar prior to unmarshalling objects.  That *-dl.jar could have dependency's it requires resolved by a frame work too, all prior to any unmarshalling.

Dependency Tree:

           Service Interface
                    |
        ____________|____________
       |                         |
    Client                  Service Proxy  (Service-dl.jar)
                                 |
                             [ Remote ]
                                 |
                           Service Implementation  (Service.jar)


The Client has no direct relationships with the Service Proxy, if it did, we wouldn't be able to swap one service for another.

What makes this issue confusing for many is the Service Interface can find it's way into the *-dl.jar, however, in the case of smart proxy's it will usually be loaded previously by a parent ClassLoader.  If the Service Interface already exists at the client, the dumb proxy (reflective auto generated stub whatever you want to call it) doesn't even need a *-dl.jar

EG: River's Service Interfaces are in the jsk-platform.jar

I'd like to encourage developers to package their Service Interface's separately from their implementations, I'd like a way of indicating in a jar manifest, that the jar archive contains a Service Interface.  Then we could create a Directory Service that allow's users to find new ServiceInterfaces and lookup implementing Services, a ServiceInterface.jar should probably contain the LICENSE and javadoc too, to encourage other developers to implement it.

It makes sense to arrange ClassLoaders in a hierarchy similar to the dependency tree, if not utilising a Modular framework like OSGi.

These ideas are all good, lets keep having this discussion.

Regards,

Peter.