Thanks for the detailed explanation, let's go with your proposal.
Deepal
> Hi Deepal,
> Thanks for your reply. I could easily extend the patch provided by
> Nandana in AXIS2-4066
> <https://issues.apache.org/jira/browse/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
> <https://issues.apache.org/jira/browse/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="http://www.w3.org/2005/08/addressing";>
> ...
> <Identity
> xmlns="http://schemas.xmlsoap.org/ws/2006/02/addressingidentity";>
> <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 <[email protected]
> <mailto:[email protected]>> wrote:
>
> Hi Detelin,
>
> Glad to hear your interest on contributing to Axis2.
>> Hi everyone,
>> While looking into implementing AddressingAndIdentity
>>
>> <http://schemas.xmlsoap.org/ws/2004/08/addressing/addressingidentity/WS-AddressingAndIdentity.pdf>
>> support in Axis2, I noticed Nandana has already done some work in
>> this area (AXIS2-4066
>> <https://issues.apache.org/jira/browse/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
>
>
