Changed the mailing list to something more appropriate... After further thinking I realised that I don't actually want to do exactly as what would be achieved with a spring int custom transport (at least not the destination component)
First of all, all of my web service methods will be one way, so I don't need to deal with a reply to channel or anything. What I actually want to do is this: CLIENT ----------------------------------------------------------------- jaxws:client -> spring integration channel -> https This could be achieved with a custom conduit with a client address of: spring-int://channel/somechannel The end of the channel would need to be a outgoing http outgoing gateway or something. However if I instead implemented: spring integration gateway (implementing the service interface) -> spring integration channel -> jaxws:client I would not have to worry about a http outgoing gateway ENDPOINT (SERVICE) -------------------------------------------------------------- For Service: jaxws:endpoint -> spring integration pollable channel -> service impl This would not be catered for by a destination as I still want to use the Jetty front end for the jaxws:endpoint but instead of passing the call directly onto the service impl, I want it to be stored into a message channel and at some later point the service impl would be executed. CUSTOM SERVICE ACTIVATOR / MESSAGE HANDLER ------------------------------------------------------------------------------------ So really what I need to do in both cases I think is a custom message handler that can figure out what service method to implement based on the message and header content. Since I will be persisting to a db in the integration channel I will also need to figure out how to either unmarshal the correct JAXB from the serialised XML or instead use java serialisation of the jaxb objects. Then I will need an enhanced service activator that can execute the correct method on the jaxws:client or the service impl as appropriate. On Fri, Apr 12, 2013 at 1:26 PM, Jason Pell <[email protected]> wrote: > I can see what you were getting at, and that certainly makes sense. I > guess I can model this on the camel transport. > > > http://camel.apache.org/better-jms-transport-for-cxf-webservice-using-apache-camel.html > http://camel.apache.org/camel-transport-for-cxf.html > > I might spend some time on this and see how difficult it would be. > > > On Fri, Apr 12, 2013 at 1:19 PM, Jason Pell <[email protected]> wrote: > >> Yes, >> >> I also realised my approach will not work for multiple methods as the >> service-activator expects a method name. Back to doing more reading in the >> spring integration docs and samples. >> >> >> >> >> On Fri, Apr 12, 2013 at 1:06 PM, Willem jiang <[email protected]>wrote: >> >>> Yeah, you are not the first one who has this idea. >>> I think the easiest way is implement a transport of sprint integration, >>> you can setup the {Input|Output} channel for the conduit or destination. >>> The difficult part could how to implement the CXF Continuation API with >>> spring integration async support. >>> >>> BTW, CXF supports the Servlet3 async invocation API out of box. >>> >>> -- >>> Willem Jiang >>> >>> Red Hat, Inc. >>> FuseSource is now part of Red Hat >>> Web: http://www.fusesource.com | http://www.redhat.com >>> Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) >>> (English) >>> http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese) >>> Twitter: willemjiang >>> Weibo: 姜宁willem >>> >>> >>> >>> >>> >>> On Friday, April 12, 2013 at 8:27 AM, Jason Pell wrote: >>> >>> > Topics of interest. >>> > >>> > >>> http://cxf.547215.n5.nabble.com/re-CXF-with-Sprint-Integration-td5501007.html >>> > >>> http://cxf.547215.n5.nabble.com/CXF-embedded-within-a-SpringIntegration-Context-td5158465.html >>> > >>> > >>> > On Wed, Apr 10, 2013 at 8:25 PM, Jason Pell <[email protected](mailto: >>> [email protected])> wrote: >>> > >>> > > Is there any plans to add namespace support for jaxws endpoint and >>> client >>> > > to spring integration? >>> > > >>> > > I am envisioning ability to define jaxws:client as a gateway with a >>> queue >>> > > channel in between to provide decoupling of client from transport >>> > > >>> > > And endpoint as a end of a channel - service activator maybe. >>> > > >>> > > There is camel support for cxf not sure how that works >>> > > >>> > > I am looking at using spring integration for async support rather >>> than jms >>> >>> >>> >> >
