Sorry for the delay, I've been out and then tied up at work...
My first comment is most of the code is organized the way you describe.
I do have several big issues with details:
1. A main tenet of the current runtime architecture is that there is
one kernel implementation capable of being embedded in a variety of
host environments. This facilitates. among other things, having a /
common/ extension SPI and policy framework. Someone could certainly
have a set of SCA implementations that share a common metamodel.
However, I don't see how to reconcile that with the goals of a
portable runtime.
2. The metamodel in the sandbox does not account for federation,
distribution, or mapping to a physical topology
3. The goal of the wiring infrastructure is that it not be tied to
Java component implementation types. There may be one or two
assumptions we need to fix in the code but the majority of the
runtime today is the wiring engine. Again, this relates to having
infrastructure that supports common federation, wiring, policy, and
monitoring in a heterogeneous environment.
I feel we are so far off in terms of goals and architecture we are
just talking past one another. I'm trying to find common ground but I
just don't see it happening. I have responded to specifics below if
this helps...
Jim
On Mar 26, 2007, at 2:30 PM, Raymond Feng wrote:
Hi,
By reading through a bunch of e-mails on this mailing list and
adding my imagination, I put together a conceptual diagram at the
following wiki page to illustrate the kernel modulization.
http://cwiki.apache.org/confluence/display/TUSCANY/Kernel
+Modulization+Design+Discussions
This diagram is merely for the discussion purpose and it only
reflects my understandings so far. By no means it is meant to be
complete and accurate. But I hope we can use it as the starting
point for the technical discussion.
Going through this exercise, I start to see values of the efforts
which would lead to greater adoption of Tuscany/SCA by various
embedders including other Apache projects and simplication of the
kernel that the community can work together. You might take the
following items as my crazy brainstorming:
1) Allow different ways to populate the assembly model: from SCDL,
from other Domain Specific Languages (DSL) or even from another
model such as the Spring context. On the hand, make it possible to
convert the SCA assembly model to be executed by other frameworks
such as Spring.
The current kernel can already support this since the assembly model
is just POJOs.
2) Improve the federation story so that we can plugin different
federation mechanisms, such as P2P discovery-based or repository-
based schemes.
We already support this. Meeraj was able to implement both JXTA and
JMS mechanisms.
3) Bootstrap the Tuscany kernel without the Java container in case
that either the hosting runtime is resource-constrained (for
example, cellular phones or network appliances) or it doesn't need
to the support for POJO (for example, scripting for Web 2.0).
Besides the requirement for Java 5 (I'm not sure how many resource-
constrained devices support that level of JVM) I believe the
federation architecture supports this better. For example, the wiring
infrastructure takes a physical model which is highly optimized. We
are also in the process of significantly reducing the current kernel
footprint from its current 500K size. Modularizing according to how
the federated architecture works would probably enable that better.
On the wiring engine, we will still need something for extending the
runtime and supporting other component implementation types outside
of the Java SCA spec.
4) Provide more flexibility to integrate with different hosting
environments with a subset of kernel modules.
...
I guess I throw out enough seeds for thoughts and now it's your
turn :-).
Thanks,
Raymond
---------------------------------------------------------------------
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]
