Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Wiki Markup
{section:border=false}{column:width=15%}
{panel:title= Java SCA

...

Items that people think will be useful and links to detailed pages, as appropriate, containing roadmap items for each area.

Items

...

 Roadmap |borderStyle=solid|borderColor=#C3CDA1|titleBGColor=#C3CDA1|bgColor=#ECF4D1}
* [About This Page |#About This Page]
* [Programming Model|#Programming Model]
** Includes wish list for programming model and SCA Core
* [Bindings|#Bindings]
** Includes wish list for Bindings
* [Implementation Types|#Implementation Types]
** Includes wish list for Implementation Types
* [Integration with other technologies|#Integration with other technologies]
** Includes wish list for implemeting with other technologies
{panel}

h1. {anchor:About This Page}{bgcolor:#C3CDA1}About This Page{bgcolor}

This page contains a list of features that our community thinks is important to include in Tuscany Java SCA. 

Items can be linked to a more detailed Roadmap page as they are being worked on. 

*Please help to make this a live document. Thanks*

h2. Items
- Update the policy model to separate it from the assembly model [http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Policy

...

] 

- Extend the runtime wires to allow the binding to contribute wireFormat and operationSelection interceptors [http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Request+Response+Binding
  • Endpoint implementation needs fixing up to take account of this
  • Roll endpoint implementation out to services
    • Can it replace $promoted$?

...

] 
-- Endpoint implementation needs fixing up to take account of this

- Roll endpoint implementation out to services
-- Can it replace $promoted$?

- Make implementation.spring spec compliant [http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Java+SCA+-+Spring+Roadmap+Items

...

] 

- Support rpc/literal wsdl

...



- Provide first rate support for Tuscany running in OSGi container [http://cwiki.apache.org/confluence/display/TUSCANYWIKI/OSGi+Integration

...

] 

- Finish off web2.0 support

...

 
-- Atom [http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SCA+Atom+Binding+Scenarios

...

  • Support for transaction and reliability policies
    • Several users have asked for it, and there's now a public draft of the transaction policy spec

...

] 

- Support for transaction and reliability policies 
-- Several users have asked for it, and there's now a public draft of the transaction policy spec

- Webapp and EJB module integration [http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Java+EE+Integration
  • Track the OASIS work on this and implement it in parallel in Tuscany. Many users have existing J2EE EJB and EAR modules that they'll need to integrate in bigger SCA compositions. Also Webapp developers will need a non-intrusive way to wire a Webapp with other SCA components in an SCA domain.
  • Conversational and non blocking + callback programming model over Web2.0 bindings
    • Seems like a good fit with JSON for example... in particular Ajax interactions fit really well with the SCA non blocking + callback programming model.
  • Website documentation. There's still lots of detail and improvements we could add to the documentation and its really important to attract users
  • Resolve JIRAs.
  • Make releasing easier
  • Distribution improvements - conclude the ML discussion from a while back on the size and ease of use.
    • Think about profiles for Tuscany SCA use.
  • Further improve SCA policy support. Good support for things like WS-Security and WS-RM and show using Java/JMS/WS etc and all the QOS stuff really is as easy as just saying something like requires="reliability"
  • Incremental binding.ws improvements
    • MTOM
    • headers
    • REST/POX
  • clean up the WS and tooling code so we don't copy so much Axis2 code as it causes such a headache when moving up Axis2 releases and picking up Axis2 fixes
  • Get implementation.bpel more spec complete
  • Get the Geronimo integration and WAR distribution working really well and with all Tuscany extensions so you can take a Tuscany sample contribution jar and it easily runs where ever you deploy it.
  • Better integration btw script components and bindings and data bindings to show the dynamic language support really does have value - seamlessly wire up Ruby components using Hpricot for HTML processing with binding.http, JavaScript/E4X for XML manipulation with binding.ws etc
  • Add some sort of mediation capability
  • Data Integration, as I see SCA of great help to simplify exposing data as services to a client application in a simple and flexible way.
  • Improve the error reporting/handling for our data binding framework.
  • Support SDO namespace when using websservice.
    • Deploy a service to webservice,a schema file used in SDO and have sdo namespace such as commonj.sdo/java or commonj.sdo/xml,we should support the feature when parsing the wsdl.
  • Support load contribution as a osgi bundle.
  • Look into what level of integration with php SCA implementation can be achieved
  • Management
    • Link domain/node into established management solution. New modules required management, management-wsdm, management-jmx, etc.
  • implemenation.xslt

...

] 
-- Track the OASIS work on this and implement it in parallel in Tuscany. Many users have existing J2EE EJB and EAR modules that they'll need to integrate in bigger SCA compositions. Also Webapp developers will need a non-intrusive way to wire a Webapp with other SCA components in an SCA domain.

- Conversational and non blocking + callback programming model over Web2.0 bindings
-- Seems like a good fit with JSON for example... in particular Ajax interactions fit really well with the SCA non blocking + callback programming model.

- Website documentation. There's still lots of detail and improvements we could add to the documentation and its really important to attract users 

- Resolve JIRAs. 

- Make releasing easier  

- Distribution improvements - conclude the ML discussion from a while back on the size and ease of use.
-- Think about profiles for Tuscany SCA use. 

- Further improve SCA policy support. Good support for things like WS-Security and WS-RM and show using Java/JMS/WS etc and all the QOS stuff really is as easy as just saying something like requires="reliability" 

- Incremental binding.ws improvements 
-- MTOM
-- headers
-- REST/POX 

- clean up the WS and tooling code so we don't copy so much Axis2 code as it causes such a headache when moving up Axis2 releases and picking up Axis2 fixes

- Get implementation.bpel more spec complete

- Get the Geronimo integration and WAR distribution working really well and with all Tuscany extensions so you can take a Tuscany sample contribution jar and it easily runs where ever you deploy it.

- Better integration btw script components and bindings and data bindings to show the dynamic language support really does have value - seamlessly wire up Ruby components using Hpricot for HTML processing with binding.http, JavaScript/E4X for XML manipulation with binding.ws etc

- Add some sort of mediation capability

- Data Integration, as I see SCA of great help to simplify exposing data as services to a client application in a simple and flexible way.

- Improve the error reporting/handling for our data binding framework.

- Support SDO namespace when using websservice.
-- Deploy a service to webservice,a schema file used in SDO and have sdo namespace such as commonj.sdo/java or commonj.sdo/xml,we should support the feature when parsing the wsdl.

- Support load contribution as a osgi bundle.

- Look into what level of integration with php SCA implementation can be achieved

- Management
-- Link domain/node into established management solution. New modules required management, management-wsdm, management-jmx, etc.

- implemenation.xslt

- ESB connectivity, e.g. Mule, Synapse, Servicemix