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.
A few examples come to mind:
- swap our POJO IOC container with another one already there in the
target app server;
- strip out the local assembly support when building a WSDL
remote-interface based (an SCA/BPEL container for example);
- 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;
- replace the SCDL loaders if you're storing the assembly metadata in a
database instead of SCDL files;
- 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.
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.
A refactored/componentized kernel will also make it easier for people to
contribute to the individual pieces and exchange components between our
various initiatives.
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?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
