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.
I'm aware of what platforms are supported, thanks for reminding me :)
but as I said above I'm hoping that this exercise will help achieve
better integrations. For example with Tomcat we are currently packaging
the whole Tuscany runtime in each web app. This is not ideal for me so
I'd like to see how componentizing the Kernel can help improve this
particular integration with Tomcat.
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?
Both I think.
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.
You're right, the current approach is problematic. Since the SCA kernel
is implemented as a set of SCA components requiring... an SCA kernel to
run, it becomes difficult to split the Kernel in smaller modules. But
that doesn't necessarily mean that we have to satisfy ourselves with a
single-module Kernel, and that we cannot try to fix that problem. I'm
not sure that we need a full SCA implementation to implement an SCA
runtime kernel and I'm trying to be optimistic, the nice thing with the
current Kernel is that it's implemented as a set of IOC friendly beans
so it shouldn't be too difficult to assemble.
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.
- 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.
Local is the default for Java interfaces. WSDL interfaces are remotable.
This is mainly just an example, but an SCA runtime executing a BPEL
process component would not need to support local services as its
interfaces will be WSDL.
- 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.
The advantage of integrating the kernel? Reuse everything else the
kernel support as-is. That's still very interesting, even if you choose
to implement distributed deployment / discovery / wiring differently in
that particular environment.
- replace the SCDL loaders if you're storing the assembly metadata in
a database instead of SCDL files;
You can already do that today.
Cool. Looks like more specific scenarios/questions were asked in
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200703.mbox/[EMAIL PROTECTED]
This might be a good thread to start a discussion on this particular
subject.
- use a different handler/interceptor mechanism already in use in
your app server or a more dynamic invocation mechanism to support
scripting languages for example.
This I really don't get. If the infrastructure uses a different wiring
mechanism, the builders, policy, federation, components and extensions
will all need to be different. At that point, it's a different runtime.
Also, what is "a more dynamic invocation mechanism"?
Most scripting languages out there use dynamic typing - or duck typing
for Ruby :) - and do not define interfaces and method signatures. Going
further Ruby for example defines a method_missing method that will be
invoked if the target component does not implement the method a client
is trying to invoke. I think that an SCA runtime assembled to run
scripting components will have to support that. Ant may have more
insight here as he's been doing some scripting integration work with the
Java runtime.
Another scenario I have in mind is to reuse parts of the Tuscany
kernel in validation tasks, codegen utilities, deployment and
management tools. For example I'd like to have an Ant task that
automates the generation of SDO or JAXB objects for an entire SCA
contribution.
This task will need access to the SCA assembly model, the SCA
contribution model, maybe our Interface contract model as well, but I
don't want to drag the whole kernel for that. Similar idea for
deployment and management tasks.
We've been over this ground many times before. If tooling can make use
of runtime classes that is great,
Yes, that's what I'd like to see, at least for our command line codegen,
deployment and our admin capabilities.
but I don't think we should be building our runtime around the demands
of tooling implementations.
I agree, that would not work well.
You may be better off here looking at Eclipse STP.
Looks like this is a pure EMF model, I think it'll be great to build
editors and Eclipse development tools, but I think that our runtime
model should be sufficient for what we'll need to do in the build /
deployment / admin space.
If you can reuse the kernel code, I believe it is about 500K which is
less than a StAX parser, as well as SDO and JAXB implementations :-)
A refactored/componentized kernel will also make it easier for people
to contribute to the individual pieces and exchange components
between our various initiatives.
We already have a "componentized kernel" - it is built from SCA
components. That is different than modularity.
I think that Raymond brought that up too in the thread I pointed to
above, component, module are overloaded terms. I'd be happy to call this
modularizing our Kernel if it's more clear to everybody. In Maven terms
we'll probably come up with multiple modules. On the other hand, since
our runtime is built using SCA, each module will probably contain SCDL
defining a composite... component, containing the (finer grained)
components that you're talking about :)
For example I'd like to pull pieces of the trunk in the integration
branch, and it would be much easier if the single kernel/core module
was split in smaller independent modules (assembly model, SCA
contribution model, loaders, assembly wiring logic, invocation
framework etc...)
To help explore these ideas, I'm thinking about starting some
concrete work and try to pull some of the kernel code into individual
modules, probably start from the bottom of the stack and have the
assembly metadata and SCDL loaders in separate modules. There's a lot
of code, so I could use any help if people are interested.
Thoughts?
I think your ideas would resonate and gain more currency if you made
concrete proposals, particularly if they took into account the
architecture we have in place and the current discussions related to
ongoing work. For example, we are currently working on support for
federated provisioning. Perhaps the existing kernel should be
modularized by separating capabilities related to the controller and
slave nodes?
What you have above lacks detail for me to thoroughly understand what
is being proposed or how it will benefit any of the work being done in
trunk.
I see you have gone ahead and started experimenting with this in the
"integration" branch you set up. Maybe that is the best way to proceed
so we can understand what your specific proposal(s) entail?
+1, I agree that this is the best way to proceed, I created the first
two modules yesterday and been busy working on them most of the day. If
other people are interested in helping flesh out the details and make
this proposal concrete through code, feel free to come and help.
Jim
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
