Hi Willem and Claus, if you are interested I can prepare a SoapJaxbDataFormat. I propose to add it to the camel-jaxb component.
I think the goal must be to stay with really easy stuff. For everything more complex CXF is the much better solution. On the other hand I also try to understand what the core of the problem is. Perhaps we can also simplify CXF for some smaller cases so it is easier to setup and uses less dependencies. Greetings Christian Christian Schneider Team Handel und Risikomanagement Informationsverarbeitung Business Solutions Trading EnBW Systeme Infrastruktur Support GmbH Informationsverarbeitung Business Solutions Handel und Dispatching Durlacher Allee 93 76131 Karlsruhe Tel : +49-(0)721-63-15482 Mail: christian.schnei...@enbw.com Sitz der Gesellschaft: Karlsruhe Handelsregister: Amtsgericht Mannheim HRB 108550 Vorsitzender des Aufsichtsrats: Dr. Bernhard Beck Geschäftsführer: Jochen Adenau, Dr. Peter Krampf -----Ursprüngliche Nachricht----- Von: Willem Jiang [mailto:willem.ji...@gmail.com] Gesendet: Mittwoch, 20. Januar 2010 15:47 An: users@camel.apache.org Betreff: Re: Easy One way soap services Maybe we can add a SOAP data formate to deal with the soap envelop out of box. BTW, It could be easy to just take off or put on the soap envelop. But if there any WS* work involved, you had to switch to more flexible way ( to use camel-cxf component). Willem Claus Ibsen wrote: > On Wed, Jan 20, 2010 at 3:03 AM, Willem Jiang <willem.ji...@gmail.com> wrote: >> Hi Christian, >> >> Your processor implements a easy way to unmarshal the soap message. >> But I think you can leverage JAXB DataFormat to do the same thing, all you >> need to do is using a camel-xslt component for soap envelop transformation. >> > > I think if its possible to make it easier then that is good. Using > JAXB + XSLT may do the trick but it would be much easier with a data > format, a type converter or a processor etc. > > > >> Willem >> >> >> Christian Schneider wrote: >>> Hi all, >>> >>> I am thinking about how to make one way services easier. Currently I >>> generate code for the service using cxf codegen and use the camel-cxf module >>> to create a client or endpoint that can be routed over jms using the >>> camel-jms component. Using CXF for this task is a little overkill as very >>> few features of CXF are used and quite a lot of configuration has to be >>> done. I wonder if this can be done easier. >>> >>> I have experimented with a possible solution for the server part. It looks >>> like this: >>> from("jms:myqueue").process(new >>> SoapProcessor("com.example.customerservice")).to("bean:serviceHandler"); >>> >>> The idea is that a soap message for the service comes in over jms. The >>> soap processor parses the soap xml, strips the Envelope and Body and >>> unmarshals the content using JAXB. The processor needs the package name of >>> the generated stub code for the service. The advantage over using camel-cxf >>> is that there is much less configuration and you do not need cxf at runtime >>> (which means much less jars). Additionally the serviceHandler bean only >>> needs to have a method with the expected classs type as input parameter it >>> does not need to implement a service interface. I have added the code of >>> SoapProcessor to the mail as it is quite small. >>> >>> So what do you think? Does it make sense to have such small scale SOAP >>> functionality in camel? >>> I am thinking about turning my Processor into a DataFormat and provide >>> marshalling and unmarshalling. Does this make sense or is a processor >>> better? >>> >>> Greetings >>> >>> Christian >>> >> > > >
