Simon Nash wrote:
Actually this isn't quite what I was saying. (Sorry that I wasn't clear.)
I'm talking about the lowest level components that we distribute as
binaries, not about larger groupings that are created from these components
to provide convenient aggregations of functionality. These groupings
might be useful as well, as you are suggesting here and Graham suggested
in his recent post.
So back to the basic components. I see no value at this level in breaking
things down any lower than a unit of functionality that might be included
or excluded as a whole from some valid scenario. To give an example,
I wouldn't put "everything related to Web services" in a single basic
component, because some users might want to create a minimal Web services
configuration without Web services security and/or Web services policy.
I also wouldn't put assembly and core in the same basic component,
because some users might just want the Tuscany model without the
Tuscany runtime. But I would put interface and assembly together in the
same basic component, because there are no cases where one would be used
without the other, and I would put core, core-databinding and databinding
together in the same basic component for the same reason.
Simon
Simon,
I'm not clear what components you are talking about here.
It seems to me that we have things are different granularities, for different purposes and for
different users, something like this (starting at the smallest):
a) Basic modules, as we have today.
These are largely for Tuscany developers, but they should represent a level
of development
independence.
Some folk (including me) believe that it is these modules that should be
OSGi bundles.
If there really is NO reason to separate functionality, then we should merge
modules at this
level. I don't think that is necessary at present.
b) A variety of functional components, that represent sets of coherent
functions.
Each consists of a series of the basic modules, aggregated together.
Their function in life is to assist developers of applications that embed
some level of
Tuscany capability (including tools, Tuscany itself and so on)
These are probably not agreed by folk today - we have work to do here to
define these.
You demonstrate the problem in your example above - you want "Basic Web
Services" separate from
"Web Services Security" - but for an end user, the step from using the first
to using the
second is a trivial addition of @required="integrity" to the SCDL.
Anyone care to have a go at defining these compoennts?
c) A small number of large packages aimed at supporting end users in a series
of environments and
with a specific set of functionality
Frankly, the average end user would prefer as few of these as possible. 1
is ideal.
However, I recognise that we are likely to have different groups of users
with different needs,
so that multiple packages are pragmatic - avoiding providing huge hunks of
unneeded code to users
who will never need them (eg no BPEL needed? - let's not have
implementation.bpel and its
humongous ODE 3rd party dependencies)
Jean-Sebastien has made a stab at these packages, and I think they are a
good starting point.
d) Simple ways of starting Tuscany fucntionality - based on using the packages
in c)
This includes a launcher (or launchers) and various forms of embedding of
Tuscany into other
runtime environments such as Tomcat, Geronimo (...pick your favourite
runtime...)
I'd like to ask folks generally whether they agree with this division. If we can agree on the
division, I'd like to see us write down the contents of each of a) b) c) and d) - ideally on some
nice Wiki page that we can maintain.
Yours, Mike.
