Thanks for the detailed explanation, let's go with your proposal.

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 AXIS2-4066. 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 - <wsa:EndpointReference>).

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" binding="ns:VersionSoap12Binding">
    <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.

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.


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.