Comments inline ...
On Jul 19, 2006, at 5:20 PM, scabooz wrote:
Jeremy (and others of course),
There have been a few recent threads that have touched on the
various aspects of how Tuscany might be imbedded in a larger
runtime environment. At least Jeremy is already starting to form
a mental model of what that should look like, so I'm wondering
if someone could elaborate more in general about what you're
thinking. Questions like the following come to mind:
1) Is there a distribution for imbedders?
There might be a more fundamental question here: what's a distribution?
For M1, we focused on a end-user distribution, by which I mean
something someone could download, unpack and everything that they
needed to run Tuscany would be there. As a result it ended by a bit
kitchen-sick like containing, for example, Tomcat, Axis2, Celtix,
etc. and ended up just a tadge under 50MB in size. I don't think this
will scale as we add more functionality.
I would suggest that we continue to produce distributions aimed at
end-users but tailor them to particular runtime environments.
Specific ones that come to mind would be a simple client, one with
Tomcat, one with Celtix, one with Equinox, one with Geronimo, and so
on. These may include the environment (like we did with Tomcat in M1)
or they may packages that can install on top (e.g. as a CAR for
Geronimo).
Each one of these would be tailored for the runtime - for example,
the Tomcat one would be web-oriented, the Celtix one message-
oriented. The baseline distribution could be extended by adding in
plugins that would be distributed separately. This is a similar model
to e.g. Eclipse, Maven, etc.
We would also distribute each module from the build through the Maven
repository system. During incubation, all artifacts would be
available from the Apache snapshot repository; post-incubation,
released artifacts would also be available through the mirror system
(e.g. from ibiblio.org).
Someone looking to embed Tuscany could go about it in a couple of
ways. One would be to start with one of our distributions, take it
apart and integrate it into their environment. This would have the
advantage that all artifacts would have been tested to work with each
other but may mean that they are dependent on more than they need or
that they would have to wait for a full release to get fixes etc.
Alternatively they could work directly with the artifacts from the
maven repo. In trunk we are now using the maven assembly plugin to
build the distribution and it would be trivial for someone to
assemble a different distribution just be reconfiguring that plugin.
2) Is the runtime config mechanism extensible enough?
It's based on the SCA config mechanism so I hope so - otherwise we
will have valuable feedback for the spec ;-)
The runtime is constructed by deploying a SCA component implemented
by an SCA composite (which contains other SCA components). Which
components are present are determined by the content of the composite
and they can be configured in the same way any component can
(including via xpath expressions once we get complex properties
working).
3) Is the build modular enough to only build the pieces you want to
imbed? I saw some posts on modularizing the build
that seemed useful.
At this point probably not - for example, in order to work around the
issues building JAXB Meeraj had to hack a couple of the pom files and
that is not very desirable. As you said there have been a couple of
posts on making the build more modular and it may be better to
continue on that thread.
4) What's the right way to think about Tuscany in relation to a
hosting environment? Is it always imbedded or are there use
cases where server function in imbedded in Tuscany?
I consider the "core" to be the bit that is always embedded in some
host environment, with the core being the bit that provides the SPIs
and the framework for running system services. The host is
responsible for bootstrapping the basic runtime and for determining
which services will be started. Such services will include things
like programming models, bindings and policies as well as normal
application components.
Different hosts will start different services depending on what type
of host they are. Some may just be clients, some may start "server"
services in Tuscany and some may start "bridge" services that
transfer function between the host and the Tuscany runtime.
...there's many more questions...
We probably should work on a guide for embedding Tuscany with more
information on the bootstrap APIs. So, ask away so we can get the
right information there and tidy up the JavaDoc.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
