axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Deepal jayasinghe <>
Subject Re: Suggestion for improvement in Axis2 - handling of wsdl extensibility elements
Date Thu, 24 Apr 2014 04:02:59 GMT
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="">
>             <ds:KeyInfo>
>                 <ds:X509Data>
>                     <ds:X509Certificate>MIICXTCCA...</ds:X509Certificate>
>                 </ds:X509Data>
>             </ds:KeyInfo>
>         </Identity>
>     </wsa10:EndpointReference>
> </wsdl:port>
> 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?
> Regards,
>    Detelin
> 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