Hi Jackey- servicemix-http passes the message to another JBI compliant SU in the form of a MessageExchange, so you would be working with the message in a raw XML format. Something like sm-http -> sm-bean -- the bean would have to pull the message out of the exchange object as a raw xml string before working with it. It is also handy for tying to other out-of-the-box components.
servicemix-cxf-bc is generally paired with the servicemix-cxf-se, and the cxf-se engine automatically processes the message, converts to the plain java beans as defined by the XML Schema and passes them into the Impl class that implements all the methods as defined by the operations in the WSDL. This is handy for the straight web service <-> database type service where you just want to expose an API for objects in a database. Haven't worked with servicemix-jms, but I imagine that it just sticks the message on a queue or topic for you, so there is no coding required. The idea of having all three is to provide flexibility and maximum integration capability with as little effort as possible. For example, if you had an existing JMS implementation, you would want to use servicemix-jms to expose services as a Web Service. Also, you have a WS exposed and need to transform the message to send to another web service, you could do a sm-http (consumer: inbound message) -> sm-saxon (XSLT transform) -> sm-http (provider: send to other web service) and not have to write a single line of Java code. Matt Pavlovich -- View this message in context: http://www.nabble.com/What%27s-the-difference-between-servicemix-cxf-bc-and-servicemix-http%2C-servicemix-JMS-tp16347193s12049p16351011.html Sent from the ServiceMix - User mailing list archive at Nabble.com.
