On Mar 11, 2007, at 4:43 PM, Jean-Sebastien Delfino wrote:
I'd like to start a discussion on how we could componentize our SCA
runtime kernel. I posted two diagrams on our Wiki at http://
cwiki.apache.org/confluence/display/TUSCANY/Componentizing+our
+runtime to help start the discussion.
One of the ideas is to allow for different integration strategies
with app servers and other runtime environments. Some integrations
may reuse the Tuscany kernel as a whole, but others will want to
reuse only a subset or replace parts with specific implementations.
FYI we already support multiple host platform integration strategies
including JEE app servers, Maven, standalone, and J2SE. We should
also not have trouble running in an OSGi container.
A few examples come to mind:
- swap our POJO IOC container with another one already there in the
target app server;
Are you proposing we make our wiring infrastructure (IoC "container"
is a misnomer) substitutable for another or are you proposing we
support component implementation types that may be assembled using
other wiring engines, e.g. Spring? If it is the latter case, we
already have support with Spring. Integrating others such as
PicoContainer is relatively straightforward. If, on the other hand,
you are proposing to make our wiring engine swappable, I think this
will be problematic given the runtime and extensions are bootstrapped
using by it. If this is the case, perhaps you could explain what you
mean by describing in detail how the current process of assembling
the runtime and system extensions would be done? Will it reduce the
complexity of the runtime? Also, I would like to understand why this
type of major architectural change is worth it given the other work
people are currently engaged in.
- strip out the local assembly support when building a WSDL remote-
interface based (an SCA/BPEL container for example);
Sorry, I don't follow. What is "local assembly support"? Is it the
infrastructure that enables wiring between components that offer only
local services? If we did this then the runtime would not be able to
assemble itself or provide any extension support in its current form.
Such a runtime would also not be SCA-compliant as local services are
the default.
- strip out the federated deployment / discovery / distributed
wiring support when building a simple standalone runtime, or if
your app server already supports that and you'd like to integrate
with it;
Huh? If an app server already has support for SCA wiring or
federation, what would be the advantage of integrating with kernel?
FYI, Discovery is already in a separate module.
- replace the SCDL loaders if you're storing the assembly metadata
in a database instead of SCDL files;
You can already do that today.
- use a different handler/interceptor mechanism already in use in
your app server or a more dynamic invocation mechanism to support
scripting languages for example.
This I really don't get. If the infrastructure uses a different
wiring mechanism, the builders, policy, federation, components and
extensions will all need to be different. At that point, it's a
different runtime.
Also, what is "a more dynamic invocation mechanism"?
Another scenario I have in mind is to reuse parts of the Tuscany
kernel in validation tasks, codegen utilities, deployment and
management tools. For example I'd like to have an Ant task that
automates the generation of SDO or JAXB objects for an entire SCA
contribution.
This task will need access to the SCA assembly model, the SCA
contribution model, maybe our Interface contract model as well, but
I don't want to drag the whole kernel for that. Similar idea for
deployment and management tasks.
We've been over this ground many times before. If tooling can make
use of runtime classes that is great, but I don't think we should be
building our runtime around the demands of tooling implementations.
You may be better off here looking at Eclipse STP. If you can reuse
the kernel code, I believe it is about 500K which is less than a StAX
parser, as well as SDO and JAXB implementations :-)
A refactored/componentized kernel will also make it easier for
people to contribute to the individual pieces and exchange
components between our various initiatives.
We already have a "componentized kernel" - it is built from SCA
components. That is different than modularity.
For example I'd like to pull pieces of the trunk in the integration
branch, and it would be much easier if the single kernel/core
module was split in smaller independent modules (assembly model,
SCA contribution model, loaders, assembly wiring logic, invocation
framework etc...)
To help explore these ideas, I'm thinking about starting some
concrete work and try to pull some of the kernel code into
individual modules, probably start from the bottom of the stack and
have the assembly metadata and SCDL loaders in separate modules.
There's a lot of code, so I could use any help if people are
interested.
Thoughts?
I think your ideas would resonate and gain more currency if you made
concrete proposals, particularly if they took into account the
architecture we have in place and the current discussions related to
ongoing work. For example, we are currently working on support for
federated provisioning. Perhaps the existing kernel should be
modularized by separating capabilities related to the controller and
slave nodes?
What you have above lacks detail for me to thoroughly understand what
is being proposed or how it will benefit any of the work being done
in trunk. I see you have gone ahead and started experimenting with
this in the "integration" branch you set up. Maybe that is the best
way to proceed so we can understand what your specific proposal(s)
entail?
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
