DPML
DPML Central
HomeUtilitiesStationMetro
Freight Train
Observations
  1. speed
    1. FT is at least 300% faster than classic
  2. size
    1. runtime (composition layer) codebase is about 20% of classic
    2. buildtime codebase (type and component generator tasks) is about 70% of classic while packing a lot more functionality as class introspection is simply more efficient than javadoc tag handling
    3. note - auto-assembly functionality not included in FT
  3. impact
    1. buildtime validation is absolutely great - if something goes wrong is normally a build time error
    2. build exception reporting needs to be enhanced (not clear where an error is coming from when you have nested components
    3. runtime error reporting is good but on the other hand it feels a lot less important as a result of the strong buildtime validation
Issues
  1. logging manager
    1. transit or metro
    2. refactoring to use java.util.logging
  2. configuration and parameters
    1. some work remaining to be done
    2. safe to assume that config and params are immutable supply and forget artifacts (i.e. any runtime modification of a component would be through the context manager by the enclosing system)
  3. type and part viewers
    1. FT does not provide an XML view of a type or part
    2. can be addressed with a totally separate ant task - could be used to generate documentation about a component type and/or part automatically
  4. assembly logic
    1. all assembly directives are explicit
    2. need to add an assembly system in order to validate the explicit assembly instructions
    3. deployment and decommissioning ordering will be required when handling serialized models which in turn requires a deployment graph
  5. intergrate with Transit server mode
    1. Transit provides a server mode which triggers the setup of a reference transit instance. It is desirable to launch metro in server mode and direct cli requests to the remote metro instance.
    2. Server mode should be backed by an ant task that basically fires commands to a remote metro instance. Such a task could be used as part of a deployment test framework.
  6. a Manager inner interface
    1. Thinking is needed about a Manager inner interface within a component.
    2. Seems to be the right place for a component to publish instrumention info it makes available.
    3. Execution semantic are not currently handled.
  7. context manager development
    1. More trials with ContextManager are needed to sort some of the details out.
    2. Currently no validation on the ContextManager return type - but this is in effect a constraint declared by a container of the potential component that may be added as parts. This constraint needs to be handled as part of the component part creation task.
    3. Implementation of the context manager invocation handler needs more work - specifically, we need to clone the model context entries and resolved values into the per-instance context table enabling a complete context model view (current implementation just exposes the modified values).
  8. default parts creation and parts management
    1. Packaging of default part with a component (e.g. [classname].parts) is required.
    2. The <type> task needs to be updated to include the part association or we could put in place a .parts serialized object colocated with the class.
    3. Parts builders need to updated to load and check for pre-declared default part entries.
    4. The PartsManager is not currently implemented (however, it is expected that this will follow closely the general approach used for context management.
  9. integration between FT and classic
    1. Need to update system context to load FT by default in no deployment targets are provided.
    2. If the target is classic metro then bootstrap the classic composition otherwise bootstrap FT.
    3. With an FT manager we could wrap classic with a dedicated controller - we could also do the same thing for Avalon 4 but this needs to be demand driven.
    4. But ultimately would should be working on the assumption concurrent maintenance of classic and FT should be temporary and that final numbered build of classic should be a milestone target following which we would freeze the classic codebase and continue with FT as the Metro codebase.
  10. classloader handling needs to move down to transit
    1. FT contains a specialized classloader with debugging support.
    2. This should be moved down to Transit as part of the net.dpml.transit package.
  11. general observations on Magic
    1. get some experience in on using links in Transit/Magic/Metro
    2. rebuild magic's index/module as this is currently Magic's weakest link
  12. model serialization
    1. model serialization is not implemented yet
    2. serialized models is central to the delivery of continuations
  13. documentation
    1. FT makes most of our technical documentation redundant.
    2. New tutorials are needed and documentation updates are required across the board.
    3. Lots of opportunities exist for additional tasks the load parts and generate documentation automatically.
Recommendations

The next section address recommendations based on the current development status.