Hi,
A few comments:
1) I think the term "componentization" is bit misleading here. By adopting
the SCA assembly to build the Tuscany kernel (system composite w/ system
components), we have componentized most of the key system functions. My
understanding is that we're talking about sub-modules in the kernel. There
are fairly isolated groups of functions in the core/spi which can be better
layered out to achieve more flexibilities for Tuscany embedders. If we look
at the system SCDL today, we already have a bunch of "include" statements.
It seem to be a good indication to me for more fine-grained assembly of the
kernel. For example, "databinding", "model", "loaders", "federation" can be
the candidates for sub-modules.
2) We ran into a case: The model objects are defined in "spi" which has
dependency on "host-api". To support the case that we need to pass some
model objects to host apis, we had to use generic "Object" to avoid circular
dependencies.
3) For models/loaders, one embedder might choose to use JAXB generated
classes and use JAXB to load SCDLs. Is it possible?
4) To my knowledge, we're putting together a discovery-based federation for
SCA domain. What if we want to support repository-based (for example, a SVN
repository or maven repo) SCA domain? Do we have the pluggability?
So far we have two levels of grandularity for the Tuscany kernel, a system
composite and a list of system components. I'm looking for smaller
composites which can be used to assemble the system composites based on the
embedder's intensions. Does it make sense?
Thanks,
Raymond
----- Original Message -----
From: "Jim Marino" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, March 12, 2007 12:00 AM
Subject: Re: Componentizing our SCA runtime kernel
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
