Ooops, sent too soon. Continued at the bottom. On Fri, Jan 28, 2011 at 7:15 AM, Benson Margulies <bimargul...@gmail.com> wrote: > Alan, > > What exactly do you mean be 'binding'? In CXF, that means the mapping > of data type parameters to and from XML, as opposed to 'front end', > which deals with message structure. It's not obvious to me what you > are counting four of. > > Our usual advice to people who need to talk to 'some weird > nonconforming thing' is to use the provider interface, not a WSDL at > all. Just use CXF to push the XML in and out. > > For a WSDL to be a viable approach, I think that the binding has to > have the character that it can be expressed in W3C XML Schema. If you > can't describe the parameters in XML Schema, i >
you would need to deal in WSDL extensions. Generally, though, the cost-benefit works like this: if you are rigging up communications with a unique legacy service, building a data binding or front-end would be an inefficient process. The value of building one of these components is reusability; if you need to talk to 27 different variations. Finally, I'd note that a lot of messages on this list discuss ways to tweak CXF so that the standard components can talk to nonstandard endpoints. Fiddling with namespaces is by far the most frequent, but many other things are possible. At the front-end level, you can grab control of many decisions by writing a class and pushing it into a property, for example. > On Fri, Jan 28, 2011 at 6:20 AM, Alan Egerton <egg...@gmail.com> wrote: >> Dear CXF Users, >> >> I am at the outset of my web service journey, but am not without some >> solid Java experience in other areas. After some research, I selected >> CXF as the framework upon which to base further exploration primarily >> due to its good Spring integration—but also because I can envisage >> going down the ESB path in the future and ServiceMix integration >> appears stable and mature. >> >> One of my first WS-* projects is to generate a (Java) client for a >> WSDL contract where the binding is not one of CXF's supported four. I >> had half-expected that custom bindings might (however unwelcome) be >> fairly commonplace given the existence of historical projects based on >> proprietary protocols, but a day spent with Google has yielded >> surprisingly little fruit. >> >> Indeed, the only ready-made solution that I can find is WSIF >> <http://ws.apache.org/wsif/>, but this project has been inactive for >> many years and is currently being moved to the Apache Attic. >> >> It appears that I have three choices and I would greatly appreciate >> any insight you might be able to share towards my evaluation of the >> relative merits/demerits of each approach. >> >> (i) add support for my required binding to CXF (or, better yet, enable >> CXF to load providers of custom bindings at runtime); >> >> (ii) generate the client implementation manually; or >> >> (iii) use an alternative framework (e.g. WSIF, albeit not maintained). >> >> Incidentally, in playing around with wsdl2java I edited the contract >> to use the pure XML binding instead (i.e. from the >> http://cxf.apache.org/bindings/xformat namespace) but it continues to >> fail with the error "WSIBP Validator found <binding> is NOT a SOAP >> binding". Does wsdl2java not support CXF's other bindings? >> >> Cheers, >> -- Alan >> >
