Woden Incubating 1.0.0 M6 Release Notes

This is the Milestone 6 (M6) release of Apache Woden.
The Milestone plan is at http://incubator.apache.org/woden/dev/1.0/milestoneplan.html.

Incubation Disclaimer

The Woden project is an effort undergoing incubation at the Apache Software Foundation (ASF), sponsored by the Apache Web Services PMC. Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF.

Key points

Milestone releases will deliver Woden functionality gradually, leading up to a 1.0 release. The objective of a 1.0 release will be to deliver a WSDL processor that fully implements the W3C WSDL 2.0 specification, including parsing WSDL 2.0 documents into the WSDL 2.0 component model and validating their syntax and semantics.

Note that the WSDL 2.0 "spec" is currently at W3C Candidate Recommendation and may move to Proposed Recommendation towards the end of 2006, then full W3C Recommendation (i.e. a specification) sometime in early 2007.

The M6 release delivers an implementation of the Woden API based on DOM and Xerces parsing and an implementation based on AXIOM and StAX parsing.

The DOM implementation of Woden has been integrated into Axis2 and SOAP messaging based on WSDL 2.0 documents was successfully tested by the WSDL 2.0 working group at a W3C Interoperability event in July 2006. Work will commence soon to integrate the AXIOM/StAX implementation of Woden into Axis2.

Some remaining objectives include converting WSDL 1.1 documents into the WSDL 2.0 component model so they can be manipulated via the Woden API, serializing Woden's WSDL object model to WSDL 2.0 documents and full support for programmatically creating and modifying WSDL 2.0 documents.

The Woden framework and programming model are similar to WSDL4J, such as the factory, reader and WSDL xml object model. Other features have been reused or adapted too, such as the extension mechanism.

What's new in this release?

This release includes the following new features:

An implementation of the Woden API based on StAX parsing and AXIOM. This implementation uses the same programming model (API) as the DOM implementation, however a different WSDLFactory implementation class is needed to instantiate the StAX/AXIOM implementation (i.e. OMWSDLFactory).
The way that elements are created and added by the Woden API has been change to better support the scoping described by the WSDL 2.0 specification. The createXXXElement factory methods on DescriptionElement have been removed and instead the addXXXElement methods present on all parent elements instantiate and add the appropriate child elements. The relevant child elements have been changed to store their name as an NCName rather than a QName, but the QName is still available via the API (i.e. derived from the target namespace).

Current Release Structure

The binary distribution contains three Woden jar files described below:

woden-api.jar - Contains only the public Woden API (not yet final). This jar is suitable for those that wish to create their own implementation of the API.
woden.jar - Contains the public Woden API (not yet final) and current DOM and AXIOM implementations.
woden-ant.jar - Contains the Ant task ValidateWSDL20.

Woden depends on the following libraries and these are included in the binary distribution:

Apache WS Commons XmlSchema 1.1 (for representing schemas in the Woden API)
Apache Xerces 2.8.1 (used by XmlSchema and by the DOM implementation of Woden)
Apache WS Commons AXIOM 1.1
Apache Commons Logging API 1.1 (used by the AXIOM implementation of Woden)
StAX 1.0.1 API and the Woodstox 3.0.1 implementation (used by the AXIOM implementation of Woden)
WSDL4J 1.6.1 (used by the standalone WSDL 1.1 conversion program)

The source distribution contains all of the Woden source code; the API source, the implementation source and the Ant tasks source. It does not contain the dependent libraries, but the build.properties file specifies where they can be obtained from.

What's still to do?

Please see a list of what we think needs doing - and please consider helping out if you're interested & able!

Work is well underway on a URL resolver mechanism.
Unit tests for the WSDL extensions are mostly complete, but tests for the core WSDL 2.0 Component model and its underlying Element model are still largely outstanding. These are still crucially important for regression testing further development and will remain a major focus item for the next milestone.
The User Guide added after M3 needs updating to reflect the functional additions up to M6.
Technical design documentation for developers needs to be created, probably on the Woden Wiki.
Integrating the stand-alone WSDL 1.1 to 2.0 converter tool into Woden to produce a Woden WSDL 2.0 object model from a parsed WSDL 1.1. document.
Validation of MEPs and extension elements (such as those for SOAP and HTTP bindings) has not yet been implemented.
Serialization (e.g. WSDLWriter) has not been implemented.
Support for non-XML Schema type systems has not yet been implemented.
See the Woden JIRA issues at http://issues.apache.org/jira/browse/Woden.
See also the Task List on the Woden wiki at http://wiki.apache.org/ws/FrontPage/Woden/TaskList.

Example Usage

   WSDLFactory factory = WSDLFactory.newInstance();
   WSDLReader reader = factory.newWSDLReader();
   reader.setFeature(ReaderFeatures.VALIDATION_FEATURE_ID, true); <-- enable WSDL 2.0 validation (optional) 
   DescriptionElement desc = reader.readWSDL(wsdlLoc);            <-- the <description> element
   Description descComp = desc.toComponent();                     <-- the Description component

A custom error handler can also be specified as follows:

   DescriptionElement desc = reader.readWSDL(wsdlLoc, handler);

WSDL can be now be parsed from a DOM Element, DOM Document or InputSource using a WSDLSource object:

   WSDLFactory factory = WSDLFactory.newInstance();
   WSDLReader reader = factory.newWSDLReader();
   reader.setFeature(WSDLReader.FEATURE_VALIDATION, true);
   WSDLSource wsdlSource = reader.createWSDLSource();
   wsdlSource.setBaseURI(wsdlURI);
   wsdlSource.setSource(docEl);
   DescriptionElement desc = reader.readWSDL(wsdlSource);
   Description descComp = desc.toComponent();

Known Problems/Issues

The "testSchemaId1G" testcase from the W3C WSDL 2.0 test suite is failing since the change to XmlSchema 1.1. This appears to be due to a fragid specified for the schemaLocation in a schema import. It requires investigation and resolving, possibly in XmlSchema rather than Woden.
The StAX/AXIOM implementation is less complete than the Xerces/DOM implementation. For example, extensions are not yet supported as this is awaiting the removal of some DOM dependencies from the Woden API. This work is underway and will be completed for Milestone 7.
Currently, the only type system supported is W3C XML Schema and this is exposed at certain points of the API (through the use of the XmlSchema interface). Later on we will consider more general, extendable support for other type systems.
There are still failures in the W3C test suite results for the Component Interchange format testing being conducted by the WSDL 2.0 Working Group. Some of these were resolved at the W3C WSDL 2.0 Interop event in early July 2006, but the remainder require investigation.
There are insufficient test cases in the test suite for M6. The suite requires more junit tests for the Woden framework and the W3C WSDL test suite is in the process of being annotated with assertions that tie each testcase to a validation rule specified in the WSDL 2.0 spec.
The current extension mechanism requires statically typed interfaces for each type of extension. This requires the client application to know each required extension and its API. Some investigation has been done on a more flexible, dynamic extension mechanism and any changes that arise from this should be delivered in M7.