Topic - Runtime Bundles for modularity and versioning
Status - Being discussed

Problem that we are trying to solve
Although we have SPIs defined in Tuscany, internals methods are not protected and can be referenced. We could improve quality and maintainability of the code by better enforcing modularity at runtime.

Tuscany provides various functionality. These features can be using similar third parties, but may require different versions. For example, the version of Saxon used by BPEL/Ode may be different than the one used for XQuery. There is a need to have different versions of third parties co-exist in the same runtime.

User
application developer, extension developer, Tuscany developer - It helps all these developers not to unknowingly create dependencies on internals.

Things to consider
The discussion for runtime bundles is different than distribution and packaging. Different distributions can contain the same bundles.

There could reasons why a developer would want to separate functionality into multiple modules even though these modules are never separated when assembling the larger aggregations (functional components and distribution packages). There are a few ways to handle this situation:

  1. Optimize the module split around developer convenience and let the basic module structure reflect this. This could create finer-grained modules than are needed to support necessary flexibility for the larger aggregations.
  2. Optimize the module split around the granularity that is needed to provide sufficient flexibility for the larger aggregations. This could create coarser-grained modules than are ideal from a developer perspective.
  3. Create an additional level in the hierarchy between maven modules and functional components. This creates confusion and complexity.

One possible approach is a combination of 2 and 3. Another approach is to use 1 in combination with a strengthened role for functional components (see functional components at runtime). There is emerging consensus around the latter option, assuming that we can agree a suitable breakdown of Tuscany into functional compoments.

Suggestion
Use OSGI to provide modularity and clean interfaces at runtime. OSGI also handles versioning.

Approach

  1. Map bundles to Maven modules that we have today.
  2. Aggregate these bundles into larger functional components that form the units of functionality selected by embdedders and Tuscany distributions. These users would not interact directly with the basic modules inside the functional components, or need to have any knowledge of what these basic modules are.

Next steps
Close the discussion on functional components at runtime

Questions to be answered

  1. Are there any cases where users (including embedders) would need to have knowledge of basic modules rather than just having knowledge of functional components?
  • No labels