There were several reasons:
1) When the STSClient was first developed, we wanted it to work on Java5 with
just the simple frontend. AKA: JAX-WS isn't available.
2) Supporting different namespaces - we need to support both WS-Trust 1.0
("http://schemas.xmlsoap.org/ws/2005/02/trust";) and WS-Trust 1.3
("http://docs.oasis-open.org/ws-sx/ws-trust/200512";). I didn't want to have
separate generated STSClients and objects and such for each. We likely COULD
use the transformation feature now to map from one to the other, but that
wasn't available at the time.
3) As Colm mentioned, the WSDL/Schema pretty much sucks with a lot of xsd:any
things. Thus, you would end up with a bunch of "instanceof" and casts and such
anyway.
4) We NEED to make sure the various security tokens remain as a DOM with ALL
the elements and text and attributes intact. JAXB parsing has a tendency to
discard things like white spaces and moves namespace declarations around and
such. Things like Signed SAML tokens would have their signatures broken if
that happened. I've logged some issues with JAXB around some of this and SOME
of those have been fixed, but I don't think all of them have.
Number 4 and number 2 were really the main drivers though.
Dan
On Aug 10, 2013, at 3:56 PM, Al Le <[email protected]> wrote:
> 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
--
Daniel Kulp
[email protected] - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
