WSDL Extensions

Overview

The Woden API has 2 WSDL models; the Component model (org.apache.woden.wsdl20) represents the abstract WSDL component model described in the WSDL 2.0 Part 1 spec and the Element model (org.apache.woden.wsdl20.xml) represents the WSDL 2.0 XML Infoset (i.e. the XML representation of the WSDL 2.0 components described in Part 1). Both WSDL models are extensible. The Element model supports extension elements and extension attributes. The Component model supports extension components and extension properties. Extension components and properties are an abstraction of extension elements and extension attributes - i.e. WSDL Components may be extended by extension components and properties which may originate from extension elements or attributes in a WSDL document, but this distinction is not reflected in the Component model.

See the editors copy of the WSDL 2.0 Part 1 Core Language spec at: http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?content-type=text/html;%20charset=utf-8

Woden's WSDL extension architecture is based on that used in WSDL4J for handling extension elements and attributes. It has been enhanced in Woden to support Component extension properties too. Applications can follow the Woden Extension model to define WSDL extensions and register them in an extension registry. At runtime Woden will query the extension registry when it encounters unknown (i.e. non-WSDL) content and invoke any registered extension artifacts via a well defined API to handle the unknown content. These artifacts include Java classes or objects, such as serializers and deserializers and Java type mappings.

So for example, if Woden encounters some unknown content in a WSDL document (i.e. non-WSDL elements or attributes) it will check if an extension has been registered for this content and if so, will use the registered deserializer to convert the XML content into the registered Java type. A similar approach will exist for serializing Java types into extension elements or attributes. When initializing the Component model from the Element model, Woden will use registered component extensions to map the extension elements or attributes in the Element model to extension properties in the Component model.

The Woden API includes four extensions based on this extension architecture and the Woden implementation pre-registers them in the extension registry. These extensions are operation safety extension, wsdlx:safe, the operation RPC signature extenstion, wrpc:signature, the SOAP binding extensions, and HTTP binding extensions described in the WSDL 2.0 Part 2 Adjuncts spec. Applications can use this same extension architecture to create their own extensions and register them in the extension registry.

See the editors copy of the WSDL 2.0 Part 2 Adjuncts spec at: http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-adjuncts.html?content-type=text/html;%20charset=utf-8

The Woden Extension API is defined by the interfaces declared in package org.apache.woden.wsdl20.extensions. These are implemented by classes from the WSDL Element and Component models or by the extension classes themselves. These interfaces form a well defined API used by Woden to invoke extension-specific logic without the need for extension-specific additions to the Woden API. Some of these methods are discussed below.

The interfaces in package org.apache.woden.wsdl20.extensions are:

WSDL extension attributes are represented in the Woden API by the interfaces defined in package org.apache.woden.xml. These interfaces declare methods to convert the string values of XML attributes into the appropriate Java types and to query the original string value. An implementator of one of these interfaces is registered for each extension attribute and is invoked by Woden to deserialize the XML attribute into the appropriate Java type. It then stores both the original string value and the typed Java object.

The interfaces currently defined in package org.apache.woden.xml are:

The interfaces currently in org.apache.woden.xml represent just the XML types for the 'known' extension attributes, as defined for RPC signature, SOAP and HTTP bindings in the WSDL 2.0 Part 2 Adjuncts spec. Obviously, this package needs to be expanded to cater for any possible attribute types that might appear in user-defined extensions as well. There is a 'todo' in the Woden TaskList wiki page about this.

Interface Operation Extensions

The wsdlx:safe extension is contained in the following packages:

The wrpc:signature extension is contained in the following packages:

SOAP Binding Extensions

The package org.apache.woden.wsdl20.extensions.soap declares the API for SOAP binding extensions, including both the Element model extensions and the Component model extensions. The package org.apache.woden.internal.wsdl20.extensions.soap defines the implementation of that API.

SOAP extension elements and attributes (Element model)

The noarg constructor of the implementation class org.apache.woden.internal.wsdl20.extensions.PopulatedExtensionRegistry registers the SOAP binding extension elements and attributes.

The <wsdl:binding> element has 3 SOAP extension attributes, which are registered as attribute extensions of BindingElement:

The <wsdl:fault> element within <wsdl:binding> has 2 SOAP extension attributes, which are registered as attribute extensions of BindingFaultElement:

The <wsdl:operation> element within <wsdl:binding> has 2 SOAP extensions attributes, which are registered as attribute extensions of BindingOperationElement:

The <wsoap:module> extension element may appear within the binding-related WSDL elements <wsdl:binding>, <wsdl:fault>, <wsdl:input>, <wsdl:output>, <wsdl:infault>, <wsdl:outfault>. It is represented in the Element model by the interface SOAPModuleElement and in the Component model by SOAPModule. These interfaces are implemented by a single class, SOAPModuleImpl.

The <wsoap:header> extension element may appear within the binding-related WSDL elements <wsdl:fault>, <wsdl:input> and <wsdl:output>. It is represented in the Element model by the interface SOAPHeaderBlockElement and in the Component model by SOAPHeaderBlock. These interfaces are implemented by a single class, SOAPHeaderBlockImpl.

SOAP extension properties (Component model)

Each binding-related WSDL Component that is extended by SOAP properties has a corresponding subtype of the ComponentExtensions interface which encapsulates those component-specific properties.

The noarg constructor of the implementation class org.apache.woden.internal.wsdl20.extensions.PopulatedExtensionRegistry registers these SOAP component extensions.

SOAPBindingExtensions declares the SOAP properties that extend the Binding component:

SOAPBindingFaultExtensions declares the SOAP properties that extend the BindingFault component:

SOAPBindingOperationExtensions declares the SOAP properties that extend the BindingOperation component:

SOAPBindingFaultReferenceExtensions declares the SOAP properties that extend the BindingFaultReference component:

SOAPBindingMessageReferenceExtensions declares the SOAP properties that extend the BindingMessageReference component:

HTTP Binding Extensions

The HTTP Binding Extensions have not yet been developed in Woden (March 2006). This section provides guidance for creating these extensions by proposing package and interface names that follow the same conventions used for the SOAP binding extensions described above. The see Woden code for SOAP binding extensions for detailed examples.

The package org.apache.woden.wsdl20.extensions.http should be created to contain the HTTP binding extensions interfaces. The package org.apache.woden.internal.wsdl20.extensions.http should contain the implementation classes.

HTTP extension elements and attributes (Element model)

The noarg constructor of the implementation class PopulatedExtensionRegistry should register the HTTP binding extension elements and attributes, similarly to those of the SOAP binding extensions.

The <wsdl:binding> element has 4 HTTP extension attributes, which should be registered as attribute extensions of BindingElement:

The <wsdl:fault> element within <wsdl:binding> has 2 HTTP extension attributes, which should be registered as attribute extensions of BindingFaultElement:

Note: for attribute whttp:code, the class implementing IntOrTokenAttr should be called IntOrTokenAnyAttrImpl and should add the same check as per class QNameOrTokenAnyAttrImpl, which is to check for an xs:token value of #any in the convert method.

The <wsdl:operation> element within <wsdl:binding> has 7 HTTP extension attributes, which should be registered as attribute extensions of BindingOperationElement:

The <wsdl:input> and <wsdl:output> elements within binding <wsdl:operation> have 1 HTTP extension attribute, which should be registered as attribute extensions of BindingMessageReferenceElement:

The <wsdl:endpoint> element within <wsdl:service> has 2 HTTP extension attributes, which should be registered as attribute extensions of EndpointElement:

The <whttp:header> extension element may appear within the binding-related WSDL elements <wsdl:fault>, <wsdl:input> and <wsdl:output>. It should be represented in the Element model by the interface HTTPHeaderElement and in the Component model by HTTPHeader. These interfaces should be implemented by a single class, HTTPHeaderImpl.

HTTPHeaderElement should extend ExtensionElement and also AttributeExtensible and ElementExtensible (because it is itself extensible). For its method declarations, it should follow the element extension conventions used for SOAP and those used for QName dereferencing:

Note 1: the implementation class HTTPHeaderImpl should store the QName specified by the setTypeName method and its getType method should dynamically resolve this QName to an XmlSchemaType stored within TypesElement. See PropertyImpl.getConstraint() for an example.

Note 2: methods for the 'required' attribute are declared in the super interface ExtensionElement.

HTTPHeader should follow the component extension conventions used for SOAP in deriving method declarations from the HTTP Header properties:

HTTP extension properties (Component model)

Each binding-related WSDL Component that is extended by HTTP properties should have a corresponding subtype of the ComponentExtensions interface which encapsulates those component-specific properties.

The noarg constructor of the implementation class PopulatedExtensionRegistry should register these HTTP component extensions, similarly to those registered for the SOAP component extensions.

The following interfaces should be created in package org.apache.woden.wsdl20.extensions.http as subtypes of ComponentExtensions (and their implementation classes created in package org.apache.woden.internal.wsdl20.extensions.http):

HTTPBindingExtensions should be created with methods to return the HTTP properties that extend the Binding component:

HTTPBindingFaultExtensions should be created with methods to return the HTTP properties that extend the BindingFault component:

HTTPBindingOperationExtensions should be created with methods to return the HTTP properties that extend the BindingOperation component:

HTTPBindingMessageReferenceExtensions should be created with methods to return the HTTP properties that extend the BindingMessageReference component:


END of WSDL Extensions

FrontPage/Woden/WSDLExtensions (last edited 2009-09-20 22:48:52 by localhost)