Just a few minor comments inline...
On Jul 19, 2006, at 6:33 PM, Jeremy Boynes wrote:
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.
One of the things we've been toying with (alluded to by Jeremy) is
the (optional) ability for the core to pull down extension
dependencies from maven repositories. This would be kind of like the
server equivalent to Eclipse's plugin installation.
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).
Dave, it would be good if you can also outline some of the use cases
you have in mind so we can make sure we cover them.
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
