a) Alan, while my name is on a lot of commits on this project, I'm not an expert on the further reaches of web services, and there are parts of the architecture that I've never immersed myself in. So it is entirely possible that Glen or Dan or someone will pop up any minute and show you a trail of breadcrumbs leading to just the sort of gingerbread house you are looking for.
b) My sense is as follows: a lot of people turn up here who need to make CXF talk to some bizarre legacy web service of which there is precisely one in creation. Some server, somewhere, built a long time ago, or using XFire or Axis1, which implements some SOAP-ish but not-quite-standard contract. There's just no incentive for generality in dealing with these. For your one-time-pad example, advice here would be to write an interceptor and configure it on your endpoint. That just works. No WSDL, no 'binding', just customization of CXF's behavior. CXF has a very, very, open architecture for this sort of thing; you can stick some custom code in between just about any two activities you can think of. In fact, the implementation of a custom binding, I think, would involve building the runtime function as one or more interceptors, and then adding the wiring to automate their installation. The existing bindings are implemented as interceptors that do what needs to be done. Writing 3 lines of Java to install interceptors that, for example, do your XOR, is not a big deal. On Fri, Jan 28, 2011 at 1:42 PM, Alan Egerton <egg...@gmail.com> wrote: > On Fri, Jan 28, 2011 at 3:03 PM, Benson Margulies <bimargul...@gmail.com> > wrote: >> 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. > > That certainly supports the results of my research to date, although > I'm genuinely surprised that such 'exotic' services have not been > described in WSDL (with extensions where necessary) more often. After > all, I thought that WSDL had been designed to do just that (in a > standard, machine-readable way too)! > > For example, suppose there is a web service that requires the serial > form of its many and complex XML messages to be XOR'd with a one time > pad prior to transmission as the content of an HTTP POST request or > response; many different parties might provide this same service. > Since the port type being so secured could be deeply complex, it would > be very useful (and ought to be trivial) to describe the service in > WSDL along the following lines: > > <wsdl:binding name="PerfectlySecretHTTP" type="complexPortType"> > <otp:pad codebook="bookIdentifier" wsdl:required="true"/> > <http:binding verb="POST"/> > ... > </wsdl:binding> > > Naturally, the complexity comes in implementing providers and > consumers of such a service. If I've understood you correctly, it > appears that the popular approach is to drop the WSDL altogether > (despite the tremendous advantages it could provide higher up the > stack) solely in order to implement a relatively small change to the > wire format? > >> 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. > > What makes this even more remarkable is that WSIF enabled fairly easy > development of custom "providers" for WSDL binding extensions (see > <http://ws.apache.org/wsif/developers/how_to_provider.html>) almost a > decade ago. Surely functionality of this sort has made it to CXF? > > Or, quite possibly, I've overlooked something fairly basic? > > -- Alan >
