You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Raymond Feng <en...@gmail.com> on 2008/12/02 07:43:59 UTC
What to do next for the Tuscany Java SCA 2.x stream
Hi,
I propose that we use the following two perspectives to drive the Tuscany
Java SCA 2.x stream.
1) Runtime architecture: Clean up the core set of modules as documented at
[1]
* Enforce the modularity and make sure cross-module code dependencies go
through proper set of SPIs
* Rationalize the core-spi which is the contract between the core and
extensions (implementations and bindings).
2) SCA functionality: Provide a consistent SCA domain story for deployment
(See [2], [3] and [4]).
* Use scenarios to better understand how multiple contributions are
installed to a SCA domain, how cross-contribution artifact references are
resolved, how nodes are configured to represent runtime capabilities and how
nodes run SCA composite applications.
* Decompose the basic services related to SCA domain management and provide
SPIs for these atomic operations.
[1]
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/OASIS+Development+Stream
[2]
http://markmail.org/message/afae3zayzmpq6rx7?q=multiple+contributions+and+the+domain-level+composite&page=1&refer=qttcfwwun33gausl
[3]
http://www.ibm.com/developerworks/opensource/library/ws-sca-tuscany/index.html
[4]
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Distributed+Runtime
Thanks,
Raymond
Re: What to do next for the Tuscany Java SCA 2.x stream
Posted by Raymond Feng <en...@gmail.com>.
Hi,
I created the following wiki page to track the Tuscany SPI packages contributed by the various modules.
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+SPIs
Thanks,
Raymond
From: Simon Laws
Sent: Tuesday, December 02, 2008 9:21 AM
To: dev@tuscany.apache.org
Subject: Re: What to do next for the Tuscany Java SCA 2.x stream
On Tue, Dec 2, 2008 at 6:43 AM, Raymond Feng <en...@gmail.com> wrote:
Hi,
I propose that we use the following two perspectives to drive the Tuscany Java SCA 2.x stream.
1) Runtime architecture: Clean up the core set of modules as documented at [1]
* Enforce the modularity and make sure cross-module code dependencies go through proper set of SPIs
* Rationalize the core-spi which is the contract between the core and extensions (implementations and bindings).
2) SCA functionality: Provide a consistent SCA domain story for deployment (See [2], [3] and [4]).
* Use scenarios to better understand how multiple contributions are installed to a SCA domain, how cross-contribution artifact references are resolved, how nodes are configured to represent runtime capabilities and how nodes run SCA composite applications.
* Decompose the basic services related to SCA domain management and provide SPIs for these atomic operations.
[1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/OASIS+Development+Stream
[2] http://markmail.org/message/afae3zayzmpq6rx7?q=multiple+contributions+and+the+domain-level+composite&page=1&refer=qttcfwwun33gausl
[3] http://www.ibm.com/developerworks/opensource/library/ws-sca-tuscany/index.html
[4] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Distributed+Runtime
Thanks,
Raymond
Thanks Raymond
Picking up on the thread title "what to do next". It's good to set ourselves some short term targets without worrying about the full shopping list that was developing on the themes thread [1].
- I propose we define "next" as what we think we can achieve before we each go on leave for Christmas
- I agree It's important to progress both functional and non-functional objectives but there will be some overlap. Without one we can't prove the other.
- For me, these are the things that should come "Next" before we start to bring up lots of extensions
SPI (1 - non-funtional)
** Define the SPI (collect the SPI actions that have appeared on the wiki and various threads).
- I would include tidying up the providers/endpoint/builders (SL1)
** Package the SPI (I thinks this is your Enforce the modularity and make sure cross-module code dependencies go through proper set of SPIs)
Thin slice through "soup to nuts" Tuscany delivery story (1 - non functional) (SL4)
** developing core
** developing extension
** developing samples/demos
** building an releasing a distribution, how do we do this much more quickly than we do now
** using a distribution
Runtime usability story (2 functional) (SL2)
** Domain/Node - points above are comprehensive.
How to adopt OASIS spec features (2 functional) (SL3)
** what features have changed
** how to extend the infrastructure, XSD, processors, runtime, tests
** how to do compliance testing
** how to improve our documentation
I've listed my order of interst in these things. What do others have on their mind?
I think we should start a roadmap page to record these things so that everyone can keep track of what people have in mind. Should also include what's going on in 1.x. I'll go create one once when we have the output from this discussion
Regards
Simon
[1] http://www.mail-archive.com/dev@tuscany.apache.org/msg03700.html
Re: What to do next for the Tuscany Java SCA 2.x stream
Posted by Raymond Feng <en...@gmail.com>.
Hi, Simon.
What you listed sounds pretty good to me.
Thanks,
Raymond
From: Simon Laws
Sent: Tuesday, December 02, 2008 9:21 AM
To: dev@tuscany.apache.org
Subject: Re: What to do next for the Tuscany Java SCA 2.x stream
On Tue, Dec 2, 2008 at 6:43 AM, Raymond Feng <en...@gmail.com> wrote:
Hi,
I propose that we use the following two perspectives to drive the Tuscany Java SCA 2.x stream.
1) Runtime architecture: Clean up the core set of modules as documented at [1]
* Enforce the modularity and make sure cross-module code dependencies go through proper set of SPIs
* Rationalize the core-spi which is the contract between the core and extensions (implementations and bindings).
2) SCA functionality: Provide a consistent SCA domain story for deployment (See [2], [3] and [4]).
* Use scenarios to better understand how multiple contributions are installed to a SCA domain, how cross-contribution artifact references are resolved, how nodes are configured to represent runtime capabilities and how nodes run SCA composite applications.
* Decompose the basic services related to SCA domain management and provide SPIs for these atomic operations.
[1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/OASIS+Development+Stream
[2] http://markmail.org/message/afae3zayzmpq6rx7?q=multiple+contributions+and+the+domain-level+composite&page=1&refer=qttcfwwun33gausl
[3] http://www.ibm.com/developerworks/opensource/library/ws-sca-tuscany/index.html
[4] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Distributed+Runtime
Thanks,
Raymond
Thanks Raymond
Picking up on the thread title "what to do next". It's good to set ourselves some short term targets without worrying about the full shopping list that was developing on the themes thread [1].
- I propose we define "next" as what we think we can achieve before we each go on leave for Christmas
- I agree It's important to progress both functional and non-functional objectives but there will be some overlap. Without one we can't prove the other.
- For me, these are the things that should come "Next" before we start to bring up lots of extensions
SPI (1 - non-funtional)
** Define the SPI (collect the SPI actions that have appeared on the wiki and various threads).
- I would include tidying up the providers/endpoint/builders (SL1)
** Package the SPI (I thinks this is your Enforce the modularity and make sure cross-module code dependencies go through proper set of SPIs)
Thin slice through "soup to nuts" Tuscany delivery story (1 - non functional) (SL4)
** developing core
** developing extension
** developing samples/demos
** building an releasing a distribution, how do we do this much more quickly than we do now
** using a distribution
Runtime usability story (2 functional) (SL2)
** Domain/Node - points above are comprehensive.
How to adopt OASIS spec features (2 functional) (SL3)
** what features have changed
** how to extend the infrastructure, XSD, processors, runtime, tests
** how to do compliance testing
** how to improve our documentation
I've listed my order of interst in these things. What do others have on their mind?
I think we should start a roadmap page to record these things so that everyone can keep track of what people have in mind. Should also include what's going on in 1.x. I'll go create one once when we have the output from this discussion
Regards
Simon
[1] http://www.mail-archive.com/dev@tuscany.apache.org/msg03700.html
Re: What to do next for the Tuscany Java SCA 2.x stream
Posted by Simon Laws <si...@googlemail.com>.
On Tue, Dec 2, 2008 at 6:43 AM, Raymond Feng <en...@gmail.com> wrote:
> Hi,
>
> I propose that we use the following two perspectives to drive the Tuscany
> Java SCA 2.x stream.
>
> 1) Runtime architecture: Clean up the core set of modules as documented at
> [1]
> * Enforce the modularity and make sure cross-module code dependencies go
> through proper set of SPIs
> * Rationalize the core-spi which is the contract between the core and
> extensions (implementations and bindings).
>
> 2) SCA functionality: Provide a consistent SCA domain story for deployment
> (See [2], [3] and [4]).
>
> * Use scenarios to better understand how multiple contributions are
> installed to a SCA domain, how cross-contribution artifact references are
> resolved, how nodes are configured to represent runtime capabilities and how
> nodes run SCA composite applications.
>
> * Decompose the basic services related to SCA domain management and provide
> SPIs for these atomic operations.
>
> [1]
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/OASIS+Development+Stream
>
> [2]
> http://markmail.org/message/afae3zayzmpq6rx7?q=multiple+contributions+and+the+domain-level+composite&page=1&refer=qttcfwwun33gausl
> [3]
> http://www.ibm.com/developerworks/opensource/library/ws-sca-tuscany/index.html
> [4]
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Distributed+Runtime
>
> Thanks,
> Raymond
>
Thanks Raymond
Picking up on the thread title "what to do next". It's good to set ourselves
some short term targets without worrying about the full shopping list that
was developing on the themes thread [1].
- I propose we define "next" as what we think we can achieve before we each
go on leave for Christmas
- I agree It's important to progress both functional and non-functional
objectives but there will be some overlap. Without one we can't prove the
other.
- For me, these are the things that should come "Next" before we start to
bring up lots of extensions
SPI (1 - non-funtional)
** Define the SPI (collect the SPI actions that have appeared on the wiki
and various threads).
- I would include tidying up the providers/endpoint/builders (SL1)
** Package the SPI (I thinks this is your Enforce the modularity and make
sure cross-module code dependencies go through proper set of SPIs)
Thin slice through "soup to nuts" Tuscany delivery story (1 - non
functional) (SL4)
** developing core
** developing extension
** developing samples/demos
** building an releasing a distribution, how do we do this much more
quickly than we do now
** using a distribution
Runtime usability story (2 functional) (SL2)
** Domain/Node - points above are comprehensive.
How to adopt OASIS spec features (2 functional) (SL3)
** what features have changed
** how to extend the infrastructure, XSD, processors, runtime, tests
** how to do compliance testing
** how to improve our documentation
I've listed my order of interst in these things. What do others have on
their mind?
I think we should start a roadmap page to record these things so that
everyone can keep track of what people have in mind. Should also include
what's going on in 1.x. I'll go create one once when we have the output from
this discussion
Regards
Simon
[1] http://www.mail-archive.com/dev@tuscany.apache.org/msg03700.html