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.
