There seems to be no term of art so simple that the web service community can't make a ambiguity of it.
OK, then ... The two CXF things I mentioned ... front end and data binding ... are neither of them 1-1 with the WSDL binding concept you reference. In my time on the project, I can't remember anyone come through here looking to deal with an 'exotic' binding at this level. So, while on the one hand, soap bindings are just another class hierarchy in CXF, I don't feel at all confident in asserting that you can just knock off a new one and expect it to work. If things work as usual around here, presently Dan will turn up in this conversation, so I'll stop here before I write anything completely out to lunch. On Fri, Jan 28, 2011 at 9:35 AM, Alan Egerton <egg...@gmail.com> wrote: > Hi Benson, > > Thank you for your reply. I have made some comments inline below: > >> 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. > > Apologies for the ambiguity: I meant WSDL bindings which, if I > understand correctly, express the serialization of messages for the > wire. From what you say, this is the 'front end' in CXF's > terminology? > > According to <http://cxf.apache.org/docs/wsdl-bindings.html>, CXF > supports four such bindings / 'front ends': MTOM, Pure XML, SOAP 1.1 > and SOAP 1.2. > >> 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. > > Thanks, I'll look into this. > >> 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. > > Indeed, perhaps this is the source of the original confusion: the > contract in question is indeed using WSDL extensions—but it had not > quite clicked. I will dig around on this subject. > >> 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. > > Actually, it's more of an academic exercise to try and familiarise > myself with some of the more obscure features of WSDL. A baptism by > fire, if you will. > >> 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. > > Sounds like I have a lot more reading to do over the weekend! > > Thank you again for all your help. > > -- Alexi >
