tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Raymond Feng" <enjoyj...@gmail.com>
Subject [DISCUSS] Tuscany modularity, composability and usability
Date Fri, 02 Oct 2009 21:28:37 GMT

We have been discussing Tuscany modularity, composability and usability over 
and over. There seems to be a lot of confusions as we use different terms, 
mix different goals and have different opinions. I would like to bring all 
the relevant items to the table and you can add your own. Let's try to agree 
on the following items one by one. After that, we can come up a plan and 
execute it against the current structure in a batch to avoid disruptive 

1) Terminology and target audiences

1.1 Module: A maven module in the build, a project in Eclipse, or a jar (or 
OSGi bundle) in the distribution. This is visible to Tuscany developers and 
those who wants to extend Tuscany or embed Tuscany.

1.2 Feature (or Profile): A mechanism to describe and package a set of 
related modules that can be used together for an offering. This is visible 
to Tuscany developers and those who wants to extend Tuscany or embed 

1.3 Distribution: A downloadable archive of an offering. Tuscany can provide 
all-in-one package and other smaller packages such Web Services, Web 20, 
Enterprise Java etc. This is visible to Tuscany end users. It should be also 
possible that a user unzips another offering into the existing Tuscany 

2) Key principles of Tuscany architecture

Tuscany is a composable platform that provides a set of modules and services 
that can be combined together to build an offering. Not all modules are 
required for all offerings. Tuscany is organized as a code base that we will 
use to build a variety of offerings. The Tuscany platform itself is designed 
to provide the common modules needed by many offerings and to provide them 
in a way that is reusable and generic. A specific offering (such as a 
Tuscany Node, Tuscany SCA Domain Manager or SCA Tool) would select a set of 
Tuscany modules it needs and then add a set of its own modules to provide 
the offering specific content. Applications (as defined by the offering) 
would then run on this collection of modules. Applications (and end user 
administrators) would likely also have some choice over which sets of 
modules are in use in a given environment.

The promises are illustrated in diagram at [1]. It shows Tuscany or other 
products can compose offering from the modules in different ways.


3) How to justify if two functions should be in the same module or separate 

3.1 Are the two functions (A and B) can be used independently?

   3.1.1 If A depends on B at compile time, then try to find out if another 
function C (inside or outside Tuscany) can use B without A. If such a 
function C exists, then A and B should be separate modules.
   3.1.2 If A depends on B at runtime, there is a good opportunity that B 
can be replaced by another implementation (like the stax-api and woodstox). 
We should have A and B in separate modules.
   3.1.3 If A doesn't depend on B, we should have A and B in separate 
modules unless they are both trivial and it won't add dependencies or 
footprint to have them in the same module.

It is very important to distinguish between "compile" and "runtime" 

3.2 Do the two functions belong to different layers?
    * Two functions should be in separate modules if they belong to 
different layers
    * If they belong to the same layer, then use the rules in 3.1.

3.3 Good ways to keep modularity
    * Don't use "compile" dependency unless it is required for compilation
    * Use Extension Point/Extension pattern via interfaces for cross module 
calls if necessary to avoid hard dependencies

4) How to describe a group of related modules to provide functional 
    * Maven pom and assembly descriptors to describe the dependencies and 
    * Maven profiles to enable the build for each offering

5) How to distribute a set pre-defined offerings from Tuscany?
    * For each offering, we use the maven assembly plugin to produce an 


Raymond Feng
Apache Tuscany PMC Member: http://tuscany.apache.org
Co-author of Tuscany In Action: http://www.manning.com/laws

View raw message