axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Suggestion for improvement in Axis2 - handling of wsdl extensibility elements
Date Wed, 23 Apr 2014 15:39:06 GMT
Hi Deepal,
   Thanks for your reply. I could easily extend the patch provided by
Nandana in AXIS2-4066
<>and it would work,
but my intention was to find a better approach for
solving this and similar requirements in the future. I will try to explain
the point using the patch in
The goal of this patch was to allow for an Axis2 module (in this case
Rampart) to contribute to a WSDL extensibility element (in this case -

For example, if an Axis2 web service secured with Rampart message-level
security, Rampart would expose the service certificate information using an
<Identity> element in the <wsa:EndpointReference> wsdl extensibility lement:

<wsdl:port name="VersionHttpSoap12Endpoint"
    <wsa10:EndpointReference xmlns:wsa10="">
        <Identity xmlns="">

For that to work, Rampart would set this information in an Axis2 service
parameter, then the AxisService2WSDL11 would check for this parameter and
generate an <Identity> element in the EPR of an <wsdl:port>.

This approach works, but it means that Axis2 wsdl generation now contains
some security-oriented code that checks for certain parameter and acts
accordingly. If any changes are needed, for example adding support for
future releases of WS-AddressingAndIdentity specification, the
AxisService2WSDL11 needs to be patched again.

IMO this would eventually lead to polluting the wsdl generation with code
which is meant to support certain WS spec that should otherwise be hosted
in an Axis2 module.

Instead, an Axis2 description instance could keep a list of WSDL
extensibility elements attached to it (similarly to the list of policy
components), then any Axis2 module could manipulate them the way it needs.
The WSDL generation would simply serialize those extensibility elements,
without caring for their content.

This design would encourage people to develop functionality for handling
custom WSDL extensibility elements as part of an Axis2 module instead of
having to contribute patches to Axis2 kernel.

Does this make sense?


On Wed, Apr 23, 2014 at 6:41 AM, Deepal jayasinghe <>wrote:

>  Hi Detelin,
> Glad to hear your interest on contributing to Axis2.
>     Hi everyone,
>     While looking into implementing AddressingAndIdentity<>support
in Axis2, I noticed Nandana has already done some work in this area
> (AXIS2-4066 <>).
>  My intention was to provide an additional patch that would handle the
> User Principal Name.
> +1.
>    However, I would really like to improve this so that any Axis2 module
> could contribute to an wsdl extensibility element.
> hmm, let's first get that in Axis2, later we can thing about that, I guess
> ?
>     For that to work, wsdl extensibility elements must become first class
> citizens in Axis2 service model.
> Not sure I really understand what you really mean, can't we get what we
> want by having that as an external module ? (merge to wooden, or as an
> Axis2 core module ?).
> Let's get a patch, so  that we can see more about what you think.
> Deepal
>    At the moment, only policy components are attached to an Axis2
> service, while the only way to configure wsdl extensibility elements is to
> use the wsdl-first approach and provide them explicitly in the original
> wsdl - in that case, an Axis2 module can modify them by looking up and
> working with the wsdl Definition instance.
>  On the other hand, one could argue that WS-Addressing metadata processing
> can become part of Axis2 core - for example, an AxisEndpoint might be
> extended with a wsa:EndpointReference getter that would provide access to
> the EndpointReference element and allow any module to modify it.
>  This might seem natural, as the Axis2 kernel already handles
> addressing-specific metadata internally (see
> AxisService2WSDL11.generateEPRElement), however this would only solve this
> particular use case rather than solving it for any similar requirement.
>  I would be interested in getting some feedback on this - could be that
> there are other potential solutions to this issue which I have missed.
> Thanks,
>      Detelin

View raw message