Hi Michael,
That would be very much appreciated.
Best Regards,
Peter.
Michal Kleczek wrote:
On Thursday, 23 of July 2009 06:11:01 Peter Firmstone wrote:
HTTP codebase's are part of the problem, the URLClassLoader is fixed in the
object's Type (class identity), which may change over time. Michael Warres
addressed this problem by creating a dynamic codebase service where the URL
was a cryptographic hash of the jar file (stored data) identity.
Michael made a presentation on Service based codebases, apparently not
much code was required to implement it. We cannot directly copy the
code (interfaces etc) from the presentation due to copyright, although
we can produce functionally equivalent code.
http://www.jini.org/files/meetings/eighth/presentations/Warres/Warres.pdf
We have implemented a similar solution in XPro.
The main difference is that in our implementation there is no "put" operation
in a ContentAddressedStore interface. In other words:
1. Each service publishes a separate ContentAddressStore and becomes its own
codebase server.
2. You can run specialized services that cache resources from other
ContentAddressStores to achieve HA
3. Optionally you can configure the services to act in a P2P fashion - the
resources downloaded by a service are also published.
The main motivation behind this was to be able to run services with minimal
dependencies on other services being available on the network.
After resolving some licencing problems (which should not be very complicated
I think) we could contribute this code to River.
Thanks,
Michal
