Tasks for our May release

Here is a tentative list of tasks for our first May release.

This is NOT a project plan. This is just a tentative list of tasks for discussion on our next IRC chat

Legend:

• [IN]: We've reached a consensus that we want to do this work for our May release.

• [OUT]: We're not going to work on this for our May release.

Please don't hesitate to volunteer and add your name to the tasks you want to work on...

Outstanding JIRA issues

• We have over 100 outstanding JIRA issues, any volunteers to help fix some of these issues?
  

• Blockers

• Critical

• Major

• Minor

• Trivial

Extensibility API

• This is about improving our extensibility story. We need to simplify the APIs and mechanisms allowing people to contribute container, binding, and policy extensions to Tuscany.

  Volunteers: Jim/Jeremy, tentative date week of April 24th

• [IN] Atomic component implementation extensions

  • Allowing people to extend Tuscany and plug in additional atomic component implementation types (Java, Javascript, other languages). Replace builder registry list by a system service, separate out the creation of proxy factories in a separate builder, and adjust the existing extensions to the updated API.

• [IN] Composite component impl extensions

  • Same idea for composite component implementations. Demonstrate the pluggability with a Spring composite implementation type.

• [IN] Protocol binding extensions

  • Should be very similar to the Atomic component implementation extension. Used by the Axis2, Celtix and Jsonrpc bindings.

• [IN] Transport binding extensions

  • Allowing bindings to register with multiple transports (HTTP, JMS etc). Used by the Axis2, Celtix and Jsonrpc bindings.

• [IN resolving the problem is in, no consensus on how we resolve it] Data binding extensions

  • We want to allow multiple data bindings to be plugged into Tuscany, SDO, JaxB, ADB etc. We need an API to allow these data bindings to be plugged in and used in a uniform way. Implement support for metadata/schema registration, pluggable property configuration/factories, and serialization.

• [OUT] Policy extensions

  • Start with a simple Reliability policy extension, which may be used by the WS binding.

• [IN experimental/alpha, no or little doc] Wiring extensions

  • Allowing additional interceptors to be contributed to the invocation chains. We don't have this yet, so we need to define the API to contribute wiring extensions and how the wire builders will invoke them.

• [IN] Host integration API

  • Required by the WS bindings to install themselves in the host environment.

    Our Tomcat integration code currently hardcodes the entry point extensions, we need to clean this up

• [OUT]Runtime configuration

  • Allow a system administrator to configure the extensions he wants active on a particular server.

Container and Binding Extensions

• [IN] Java container

  • Jim/Jeremy what else do we need to do here?

• [IN] Javascript container

  • Ant what do we need to do here?

• [IN] Web Services binding / Axis2

  • Detailed in the Web Services binding section below.

• [IN] Celtix bindings

  • Dan can you describe what you're planning to do here?

• [IN experimental and incomplete for now, discussion not closed we will revisit before the release] Jsonrpc binding

  • Ant what do we need to do here?

Web Services Binding

• Volunteers: Ant, Sebastien part time, Raymond part time

• [IN] Test our current Web Services binding / Axis2 with SOAP test suites and fix the bugs that they will uncover

  • Some pretty complete test suites are available at http://www.whitemesa.net/ and http://www.mssoapinterop.org/.

• [IN need to find other web services, the ones listed here are mostly RPC/encoded] Develop additional test cases talking to more complex web services.

  • We should try Web services from Google, eBay, Amazon for example.

• [IN] Test doc-lit and doc-lit-wrapped, and combinations with one or more inlined or imported XSDs.

• [IN] Code cleanup

  • We need to improve exception handling, the algorithm to match WSDL operations, change calls to the assembly model to use the Context API instead.

• [IN] Port the registration of the WS entry point code to the new host api

• [IN] Port the WS binding implementation to the new protocol and transport binding APIs

• [not closed? databinding discussion is not closed, assume OUT for now?] Use the data binding API instead of hardcoding the use of SDO

• [IN] Integrate Java2WSDL tool

• [IN] Adjust the Bigbank sample to use the Java2WSDL tool.

  • Volunteers: Rick

• [OUT] Integrate support for WS-RM?

Async programming model

• Volunteers: Sebastien, tentative date for async interceptor April 21st, integration depends on availability of wire extensibility mechanism.

• [IN] Develop an Async interceptor and integrate it with the Geronimo work manager

• [IN] Integrate as a wire extension to get the interceptor inserted on @OneWay methods

Subsystem level wiring

• [OUT] Integrate subsystem level wiring with Web Service binding

• [OUT] Demonstrate in a new sample

Nightly builds and Distribution

• Volunteers: Raymond, Jeremy, tentative date?

• [IN] Set up continuum for regular builds

• [IN] Create a distribution

  • Consensus to include a pre-configured Tomcat in the distribution.

• [IN] Publish jars and distribution

Hosts

• [IN] Plain J2SE

  • What do we need to do here? Do we have enough docs describing how to set up the TuscanyRuntime?

• [IN] Tomcat

  • We would like to drop drop the Tomcat shallow integration (Tuscany JARs packaged with the Web apps) for this release. Will start this discussion on the dev list. We will support the Tomcat deep integration (Tuscany runtime integrated with a custom Tomcat Host implementation).

• [OUT] OSGI

  • Jim can you please add a description of this work?

SDO work

• Complete the following unimplemented methods:

  • DataObject.getChangeSummary() ChangeSummary.isModified() ChangeSummary.getOldSequence() ChangeSummary.undoChanges() ChangeSummary.getChangedObjects() ChangeSummary.getRootObject()

• define SDO types dynamically (programmatically) - i.e., implement the TypeHelper.define() method

• make JavaGenerator generate code patterns without EMF dependencies

• make JavaGenerator mangle names if generated code would otherwise not compile

• provide an SDO metadata configuration model so that static and dynamic models can be preregistered

• Integrate the Java2SDO generator we currently have in the sandbox?

• NOTE: need to document, or change packaging of, features (like the Java2SDO generator) that have Java 5 dependencies.

• Document the SDO programming model supported by this release (a tutorial doc easier to read than the spec)?

DAS work

• Convert to SDO APIs for dynamic type creation (JIRA-156)
• Use dynamic graph "root" for both static and dynamic graphs (TUSCANY-154)
• Some refactoring of the implementation classes

Samples

• [IN consensus to improve the structure, but no consensus yet on how to improve it] Improve the project structure for the samples and demos

  • Discussion started on the dev list for this, need to continue and close it

• [IN] Add a few technology samples

  • async non-blocking invocation, Volunteers: Sebastien

  • create an SDO in an SCA component without using .INSTANCE
  • usage of static and dynamic SDO

  • import of XML schema in SCDL, Volunteers: Jeremy

  • one or two Javascript samples, Volunteers: Sebastien

• Add a good SDO sample

• [IN] Improve bigbank and document it, Volunteers: Rick

• [OUT] Contribute other business oriented scenarios / samples?

Documentation

• [IN] Improve the how-to build / set-up / run samples docs

  • Volunteers: Sebastien First cut of docs posted on the Wiki, instructions available for Linux and Windows.

• [IN] Document the SCA programming model supported by this release (a tutorial doc easier to read than the spec)

  • Volunteers: Haleh with technical input from Jim, this is going to be a lot of work, any other volunteers?

• [IN] Document how to extend Tuscany

  • Volunteers: Jeremy/Jim, already started on Wiki

• [IN] Add more documentation for contributors

  • coding guidelines, Volunteers: Jim, Sebastien

  • exception handling, Volunteers: Jim

  • test cases, Volunteers: Jim

  • logging, Volunteers: Jeremy

  • how to submit patches, Volunteers: Sebastien

  • core values and rules of engagement for committers

• [IN] Document the architecture and design of the Tuscany runtime?

  • core runtime, Volunteers: Jim/Jeremy

  • assembly model, Volunteers: Sebastien

  • axis binding, Volunteers: Ant

  • java container, Volunteers: Jim

  • javascript and jsonrpc, Volunteers: Ant

Misc runtime cleanup

• Volunteers: Jim/Jeremy

• [IN already partially implemented] Cleanup the Builder registry

• [IN already partially implemented] Cleanup the WSDL registry

• [IN] Cleanup the SDO type helper registry