Raymond Feng wrote:
Hi, Mike.
It's a very good summary. The different perspectives are now well
separated and they should be discussed on different threads to avoid
further confusions :-).
Please see some more comments inline.
I added a couple of responses on specific points below.
Simon
Thanks,
Raymond
--------------------------------------------------
From: "Mike Edwards" <[EMAIL PROTECTED]>
Sent: Friday, June 13, 2008 2:08 PM
To: <tuscany-dev@ws.apache.org>
Subject: Re: Tracking Tuscany extensions, was: Distribution zips and
what they contain, was: SCA runtimes
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.
+1. The OSGi bundles are the basic units to constitute the tuscany
runtime and they formally defines the SPI contracts across the modules.
Maven modules are the static/structural reflection of the same idea.
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 aggregrations at the b) and c) level. I see 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 by the b) and c) levels.
2) Optimize the module split around the granularity that is needed by
the b) and c) levels. This could create coarser-grained modules than
are ideal from a developer perspective.
3) Create an additional level in the hierarchy between the a) and b)
levels as defined here. This creates confusion and complexity.
I have been arguing for some combination of 2) and 3). As a result of
this discussion, I'd like to explore the alternative of using 1) in
combination with a strengthened role for the b) level. This might
provide the advantages of 2) and 3) without their disadvantages.
So I'd like to suggest that we try to make progress at the b) level
first and come back to the a) level when we know what the b) level
looks like.
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?
What physical representations of this layer? A library/collection of
bundles like Eclispe feature?
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.
+1. This is about physical distributions which pick modules from a) and
package them into archives to be downloaded/shipped. We probably just
have to agree on this idea in principle. And we can tune the various
combinations over time based on user feedbacks.
I would expect these to be based on a combination of components from b),
with duplicate modules eliminated, not on custom combinations of modules
from a). If we can't build these packages by aggregating b) components,
this would indicate that we don't have the right groupings at the b) level.
Simon
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...)
+1 this is about platform or hosting environment specific deployment and
launching.
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.
+1 to have a wiki page.
Yours, Mike.
