Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ws Wiki" for change notification.
The following page has been changed by JeanSebastienDelfino: http://wiki.apache.org/ws/Tuscany/Tasks ------------------------------------------------------------------------------ == 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. + * Atomic component implementation extensions - * Atomic component implementation extensions - allowing people to extend Tuscany and plug in additional atomic component implementation types (Java, Javascript, other languages) + 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. * Composite component impl extensions - Same idea for composite component implementations + Same idea for composite component implementations. - Demonstrate the pluggability with a Spring composite implementation type + Demonstrate the pluggability with a Spring composite implementation type. * Protocol binding extensions - Should be very similar to the Atomic component implementation extension + Should be very similar to the Atomic component implementation extension. - Used by the Axis2, Celtix and Jsonrpc bindings + Used by the Axis2, Celtix and Jsonrpc bindings. + * Transport binding extensions - * Transport binding extensions - allowing bindings to register with multiple transports (HTTP, JMS etc.) + Allowing bindings to register with multiple transports (HTTP, JMS etc). - Used by the Axis2, Celtix and Jsonrpc bindings + Used by the Axis2, Celtix and Jsonrpc bindings. - * Data binding extensions - we want to support multiple data bindings, SDO, JaxB, ADB etc, we need an API to allow these data bindings to be plugged in and used in a uniform way. + * 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. - Handle metadata/schema registration, property configuration, serialization + Implement support for metadata/schema registration, pluggable property configuration/factories, and serialization. - Adjust the Axis2 and Celtix bindings to use this * Policy extensions? - Start with a simple Reliability policy extension, which may be used by the WS binding + Start with a simple Reliability policy extension, which may be used by the WS binding. + * Wiring extensions - * Wiring extensions - allowing additional interceptors to be contributed to the invocation chains + 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. + 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. * 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 :) + 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 :) + * Runtime configuration + Allow a system administrator to configure the extensions he wants active on a particular server. == Web Services Binding == * Test our current Web Services binding with SOAP test suites and fix the bugs that they will uncover :) - Some pretty complete test suites at http://www.whitemesa.net/ and http://www.mssoapinterop.org/ + Some pretty complete test suites are available at http://www.whitemesa.net/ and http://www.mssoapinterop.org/. - * Develop additional test cases talking to more complex services available on the web from google, ebay, amazon for example. + * Develop additional test cases talking to more complex services available. + We should try Web services from google, ebay, amazon for example. + * Code cleanup - * 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. + We need to improve exception handling, the algorithm to match WSDL operations, change calls to the assembly model to use the Context API instead. * Port the registration of the WS entry point code to the new host api * Port the WS binding implementation to the new protocol and transport binding APIs * Use the data binding API instead of hardcoding the use of SDO + * Integrate a Java2WSDL tool + And adjust the BigBank sample at least to use it. * Integrate support for WS-RM? == Container and Binding Extensions == * Java container + What else do we need to do here? * Javascript container + What do we need to here? * Web Services binding / Axis2 + Already covered above. + * Celtix bindings + Dan, can you describe what you intend to do here? * Jsonrpc binding + What do we need to here? - * Web Services binding / Celtix - * Other bindings / Celtix? == Async programming model == * Develop an Async interceptor and integrate it with the Geronimo work manager @@ -58, +73 @@ == Hosts == * Plain J2SE + What do we need to do here? Do we have enough docs describing how to set up the TuscanyRuntime? * Tomcat + Any more work here? * OSGI + Jim, do you want to add comments to this section? + + == 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? == Samples == * Improve the project structure for the samples and demos + Discussion started on the dev list for this * Add a few technology samples (async, subsystem wires) + * Add a good SDO sample * Improve bigbank and document it * Contribute other business oriented scenarios / samples? + Any ideas? and volunteers :) == Documentation == * Improve the how-to build / set-up / run samples docs
