Hi, Jim.
Please see my comments inline.
Thanks,
Raymond
----- Original Message -----
From: "Jim Marino" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, March 28, 2007 1:56 PM
Subject: Re: [Discussion] Tuscany kernel modulization
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.
IMHO, improving the modularity will help the portability. If we decompose
the kernel into smaller modules, it should be more flexible to embed Tuscany
into various host environments.
2. The metamodel in the sandbox does not account for federation,
distribution, or mapping to a physical topology
It reflects my disclaimer that it's not complete and accurate :-) and we
should work together to make it happen if we agree on the rationales for
modulization.
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.
This is very good as it seems to be possible that we separate the wiring
engine and the java component type.
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.
I was not questioning the current federation support with the pluggability
of communication mechanisms. I think the proposal is to have the federation
in its own module instead of being mixed in the core.
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.
Would you mind sharing your view of "Modularizing according to how the
federated architecture works"? We can further discuss how modulization can
be done in better ways.
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
