river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Codebase service?
Date Wed, 19 May 2010 22:58:56 GMT
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.


Mime
View raw message