Migration path from current monolytic application to a decentralized block system

The goal of this evolving document is

  1. providing a migration path from our current monotlic application and
  2. to find out what we have to do on the Cocoon side (see BlockManager, component lookup, block protocol)

This is written without having it discussed with Pier - so possible classloading issues are not considered. His input is very appreciated :-)

Component management in general

Sitemap & Source resolving

O/R-mapping

O/R-mapping tools have some kind of super factory that does all the persistence stuff (object creation, updating, deleting, ...). Used in combination with blocks this means that the metadata are spread over blocks and they are not at a single place.

As there might be dependencies between objects of different blocks, this super-factory has to be configured using all the metadata files of the different blocks. It should be possible to replace the base implementations of those super-factories by an own implementation that has access to the BlockManager that has access to the metadata files.

Another option would be that every block registers its o/r-mapping files at an super-factory-metadata-registry.

This way O/R-mapping relies on the "feature" that all classes put into the public JAR of it, can be accessed from other blocks.

Logging

Any implications on logging because of blocks?

Kernel implementation - or: How do he things described above fit into the current design of kernel?

Here input by Pier would be *very* helpful.

Backwards compatibility

22BlockImplementation (last edited 2009-09-20 23:40:15 by localhost)