pache CXF and Spring Integration

[dudleygb]

Hi all,

A colleague mentioned I should take a look at Apache CXF, but what I can tell is that Spring Integ is already wrapping the code necessary for the transports, i.e to MQ, Webservices etc. Basically by using spring Integ I dont need Aapche CXF? Am I correct in assuming? I'd like to simplify my toolset, so if I can do everything in SI, all the better

[iwein]

Apache CXF supports protocols we don't have yet. You could implement a MessageSource and a MessageHandler that delegate to a CXF component. If you go down that path please create an issue in http://jira.springframework.org/browse/SESIA so we can see if it should be added into the framework.

[Mark Fisher]

Also, we will be providing inbound Web Service support in the form of a Spring Web Services Endpoint implementation: http://jira.springframework.org/browse/INT-162

[dudleygb]

Apache CXF supports protocols we don't have yet. You could implement a MessageSource and a MessageHandler that delegate to a CXF component. If you go down that path please create an issue in http://jira.springframework.org/browse/SESIA so we can see if it should be added into the framework.

Hi Iwein,

Thanks for the response, most appreciated.
Which protocols doesnt SI have yet? Perhaps I wouldn't need them now.

[Mark Fisher]

Spring Integration provides the following in the core distribution:
* JMS
* File
* Mail
* Web Services (outbound only until 1.0.2 - likely in a few weeks)
* Stream
* RMI
* Spring's HttpInvoker
* Spring ApplicationEvents

The SI adapters extension within Spring Extensions provides FTP, and it will soon provide other protocols (for example, we have started to work on XMPP support in the sandbox).

In Spring Integration, it's also extremely trivial to add your own "adapters". Essentially, you just point to any method on any Spring-managed POJO.

As far as the Web Services support is concerned, we are using Spring-WS. In other words, our current outbound support uses the WebServiceTemplate, and the upcoming inbound support will be provided as an implementation of an endpoint.

Are you primarily interested in Web Services support (any WS-* support in particular?)... what types of requirements to do you foresee when it comes to inbound/outbound adapters?

[dudleygb]

Hi Mark,

thank again for the response.

Sounds great, I think SI actually interfaces to more useful protocols than CXF. I mean CXF can talk to CORBA, but thats something I wont use. I see you can also write WS with CXF, and its using a lot of Spring to do it. Whereas with SI, its responsibility is integration specifics, while one would use Spring WS to produce your services.

At the end of the day, we will definitely be servicing from, and delivering to, MQ series queues and Webservices mostly.
Does SI work with MQ Series easily? I've seen a lot about ActiveMQ, but the corporates all use IBM MQ Series.

The other area of concern for us is ease-of-use, marshalling and unmarshalling and transformation of messages. We foresee that our SI integration layer will handle quite large XML messages and we will definitely need a way to easily parse, unpack and transform the payloads.

There is still a strong case for us to use JCAPS, but I've been going throught the tutorials and its quite a lot of configuration and fiddling to get just a basic integration project going. I'm starting to have my doubts as to its bloatwareness. Its got great drag and drop stuff but I'm just still a little sceptical. One things for sure, I'm not going to get up and running any time soon with JCAPS,theres quite a lot to learn and concepts to get to know, before you can even start thinking about getting busy.

Basically, I'm still lost as to which decision to take, but SI is still ranking pretty high, mostly due to the fact that I can get something up and running pretty soon and its lightweight, built on proven Spring technologies. JCAPS may offer a wider functionality set, but at the end of the day, its us, you and me that has to develop this stuff and deliver a solution. I need the best tool that works, performs well and easy to maintain. So far SI still seems a good way to go.

Any advice MOST welcome!

[Mark Fisher]

It sounds like you are following the right path for well-informed decision making. There is never a one-size-fits-all answer, and those of us involved in projects do tend to be a bit biased from time to time ... so, it's good that you are considering the various options based on the needs of your particular application requirements, preferred development practices, skills of your team, etc. Drag-and-drop seems nice at first, but it's often not the most efficient when it comes to maintenance and testing. We will be providing more tools for sure, but we will always focus on developer productivity and enabling high-quality (testable!) solutions.

As far as the MQ Series/WebSphere MQ support is concerned, Spring Integration works with any JMS implementation. That means you can configure the JMS ConnectionFactory (typically administered in the container and exposed via JNDI). Should that be sufficient for your needs?