Hi,
Please see my comments inline.
Thanks,
Raymond
----- Original Message -----
From: "Jeremy Boynes" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, March 27, 2007 1:29 PM
Subject: Re: [Discussion] Tuscany kernel modulization
Nice diagram, Raymond, thanks for putting this together.
What I'm struggling with is that this seems fairly similar to the way the
code is organized now. Most of the boxes there already exist and have
interfaces to abstract away their implementation. Everything in
"Cross-cutting system services" is that way and the same for
"Container/Binding/Databinding/IDL Extensions" and "Pluggable
Federations."
I think the goal is to decompose the core into submodules that group related
system components. I agree with you that the kernel has been componentized.
But with more than 130 system components in the core, the complexibility of
the core grows and people tend to couple all the runtime pieces into one
module.
These are all components implemented using the Tuscany "system"
programming model - basically, a simplified, POJO based IoC model
decorated (to the least extent possible) with SCA annotations. Each of
those components already has an interface to define the function it
provides.
We assemble those components using SCA assembly. That makes sense to me
because as an SCA runtime we have to support SCA assembly - so not only
will we need the code to do that, it makes things familiar to users as
there is a common language. We could assemble the runtime another way,
for example using Spring XML or Java code, but then users need to be
familiar with two assembly mechanisms and that seems like confusing and
unnecessary complexity.
I think using the SCA assembly and annotations create a chicken-egg problem
which forces us to have the java component support in the core. Having the
same programming model is nice, but it seems that extension developers are
still required to code by the SPI contracts at plumbing level.
One reason the SPI module is so large is that it does define many the
interfaces for the components in you diagram. I think there is room for a
reorganization there to clarify the usage of those interfaces. I would
propose we start with that rather than the wholesale, revolutionary
rewrite of the kernel that has been suggested.
--
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]
