ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Ws Wiki] Update of "Tuscany/TuscanyJava/Tasks" by edslattery
Date Fri, 12 May 2006 09:11:37 GMT
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 edslattery:
http://wiki.apache.org/ws/Tuscany/TuscanyJava/Tasks

New page:
= 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? :)
  [[BR]]

  * '''[http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=12310210&priority=1&resolution=-1
Blockers]'''
  * '''[http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=12310210&priority=2&resolution=-1
Critical]'''
  * '''[http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=12310210&priority=3&resolution=-1
Major]'''
  * '''[http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=12310210&priority=4&resolution=-1
Minor]'''
  * '''[http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=12310210&priority=5&resolution=-1
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 @One``Way
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 Tuscany``Runtime?
  * '''[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:
    Data``Object.getChangeSummary()
    Change``Summary.isModified()
    Change``Summary.getOldSequence()
    Change``Summary.undoChanges()
    Change``Summary.getChangedObjects()
    Change``Summary.getRootObject()
  * define SDO types dynamically (programmatically) - i.e., implement the Type``Helper.define()
method
  * make Java``Generator generate code patterns without EMF dependencies
  * make Java``Generator 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 Java``2SDO generator we currently have in the sandbox?
  * '''NOTE:''' need to document, or change packaging of, features (like the Java``2SDO 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 [wiki:Self/Tuscany/GetTuscany/Linux
Linux] and [wiki:Self/Tuscany/GetTuscany/WinXP 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

Mime
View raw message