The creation of the STSClient code was before my time at CXF and so I can
only guess at the reasons. The main reason I suspect that it was
implemented the way it was, is that the WS-Trust spec imposes almost no
restrictions on the structure of the requests, and hence working from types
generated from a WSDL would largely be meaningless. For example, a
"request" is defined as:
<xs:complexType name='AbstractRequestSecurityTokenType' >
<xs:sequence>
<xs:any namespace='##any' processContents='lax' minOccurs='0'
maxOccurs='unbounded' />
</xs:sequence>
<xs:attribute name='Context' type='xs:anyURI' use='optional' />
<xs:anyAttribute namespace='##other' processContents='lax' />
</xs:complexType>
A secondary reason might have been to support the WS-MEX protocol.
Colm.
On Tue, Aug 13, 2013 at 9:15 AM, Christian Schneider <
[email protected]> wrote:
> Good question. I also wondered about this when I saw the code the first
> time.
>
> Christian
>
> Am 10.08.2013 21:56, schrieb Al Le:
>
> Hello.
>>
>> Why is the class STSClient (org.apache.cxf.ws.security.**trust.STSClient)
>> and its companion class AbstractSTSClient implemented "by hand" and not
>> e.g. using JAX-WS? The WSDL of the web service in question is available
>> (it's part of WS-Trust spec). So why create the request and read the
>> response "by hand" instead of using a typed interface to it?
>>
>> AL
>>
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
