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.
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.
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.
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.
