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."
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.
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]
