This definitely sounds like it falls really into a CXF "binding" (like the 
SOAP binding or XML binding or CORBA binding) so you have the right term.  

Honestly, there are VERY few people that have tried to extend CXF at this 
level.    For most people, they use the existing  XML or SOAP binding and then 
use a custom transport if a different transport is needed.   

The main exception to that is the CORBA binding and that MAY be the place to 
start looking.    For the most part, the BindingFactory would register an 
interceptor that would take the information from the WSDL and creates an 
XMLStreamReader/Writer that would generated the proper XML events based on the 
WSDL/Schema information.   That allows any of the databindings or similar to 
properly work with it.     Writing the readers/writers can be tricky, but if 
the format is fairly simple, definitely doable.   

Dan


On Friday 28 January 2011 1:42:28 pm Alan Egerton wrote:
> On Fri, Jan 28, 2011 at 3:03 PM, Benson Margulies <[email protected]> 
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

-- 
Daniel Kulp
[email protected]
http://dankulp.com/blog

Reply via email to