I think this is a direction worth exploring. As Jim says, we need to
develop these thoughts in more detail to understand the benefits of
making these changes. A useful way of doing this would be to look
at some use cases and see how the current design handles these, and
what would be different with a restructured/modularized/componentized
kernel.
I think it's also useful to prototype some of these ideas to put
more substance around the proposal. The prototyping could be done in
the "integration" branch (I wasn't quite sure if Sebastien was
proposing this), or in some other place.
I've added a few comments inline below.
Simon
Jim Marino wrote:
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.
We need to deliver downloadable packages (profiles) that make it easy
for users to do this. Some users of these host platforms may want to
expose their existing components using SCA, and others may want to
develop "native" SCA composites and deploy them onto the host platform.
The second usage requires more SCA functionality than the first, and
we might want to consider separating the functionality needed for
these scenarios.
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.
I'm interested in exploring this in more detail as well. I understand that
the wiring infrastructure is currently needed everywhere because of the
runtime's dependency on it. For integration scenarios where the only purpose
of the wiring infrastructure is to support the SCA runtime itself, I think
it's valid to consider whether there are other alternatives.
- 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.
Different integration scenarios will require different parts of the SCA
specs to be supported. The more flexible we can be with how these
capabilities are packaged, the more likely we are to be successful in
integrating with a wide variety of other environments.
- 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.
Maybe the app server has some other approach to federation. SCA should
be able to integrate with and extend existing capabilities rather than
assuming it provides everything. There's also the standalone single-node
case that requires a small and simple embeddable SCA runtime.
- 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]
