| Section |
|---|
|
| Column |
|---|
| | Panel |
|---|
| borderColor | #C3CDA1 |
|---|
| bgColor | #ECF4D1 |
|---|
| titleBGColor | #C3CDA1 |
|---|
| title | Java SCA Roadmap |
|---|
| borderStyle | solid |
|---|
| |
| Anchor |
|---|
| About This Page |
|---|
| About This Page |
|---|
|
| Background Color |
|---|
| | About This Page |
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
Interested to help? Great! We look forward to your participation. Start by posting your thoughts on the developer mailing list. You can subscribe to the developer mailing list here | Anchor |
|---|
| Programming Model |
|---|
| Programming Model |
|---|
|
| Background Color |
|---|
| | Programming Model |
|
|
...
- Support for transaction and reliability policies
- Several users have asked for it, and there's now a public draft of the
|
|
...
- 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"
| Anchor |
|---|
| Implementation Types |
|---|
| Implementation Types |
|---|
|
| Background Color |
|---|
| | Implementation Types |
- Get implementation.bpel more spec complete
- Webapp and EJB module integration
|
|
...
...
- 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
|
|
...
- 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.
- Ability to model client side JavaScript components
Looking at the Store sample for example, I'd like to be able to model
the client Javascript as a component with SCA references to the
ShoppingCart and Catalog services, instead of manually creating JSON and
Atom client proxies in the client Javascript code.
- Support for Atom using Apache Abdera
Abdera just released their 0.3.0, I've started to look at it and it
looks pretty good. I think we should try to port our Atom/RSS binding to
it and see how it compares with the Rome library which we are currently
using.
- More modular distributions, in addition to our current all-in-one
distribution, distribute smaller packages that people can choose to
install or not?
- Some clean up of the core runtime invocation and injection mechanism,
we can probably simplify and actually remove code in a number of places 
Core:
- Separate the interface declaration (per service or reference) and
interface type (can be shared if used by multiple services or references)
and enhance the dynamic interface/operation support - Improve exception handling accross bindings
- Better support the remote case of binding.sca (marshaling/unmarshaling
data, performance optimization, propagation of callable references)
Bindings:
- Bring binding.jms to spec 1.0 level (and what about JCA as the 1.0 spec is
out?) - Add support for JSONRPC reference binding so that SCA components can talk
to JSONRPC services - Better align the WSDL2Java tools with Axis2
- Leverage the Axis2 JAX-WS metadata layer for better WSDL/Java interop and
the WSDL-less support
Tooling:
- Improve the Eclipse-based tooling support to facilitate developing and
testing Tuscany SCA Java applications.
Hosting environment:
- Further improve the Tuscany/Geronimo integration to better leverage the
SCA domain/node
A roadmap would be good, tis hard though to see beyond specific work items
to be done in the near future and to come up with broader statements for
what may happen over the coming year.
Of the things already mentioned the improvements for JSONRPC for references,
callbacks, and browser based components etc sounds really interesting and
useful. And along with items already mentioned here are some I think would
be good:
- 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
- Interoperability: Improve using sca wdsl with X language
(replace X with
java, Python, C++, ecc)
| Anchor |
|---|
| Integration with other technologies |
|---|
| Integration with other technologies |
|---|
|
| Background Color |
|---|
| | Integration with other technologies |
- 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.
- ESB connectivity, e.g. Mule, Synapse, Servicemix
- Finish off web2.0 support
- Incremental binding.ws improvements
- 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
- 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.
- More bindings suggestions on this roadmap page.
| Background Color |
|---|
| | Usability |
- Improve Website documentation. There's still lots of detail and improvements we
|
|
...
- could add to the documentation and its really important to attract users
|
|
...
- Documentation that matches releases. Right now there is only one documentation, the latest.
- Distribution improvements - conclude the ML discussion from a while back
|
|
...
- on the size and ease of use
|
|
...
- .
- Think about profiles for Tuscany SCA use.
- Improve the error reporting/handling for our data binding framework.
- Management
- Link domain/node into established management solution. New modules required management, management-wsdm, management-jmx, etc.
- Add some sort of mediation capability
|
|
A couple of other things to think about; i think would be good if we could
work a bit more together with one or two others on things instead of each of
us going off implementing something individually which i guess started
happening more as we tried to get 1.0 out quickly. I also wonder if
sometimes these days we seem to get bogged done in lots of detailed
discussion when it may be better to just let people get on with coding.
From what you mentioned, I'm very interested in the web 2.0
integration, and the ability to mashup SCA components/services using
simple SCA References concept on a web 2.0 client application.
...
- see SCA of great help to simplify exposing data as services to a
|
|
...
- client application in a simple and flexible way.
|
|
...
- Support hot deployable on contribution and composite.
This should be have a recursive algorithm to update the correlated component when it has been referenced.
...
- 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.
|
|
...
- Look into what level of integration with php SCA implementation can be achieved
|
|
