On Mar 12, 2007, at 5:11 AM, Simon Nash wrote:
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.
Just to be sure, I didn't say it was worth exploring. I'm just trying
to understand what is being proposed as it is not clear at all.
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.
My advice would be to take the approach of focusing on how your
proposals benefit the community and, in particular, the areas people
are currently working on. I think you will get less traction if you
propose a set of "external requirements".
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.
What specifically is being proposed? How is this different from:
http://people.apache.org/repo/m2-incubating-repository/org/apache/
tuscany/sca/kernel/
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.
Please note from my original questions that it is unclear what is
even being proposed: using alternative wiring infrastructure for
component implementation types or using an alternative wiring engine
for the runtime itself.
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.
Again, I don't follow what is being proposed. If you want to "cherry-
pick" something from the existing kernel, this can already be done.
The kernel itself is only 500K. If you are not using the loaders,
then you can also remove the single dependency on StAX and have just
the kernel jars on the classpath. Also, the functionality in kernel
is completely componentized as POJOs.
- 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.
That's too general of a statement. I'm all for providing flexibility
and choice but what is being proposed?
- 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.
I think we need to get into specifics here again. If an app server
supports a protocol for things like Discovery, the current
architecture can handle this case as it is pluggable. For example, I
could use WebLogic's T3 protocol. If someone wants to replace the
marshalling infrastructure, e.g. how physical definitions are
serialized and distributed, that can be done as well. If, however,
you want to replace all of the marshalling and wiring infrastructure,
then my recommendation is to use a different runtime.
There's also the standalone single-node
case that requires a small and simple embeddable SCA runtime.
We support that as well. In fact, the single node is about 2MB.
Hopefully we can get that smaller as well.
I do think there is a discussion to be had on reorganizing the kernel
to better support the federation architecture. I will pick that up in
a different thread as, unfortunately, it seems to have been lost in
the noise.
In terms of the discussion at hand, you suggested above it may be
worth prototyping these ideas. Maybe you can go do this in the
sandbox and when you have concrete proposals in place, we can take a
look?
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
