You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jean-Sebastien Delfino <js...@apache.org> on 2007/03/12 00:43:41 UTC
Componentizing our SCA runtime kernel
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Working in trunk, was: Componentizing our SCA runtime kernel
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi,
My view is that, if the design that Sebastien is proposing is a step forward
in our modularization goals then its good to get it into the trunk. I like
the design and here is my +1 to move this into the trunk. IMO, moving to
the trunk does not mean the kernel will have to be immediately integrated
with this. I suppose we can take this incrementally evaluating and changing
things (wherever required) as we go along. Since this is going to come in as
a new module, it would only help in the incremental phase over.
Thanks
- Venkat
On 3/20/07, ant elder <an...@gmail.com> wrote:
>
> I agree putting it the trunk makes sense for all the reasons already
> mentioned.
>
> The trunk is where main development should take place unless there are a
> good reasons not to. Code going into trunk does not have to be finished
> and
> perfect but should be worked on in the trunk to incrementally improve. No
> one is going to intentionally set out to make things unstable but during
> active development there are going to be times when not everything works
> perfectly - just look at the state of the trunk right now. When
> requirements
> come up that need more guaranteed stability then they can use a branch so
> active development can continue in the trunk. This is what we've done in
> the
> past, eg. for all the releases and with the integration branch.
>
> The proposal is to add a new module for this code in java/sca/assembly so
> its not going to make anything unstable, and that allows other modules to
> easily start using it as the need arises. I can't see any reasons for this
> not to go in trunk.
>
> ...ant
>
> On 3/20/07, Simon Nash <na...@hursley.ibm.com> wrote:
> >
> > I think it's a good idea to move this code out of the integration
> > branch. I prefer to keep the integration branch for its original
> > purpose of providing a stable environment for developing and testing
> > end to end scennarios.
> >
> > I agree that it's important not to destabilize trunk by adding this
> > code. This could be achieved by separating it from the rest of trunk
> > by putting it in a separate module that is not part of the main
> > build profile.
> >
> > If there is potential to use this code in other parts of the trunk
> > code (Sebastien suggested a few possibilities), then this would be a
> > good reason to put it in trunk rather than a sandbox. I'm not clear
> > on whether this usage is something that might happen soon or is a little
> > further out. If this expected usage is a near-term thing, then I think
> > it makes sense to put the code in trunk. If there isn't any immediate
> > need to use it elsewhere, then it could go into a sandbox for now.
> >
> > Simon
> >
> > Jim Marino wrote:
> > >
> > > On Mar 19, 2007, at 10:40 PM, Jean-Sebastien Delfino wrote:
> > >
> > >> 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.
> > >>>
> > >>> 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?
> > >>>
> > >>
> > >> I made some progress with an assembly model module, containing
> > >> interfaces representing the SCA 1.0 assembly model and a default
> > >> implementation of these interfaces.
> > >>
> > >> The module is currently there: http://svn.apache.org/repos/asf/
> > >>
> incubator/tuscany/branches/sca-java-integration/sca/assembly. There's
> > >> additional test cases as well under http://svn.apache.org/
> > >> repos/asf/incubator/tuscany/branches/sca-java-integration/sca/scdl,
> > >> I'm planning to merge them into the assembly module soon. The
> > >> interfaces in assembly are different from the o.a.t.spi.model
> classes
> > >> in kernel/core. They are interfaces instead of classes, and I tried
> > >> to be as close as possible to the latest revision of SCA 1.0 spec.
> > >> I'd like your feedback and please let me know if you see any
> > >> inconsistencies with the SCA 1.0 spec. Next, I'd like to see if the
> > >> model loaders could be externalized as well in a separate module,
> but
> > >> this is going to be a little more complicated as the current loaders
> > >> have more dependencies, including circular dependencies with other
> > >> packages in kernel/core.
> > >>
> > >> This work is starting to generate significant changes and new code
> > >> and I don't want to risk destabilizing the integration branch
> with it
> > >> so I'd like to continue to work on this somewhere in the trunk
> > >> instead. I'm thinking of moving the assembly model module to trunk
> > >> under java/sca/assembly, available for use by our various tools,
> > >> plugins, as well as the kernel and services modules if they need.
> > >>
> > > As you mentioned above, the approach taken is significantly different
> > > than the design we have in trunk. To avoid destabilizing it, I'd
> > > suggest starting this in a sandbox so that we can better
> understand how
> > > it would integrate with our existing design without
> impacting existing
> > > ongoing work.
> > >
> > > Jim
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
Re: Working in trunk, was: Componentizing our SCA runtime kernel
Posted by ant elder <an...@gmail.com>.
I agree putting it the trunk makes sense for all the reasons already
mentioned.
The trunk is where main development should take place unless there are a
good reasons not to. Code going into trunk does not have to be finished and
perfect but should be worked on in the trunk to incrementally improve. No
one is going to intentionally set out to make things unstable but during
active development there are going to be times when not everything works
perfectly - just look at the state of the trunk right now. When requirements
come up that need more guaranteed stability then they can use a branch so
active development can continue in the trunk. This is what we've done in the
past, eg. for all the releases and with the integration branch.
The proposal is to add a new module for this code in java/sca/assembly so
its not going to make anything unstable, and that allows other modules to
easily start using it as the need arises. I can't see any reasons for this
not to go in trunk.
...ant
On 3/20/07, Simon Nash <na...@hursley.ibm.com> wrote:
>
> I think it's a good idea to move this code out of the integration
> branch. I prefer to keep the integration branch for its original
> purpose of providing a stable environment for developing and testing
> end to end scennarios.
>
> I agree that it's important not to destabilize trunk by adding this
> code. This could be achieved by separating it from the rest of trunk
> by putting it in a separate module that is not part of the main
> build profile.
>
> If there is potential to use this code in other parts of the trunk
> code (Sebastien suggested a few possibilities), then this would be a
> good reason to put it in trunk rather than a sandbox. I'm not clear
> on whether this usage is something that might happen soon or is a little
> further out. If this expected usage is a near-term thing, then I think
> it makes sense to put the code in trunk. If there isn't any immediate
> need to use it elsewhere, then it could go into a sandbox for now.
>
> Simon
>
> Jim Marino wrote:
> >
> > On Mar 19, 2007, at 10:40 PM, Jean-Sebastien Delfino wrote:
> >
> >> 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.
> >>>
> >>> 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?
> >>>
> >>
> >> I made some progress with an assembly model module, containing
> >> interfaces representing the SCA 1.0 assembly model and a default
> >> implementation of these interfaces.
> >>
> >> The module is currently there: http://svn.apache.org/repos/asf/
> >> incubator/tuscany/branches/sca-java-integration/sca/assembly. There's
> >> additional test cases as well under http://svn.apache.org/
> >> repos/asf/incubator/tuscany/branches/sca-java-integration/sca/scdl,
> >> I'm planning to merge them into the assembly module soon. The
> >> interfaces in assembly are different from the o.a.t.spi.model classes
> >> in kernel/core. They are interfaces instead of classes, and I tried
> >> to be as close as possible to the latest revision of SCA 1.0 spec.
> >> I'd like your feedback and please let me know if you see any
> >> inconsistencies with the SCA 1.0 spec. Next, I'd like to see if the
> >> model loaders could be externalized as well in a separate module, but
> >> this is going to be a little more complicated as the current loaders
> >> have more dependencies, including circular dependencies with other
> >> packages in kernel/core.
> >>
> >> This work is starting to generate significant changes and new code
> >> and I don't want to risk destabilizing the integration branch with it
> >> so I'd like to continue to work on this somewhere in the trunk
> >> instead. I'm thinking of moving the assembly model module to trunk
> >> under java/sca/assembly, available for use by our various tools,
> >> plugins, as well as the kernel and services modules if they need.
> >>
> > As you mentioned above, the approach taken is significantly different
> > than the design we have in trunk. To avoid destabilizing it, I'd
> > suggest starting this in a sandbox so that we can better understand how
> > it would integrate with our existing design without impacting existing
> > ongoing work.
> >
> > Jim
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Working in trunk, was: Componentizing our SCA runtime kernel
Posted by Simon Nash <na...@hursley.ibm.com>.
I think it's a good idea to move this code out of the integration
branch. I prefer to keep the integration branch for its original
purpose of providing a stable environment for developing and testing
end to end scennarios.
I agree that it's important not to destabilize trunk by adding this
code. This could be achieved by separating it from the rest of trunk
by putting it in a separate module that is not part of the main
build profile.
If there is potential to use this code in other parts of the trunk
code (Sebastien suggested a few possibilities), then this would be a
good reason to put it in trunk rather than a sandbox. I'm not clear
on whether this usage is something that might happen soon or is a little
further out. If this expected usage is a near-term thing, then I think
it makes sense to put the code in trunk. If there isn't any immediate
need to use it elsewhere, then it could go into a sandbox for now.
Simon
Jim Marino wrote:
>
> On Mar 19, 2007, at 10:40 PM, Jean-Sebastien Delfino wrote:
>
>> 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.
>>>
>>> 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?
>>>
>>
>> I made some progress with an assembly model module, containing
>> interfaces representing the SCA 1.0 assembly model and a default
>> implementation of these interfaces.
>>
>> The module is currently there: http://svn.apache.org/repos/asf/
>> incubator/tuscany/branches/sca-java-integration/sca/assembly. There's
>> additional test cases as well under http://svn.apache.org/
>> repos/asf/incubator/tuscany/branches/sca-java-integration/sca/scdl,
>> I'm planning to merge them into the assembly module soon. The
>> interfaces in assembly are different from the o.a.t.spi.model classes
>> in kernel/core. They are interfaces instead of classes, and I tried
>> to be as close as possible to the latest revision of SCA 1.0 spec.
>> I'd like your feedback and please let me know if you see any
>> inconsistencies with the SCA 1.0 spec. Next, I'd like to see if the
>> model loaders could be externalized as well in a separate module, but
>> this is going to be a little more complicated as the current loaders
>> have more dependencies, including circular dependencies with other
>> packages in kernel/core.
>>
>> This work is starting to generate significant changes and new code
>> and I don't want to risk destabilizing the integration branch with it
>> so I'd like to continue to work on this somewhere in the trunk
>> instead. I'm thinking of moving the assembly model module to trunk
>> under java/sca/assembly, available for use by our various tools,
>> plugins, as well as the kernel and services modules if they need.
>>
> As you mentioned above, the approach taken is significantly different
> than the design we have in trunk. To avoid destabilizing it, I'd
> suggest starting this in a sandbox so that we can better understand how
> it would integrate with our existing design without impacting existing
> ongoing work.
>
> Jim
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Working in trunk, was: Componentizing our SCA runtime kernel
Posted by Jim Marino <jm...@myromatours.com>.
On Mar 21, 2007, at 3:53 AM, Davanum Srinivas wrote:
> "we decided to abandon"...was there a VOTE? Please refresh my memory.
Yes, that was when we voted to move Chianti to trunk.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Working in trunk, was: Componentizing our SCA runtime kernel
Posted by Davanum Srinivas <da...@gmail.com>.
"we decided to abandon"...was there a VOTE? Please refresh my memory.
thanks,
dims
On 3/21/07, Jim Marino <jm...@myromatours.com> wrote:
>
> On Mar 20, 2007, at 10:45 PM, Luciano Resende wrote:
>
> > Hi Sebastien
> >
> > My understanding is that these are separate modules that are not
> > going to
> > destabelize the trunk at the moment. My personal opinion is that it
> > would be
> > OK to have this work done in the trunk as most of new work is being
> > developed.
>
> The proposed model changes will require a significant re-write of the
> kernel and re-introduce an old design that we decided to abandon
> about a year ago.
>
> Is that what people want to do?
>
> Jim
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Working in trunk, was: Componentizing our SCA runtime kernel
Posted by Jim Marino <jm...@myromatours.com>.
On Mar 20, 2007, at 10:45 PM, Luciano Resende wrote:
> Hi Sebastien
>
> My understanding is that these are separate modules that are not
> going to
> destabelize the trunk at the moment. My personal opinion is that it
> would be
> OK to have this work done in the trunk as most of new work is being
> developed.
The proposed model changes will require a significant re-write of the
kernel and re-introduce an old design that we decided to abandon
about a year ago.
Is that what people want to do?
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Working in trunk, was: Componentizing our SCA runtime kernel
Posted by Luciano Resende <lu...@gmail.com>.
Hi Sebastien
My understanding is that these are separate modules that are not going to
destabelize the trunk at the moment. My personal opinion is that it would be
OK to have this work done in the trunk as most of new work is being
developed.
--
Luciano Resende
http://people.apache.org/~lresende
On 3/20/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> Jim Marino wrote:
> >
> > On Mar 19, 2007, at 10:40 PM, Jean-Sebastien Delfino wrote:
> >
> >> 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.
> >>>
> >>> 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?
> >>>
> >>
> >> I made some progress with an assembly model module, containing
> >> interfaces representing the SCA 1.0 assembly model and a default
> >> implementation of these interfaces.
> >>
> >> The module is currently there:
> >>
> http://svn.apache.org/repos/asf/incubator/tuscany/branches/sca-java-integration/sca/assembly
> .
> >> There's additional test cases as well under
> >>
> http://svn.apache.org/repos/asf/incubator/tuscany/branches/sca-java-integration/sca/scdl
> ,
> >> I'm planning to merge them into the assembly module soon. The
> >> interfaces in assembly are different from the o.a.t.spi.model classes
> >> in kernel/core. They are interfaces instead of classes, and I tried
> >> to be as close as possible to the latest revision of SCA 1.0 spec.
> >> I'd like your feedback and please let me know if you see any
> >> inconsistencies with the SCA 1.0 spec. Next, I'd like to see if the
> >> model loaders could be externalized as well in a separate module, but
> >> this is going to be a little more complicated as the current loaders
> >> have more dependencies, including circular dependencies with other
> >> packages in kernel/core.
> >>
> >> This work is starting to generate significant changes and new code
> >> and I don't want to risk destabilizing the integration branch with it
> >> so I'd like to continue to work on this somewhere in the trunk
> >> instead. I'm thinking of moving the assembly model module to trunk
> >> under java/sca/assembly, available for use by our various tools,
> >> plugins, as well as the kernel and services modules if they need.
> >>
> > As you mentioned above, the approach taken is significantly different
> > than the design we have in trunk. To avoid destabilizing it, I'd
> > suggest starting this in a sandbox so that we can better understand
> > how it would integrate with our existing design without impacting
> > existing ongoing work.
> >
> > Jim
> >
>
> Jim,
>
> You're right, the approach is significantly different than the current
> design in trunk. The sandbox idea is a good idea, I'll continue to work
> on this in sandbox/sebastien so that our community can take a look and
> provide feedback without destabilizing the trunk.
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Working in trunk, was: Componentizing our SCA runtime kernel
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jim Marino wrote:
>
> On Mar 19, 2007, at 10:40 PM, Jean-Sebastien Delfino wrote:
>
>> 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.
>>>
>>> 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?
>>>
>>
>> I made some progress with an assembly model module, containing
>> interfaces representing the SCA 1.0 assembly model and a default
>> implementation of these interfaces.
>>
>> The module is currently there:
>> http://svn.apache.org/repos/asf/incubator/tuscany/branches/sca-java-integration/sca/assembly.
>> There's additional test cases as well under
>> http://svn.apache.org/repos/asf/incubator/tuscany/branches/sca-java-integration/sca/scdl,
>> I'm planning to merge them into the assembly module soon. The
>> interfaces in assembly are different from the o.a.t.spi.model classes
>> in kernel/core. They are interfaces instead of classes, and I tried
>> to be as close as possible to the latest revision of SCA 1.0 spec.
>> I'd like your feedback and please let me know if you see any
>> inconsistencies with the SCA 1.0 spec. Next, I'd like to see if the
>> model loaders could be externalized as well in a separate module, but
>> this is going to be a little more complicated as the current loaders
>> have more dependencies, including circular dependencies with other
>> packages in kernel/core.
>>
>> This work is starting to generate significant changes and new code
>> and I don't want to risk destabilizing the integration branch with it
>> so I'd like to continue to work on this somewhere in the trunk
>> instead. I'm thinking of moving the assembly model module to trunk
>> under java/sca/assembly, available for use by our various tools,
>> plugins, as well as the kernel and services modules if they need.
>>
> As you mentioned above, the approach taken is significantly different
> than the design we have in trunk. To avoid destabilizing it, I'd
> suggest starting this in a sandbox so that we can better understand
> how it would integrate with our existing design without impacting
> existing ongoing work.
>
> Jim
>
Jim,
You're right, the approach is significantly different than the current
design in trunk. The sandbox idea is a good idea, I'll continue to work
on this in sandbox/sebastien so that our community can take a look and
provide feedback without destabilizing the trunk.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Working in trunk, was: Componentizing our SCA runtime kernel
Posted by Jim Marino <jm...@myromatours.com>.
On Mar 19, 2007, at 10:40 PM, Jean-Sebastien Delfino wrote:
> 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.
>>
>> 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?
>>
>
> I made some progress with an assembly model module, containing
> interfaces representing the SCA 1.0 assembly model and a default
> implementation of these interfaces.
>
> The module is currently there: http://svn.apache.org/repos/asf/
> incubator/tuscany/branches/sca-java-integration/sca/assembly.
> There's additional test cases as well under http://svn.apache.org/
> repos/asf/incubator/tuscany/branches/sca-java-integration/sca/scdl,
> I'm planning to merge them into the assembly module soon. The
> interfaces in assembly are different from the o.a.t.spi.model
> classes in kernel/core. They are interfaces instead of classes, and
> I tried to be as close as possible to the latest revision of SCA
> 1.0 spec. I'd like your feedback and please let me know if you see
> any inconsistencies with the SCA 1.0 spec. Next, I'd like to see if
> the model loaders could be externalized as well in a separate
> module, but this is going to be a little more complicated as the
> current loaders have more dependencies, including circular
> dependencies with other packages in kernel/core.
>
> This work is starting to generate significant changes and new code
> and I don't want to risk destabilizing the integration branch with
> it so I'd like to continue to work on this somewhere in the trunk
> instead. I'm thinking of moving the assembly model module to trunk
> under java/sca/assembly, available for use by our various tools,
> plugins, as well as the kernel and services modules if they need.
>
As you mentioned above, the approach taken is significantly different
than the design we have in trunk. To avoid destabilizing it, I'd
suggest starting this in a sandbox so that we can better understand
how it would integrate with our existing design without impacting
existing ongoing work.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Working in trunk, was: Componentizing our SCA runtime kernel
Posted by ant elder <an...@gmail.com>.
On 3/20/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> 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.
> >
> > 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?
> >
>
> I made some progress with an assembly model module, containing
> interfaces representing the SCA 1.0 assembly model and a default
> implementation of these interfaces.
>
> The module is currently there:
>
> http://svn.apache.org/repos/asf/incubator/tuscany/branches/sca-java-integration/sca/assembly
> .
> There's additional test cases as well under
>
> http://svn.apache.org/repos/asf/incubator/tuscany/branches/sca-java-integration/sca/scdl
> ,
> I'm planning to merge them into the assembly module soon. The interfaces
> in assembly are different from the o.a.t.spi.model classes in
> kernel/core. They are interfaces instead of classes, and I tried to be
> as close as possible to the latest revision of SCA 1.0 spec. I'd like
> your feedback and please let me know if you see any inconsistencies with
> the SCA 1.0 spec. Next, I'd like to see if the model loaders could be
> externalized as well in a separate module, but this is going to be a
> little more complicated as the current loaders have more dependencies,
> including circular dependencies with other packages in kernel/core.
>
> This work is starting to generate significant changes and new code and
> I don't want to risk destabilizing the integration branch with it so I'd
> like to continue to work on this somewhere in the trunk instead. I'm
> thinking of moving the assembly model module to trunk under
> java/sca/assembly, available for use by our various tools, plugins, as
> well as the kernel and services modules if they need.
>
> Thoughts?
Moving this to trunk and continuing development there seems like the best
approach to me.
...ant
Working in trunk, was: Componentizing our SCA runtime kernel
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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.
>
> 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?
>
I made some progress with an assembly model module, containing
interfaces representing the SCA 1.0 assembly model and a default
implementation of these interfaces.
The module is currently there:
http://svn.apache.org/repos/asf/incubator/tuscany/branches/sca-java-integration/sca/assembly.
There's additional test cases as well under
http://svn.apache.org/repos/asf/incubator/tuscany/branches/sca-java-integration/sca/scdl,
I'm planning to merge them into the assembly module soon. The interfaces
in assembly are different from the o.a.t.spi.model classes in
kernel/core. They are interfaces instead of classes, and I tried to be
as close as possible to the latest revision of SCA 1.0 spec. I'd like
your feedback and please let me know if you see any inconsistencies with
the SCA 1.0 spec. Next, I'd like to see if the model loaders could be
externalized as well in a separate module, but this is going to be a
little more complicated as the current loaders have more dependencies,
including circular dependencies with other packages in kernel/core.
This work is starting to generate significant changes and new code and
I don't want to risk destabilizing the integration branch with it so I'd
like to continue to work on this somewhere in the trunk instead. I'm
thinking of moving the assembly model module to trunk under
java/sca/assembly, available for use by our various tools, plugins, as
well as the kernel and services modules if they need.
Thoughts?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Componentizing our SCA runtime kernel
Posted by ant elder <an...@gmail.com>.
On 3/13/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> ant elder wrote:
> > On 3/11/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> >
> > <snip/>
> >
> > 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.
> >
> >
> >
> > I'd like to help, could you say a bit more on some specific things to
> > help
> > with that would fit in with what you've already begun?
> >
> > ...ant
> >
> Ant,
>
> Here are a few features that could packaged as separate modules IMO:
> - language independent interface definition support, independent of WSDL
> and Java (the *idl* packages)
> - support for SCA contributions
> - core databinding framework
> - builder framework
> - wiring logic
> - IOC injection container
> - lifecycle management
> - invocation/message interceptor framework
> - federated deployment and distributed wiring in an SCA domain
> - <implementation.java> support, annotation processing, and scope
> management
> - policy support
>
> Just pick what you're interested in, but I think it'll be easier if we
> get the top ones in place first. IIRC you've been doing some work with
> WSDL/Java mapping so the interface definition (idl) framework may be a
> good candidate, starting with creating a new Maven module for it...
Ok, I'll start having a look at this language independent interface
definition support.
...ant
Re: Componentizing our SCA runtime kernel
Posted by Raymond Feng <en...@gmail.com>.
Hi,
I will give a try on "databinding" first. Then "IoC" if possible.
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <js...@apache.org>
To: <tu...@ws.apache.org>
Sent: Monday, March 12, 2007 7:03 PM
Subject: Re: Componentizing our SCA runtime kernel
> ant elder wrote:
>> On 3/11/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>>
>> <snip/>
>>
>> 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.
>>
>>
>>
>> I'd like to help, could you say a bit more on some specific things to
>> help
>> with that would fit in with what you've already begun?
>>
>> ...ant
>>
> Ant,
>
> Here are a few features that could packaged as separate modules IMO:
> - language independent interface definition support, independent of WSDL
> and Java (the *idl* packages)
> - support for SCA contributions
> - core databinding framework
> - builder framework
> - wiring logic
> - IOC injection container
> - lifecycle management
> - invocation/message interceptor framework
> - federated deployment and distributed wiring in an SCA domain
> - <implementation.java> support, annotation processing, and scope
> management
> - policy support
>
> Just pick what you're interested in, but I think it'll be easier if we get
> the top ones in place first. IIRC you've been doing some work with
> WSDL/Java mapping so the interface definition (idl) framework may be a
> good candidate, starting with creating a new Maven module for it...
>
> Thanks!
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Componentizing our SCA runtime kernel
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
> On 3/11/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> <snip/>
>
> 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.
>
>
>
> I'd like to help, could you say a bit more on some specific things to
> help
> with that would fit in with what you've already begun?
>
> ...ant
>
Ant,
Here are a few features that could packaged as separate modules IMO:
- language independent interface definition support, independent of WSDL
and Java (the *idl* packages)
- support for SCA contributions
- core databinding framework
- builder framework
- wiring logic
- IOC injection container
- lifecycle management
- invocation/message interceptor framework
- federated deployment and distributed wiring in an SCA domain
- <implementation.java> support, annotation processing, and scope management
- policy support
Just pick what you're interested in, but I think it'll be easier if we
get the top ones in place first. IIRC you've been doing some work with
WSDL/Java mapping so the interface definition (idl) framework may be a
good candidate, starting with creating a new Maven module for it...
Thanks!
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Componentizing our SCA runtime kernel
Posted by ant elder <an...@gmail.com>.
On 3/11/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
<snip/>
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.
I'd like to help, could you say a bit more on some specific things to help
with that would fit in with what you've already begun?
...ant
Re: Componentizing our SCA runtime kernel
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
> On 3/12/07, Jim Marino <jm...@myromatours.com> wrote:
>>
>>
>> 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.
>
>
> Lets remember we are all part of the community and all the area's
> currently
> being worked on includes all the things in the sca-java-integration
> branch.
>
> It looks like Sebastien has started prototyping these changes now,
> thats in
> the sca-java-integration branch, i guess it doesn't matter where its done
> right now but I really hope as soon as anything comes of this we start
> moving bits to trunk to be refined further there as it would be vastly
> better for Tuscany if we could find a way to get things back together
> again.
Yes, I'm really hoping that this componentization work will help get
things back together, smaller modules will help.
>
> I'm +1 in principle to whats being proposed and I'd like to help with the
> prototyping work.
>
> ...ant
>
Cool! I see that you've posted another email to discuss specific help
(see
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200703.mbox/%3C71e1b5740703121033xe642b96obb9af216c106a4@mail.gmail.com%3E).
I'll respond to this one.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Componentizing our SCA runtime kernel
Posted by ant elder <an...@gmail.com>.
On 3/12/07, Jim Marino <jm...@myromatours.com> wrote:
>
>
> 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.
Lets remember we are all part of the community and all the area's currently
being worked on includes all the things in the sca-java-integration branch.
It looks like Sebastien has started prototyping these changes now, thats in
the sca-java-integration branch, i guess it doesn't matter where its done
right now but I really hope as soon as anything comes of this we start
moving bits to trunk to be refined further there as it would be vastly
better for Tuscany if we could find a way to get things back together again.
I'm +1 in principle to whats being proposed and I'd like to help with the
prototyping work.
...ant
Re: Componentizing our SCA runtime kernel
Posted by Jim Marino <jm...@myromatours.com>.
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Componentizing our SCA runtime kernel
Posted by Simon Nash <na...@hursley.ibm.com>.
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. 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.
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.
>> 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. 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.
>
>> - 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.
>> - 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. There's also the standalone single-node
case that requires a small and simple embeddable SCA runtime.
>> - replace the SCDL loaders if you're storing the assembly metadata in
>> a database instead of SCDL files;
>
> You can already do that today.
>
>> - 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"?
>
>> 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, but I don't think we should be
> building our runtime around the demands of tooling implementations. You
> may be better off here looking at Eclipse STP. 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.
>
>>
>> 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?
>
> Jim
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Componentizing our SCA runtime kernel
Posted by ant elder <an...@gmail.com>.
On 3/13/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
<snip/>
> 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.
Yes I'd really like to get the script components working in a more dynamic
way. Other script languages besides Ruby also support 'method missing' type
function, Rhino will in their up coming release, many other dynamic
languages support things like defining new functions or methods at runtime.
For these dynamic languages having to define type information via
annotations or side files is unnatural, so I'd like to get to where they're
not mandatory. Maybe enable script components to be wired up anywhere and
the invocation is just attempted and fails at runtime if the function
doesn't exist or the argument types are not what the script expects.
Along with getting the Axis2 binding going again in the trunk I also plan to
get the script container going again as well and explore some of these
things. I have tried in the past but its been difficult to get to work, it
looks like some of the recent spec and trunk changes may make some of this
easier to do now.
...ant
Re: Componentizing our SCA runtime kernel
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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/%3c013e01c764ed$dbf43570$0400a8c0@rfengt60p%3e
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Componentizing our SCA runtime kernel
Posted by Luciano Resende <lu...@gmail.com>.
I'll take a look at making the "support for SCA contributions" into a
separate module and share my experience.
On 3/12/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> [snip]
> Raymond Feng wrote:
> > Hi,
> >
> > A few comments:
> >
> > 1) I think the term "componentization" is bit misleading here. By
> > adopting the SCA assembly to build the Tuscany kernel (system
> > composite w/ system components), we have componentized most of the key
> > system functions. My understanding is that we're talking about
> > sub-modules in the kernel. There are fairly isolated groups of
> > functions in the core/spi which can be better layered out to achieve
> > more flexibilities for Tuscany embedders. If we look at the system
> > SCDL today, we already have a bunch of "include" statements. It seem
> > to be a good indication to me for more fine-grained assembly of the
> > kernel. For example, "databinding", "model", "loaders", "federation"
> > can be the candidates for sub-modules.
> >
> > 2) We ran into a case: The model objects are defined in "spi" which
> > has dependency on "host-api". To support the case that we need to pass
> > some model objects to host apis, we had to use generic "Object" to
> > avoid circular dependencies.
> >
> > 3) For models/loaders, one embedder might choose to use JAXB generated
> > classes and use JAXB to load SCDLs. Is it possible?
> >
> > 4) To my knowledge, we're putting together a discovery-based
> > federation for SCA domain. What if we want to support repository-based
> > (for example, a SVN repository or maven repo) SCA domain? Do we have
> > the pluggability?
> >
> > So far we have two levels of grandularity for the Tuscany kernel, a
> > system composite and a list of system components. I'm looking for
> > smaller composites which can be used to assemble the system composites
> > based on the embedder's intensions. Does it make sense?
> >
> > Thanks,
> > Raymond
> >
>
> Yes that's along the lines of what I was thinking too, a few modules
> facilitating the assembly of a runtime integration.
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Luciano Resende
http://people.apache.org/~lresende
Re: Componentizing our SCA runtime kernel
Posted by Jean-Sebastien Delfino <js...@apache.org>.
[snip]
Raymond Feng wrote:
> Hi,
>
> A few comments:
>
> 1) I think the term "componentization" is bit misleading here. By
> adopting the SCA assembly to build the Tuscany kernel (system
> composite w/ system components), we have componentized most of the key
> system functions. My understanding is that we're talking about
> sub-modules in the kernel. There are fairly isolated groups of
> functions in the core/spi which can be better layered out to achieve
> more flexibilities for Tuscany embedders. If we look at the system
> SCDL today, we already have a bunch of "include" statements. It seem
> to be a good indication to me for more fine-grained assembly of the
> kernel. For example, "databinding", "model", "loaders", "federation"
> can be the candidates for sub-modules.
>
> 2) We ran into a case: The model objects are defined in "spi" which
> has dependency on "host-api". To support the case that we need to pass
> some model objects to host apis, we had to use generic "Object" to
> avoid circular dependencies.
>
> 3) For models/loaders, one embedder might choose to use JAXB generated
> classes and use JAXB to load SCDLs. Is it possible?
>
> 4) To my knowledge, we're putting together a discovery-based
> federation for SCA domain. What if we want to support repository-based
> (for example, a SVN repository or maven repo) SCA domain? Do we have
> the pluggability?
>
> So far we have two levels of grandularity for the Tuscany kernel, a
> system composite and a list of system components. I'm looking for
> smaller composites which can be used to assemble the system composites
> based on the embedder's intensions. Does it make sense?
>
> Thanks,
> Raymond
>
Yes that's along the lines of what I was thinking too, a few modules
facilitating the assembly of a runtime integration.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Componentizing our SCA runtime kernel
Posted by Raymond Feng <en...@gmail.com>.
Hi,
A few comments:
1) I think the term "componentization" is bit misleading here. By adopting
the SCA assembly to build the Tuscany kernel (system composite w/ system
components), we have componentized most of the key system functions. My
understanding is that we're talking about sub-modules in the kernel. There
are fairly isolated groups of functions in the core/spi which can be better
layered out to achieve more flexibilities for Tuscany embedders. If we look
at the system SCDL today, we already have a bunch of "include" statements.
It seem to be a good indication to me for more fine-grained assembly of the
kernel. For example, "databinding", "model", "loaders", "federation" can be
the candidates for sub-modules.
2) We ran into a case: The model objects are defined in "spi" which has
dependency on "host-api". To support the case that we need to pass some
model objects to host apis, we had to use generic "Object" to avoid circular
dependencies.
3) For models/loaders, one embedder might choose to use JAXB generated
classes and use JAXB to load SCDLs. Is it possible?
4) To my knowledge, we're putting together a discovery-based federation for
SCA domain. What if we want to support repository-based (for example, a SVN
repository or maven repo) SCA domain? Do we have the pluggability?
So far we have two levels of grandularity for the Tuscany kernel, a system
composite and a list of system components. I'm looking for smaller
composites which can be used to assemble the system composites based on the
embedder's intensions. Does it make sense?
Thanks,
Raymond
----- Original Message -----
From: "Jim Marino" <jm...@myromatours.com>
To: <tu...@ws.apache.org>
Sent: Monday, March 12, 2007 12:00 AM
Subject: Re: Componentizing our SCA runtime kernel
>
> 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.
>
>> 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.
>
>
>> - 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.
>
>> - 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.
>
>> - replace the SCDL loaders if you're storing the assembly metadata in a
>> database instead of SCDL files;
> You can already do that today.
>
>> - 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"?
>
>> 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, but I don't think we should be building
> our runtime around the demands of tooling implementations. You may be
> better off here looking at Eclipse STP. 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.
>>
>> 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?
>
> Jim
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Componentizing our SCA runtime kernel
Posted by Jim Marino <jm...@myromatours.com>.
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.
> 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.
> - 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.
> - 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.
> - replace the SCDL loaders if you're storing the assembly metadata
> in a database instead of SCDL files;
You can already do that today.
> - 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"?
> 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, but I don't think we should be
building our runtime around the demands of tooling implementations.
You may be better off here looking at Eclipse STP. 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.
>
> 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?
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org