Spring Integration In Action

[Brittany Bhadd]

NavinPillu wrote:Hi Jothi

If we map Action class in struts.xml directly then how can we say that we are integrating it with Spring. In this case what's the use of applicationContext.xml

In Struts1 we do like this only. "org.springframework.web.struts.DelegatingActionProxy" create class object using reflection. So struts.xml is used to define the path and applicationContext.xml is used to map the action class to specified path just like mentioned below.

struts-config.xml

applicationContext.xml

Could you elaborate more on this please? I've got confused now.

Thanks

Navin

Using the Spring Framework encourages developers to code using interfaces and use dependency injection (DI) to provide a Plain Old Java Object (POJO) with the dependencies it needs to perform its tasks. Spring Integration takes this concept one step further, where POJOs are wired together using a messaging paradigm and individual components may not be aware of other components in the application. Such an application is built by assembling fine-grained reusable components to form a higher level of functionality. With careful design, these flows can be modularized and also reused at an even higher level.

In addition to wiring together fine-grained components, Spring Integration provides a wide selection of channel adapters and gateways to communicate with external systems. Channel Adapters are used for one-way integration (send or receive); gateways are used for request/reply scenarios (inbound or outbound). For a full list of adapters and gateways, refer to the reference documentation.

In the following "quick start" application you can see that the same gateway interface is used to invoke two completely different service implementations. To build and run this program you will need the spring-integration-ws and spring-integration-xml modules as described above.

First of all, for full disclosure, for the last 1.5 years, I've been working as a consultant for FuseSource (now Red Hat) supporting SOA and Integration projects for large and small companies in diverse verticals from retail, shipping, banking/finance, health, etc etc. My specialty has been architecting solutions with high scalability and throughput demands using some of the best open-source projects in this space: Apache ActiveMQ, Apache Camel, Apache ServiceMix, Apache CXF, et al.

I am the author of one of the DZone Refcardz for Apache Camel titled "Apache Camel Essential Components" as well as speaker for the same titled webcast. I'm also a technical reviewer for an upcoming book on Apache Camel for Packt Publishing, which I hope to soon post about publicly.

But before I got started with FuseSource, I had experiences with other middleware integration projects -- some open-source, some commercial, but my first foray with light-weight open-source integration projects was not with Apache Camel.

I wrote blogs about Spring Integration, contributed to the user forums, contributed bug fixes and examples, etc, etc. stayed a little active in the community. I have tremendous respect for Mark, Oleg, Gary, Gunnar, et. al. for their amazing work on Spring Integration.

I liked how it extended Spring and how closely it implemented the Enterprise Integration Pattens as cataloged by Gregor Hohpe and Bobby Wolf. I used it on a few projects back then, and I firmly believe you don't get a real feel for a project unless you've used it on a real project to solve real problems. But since I've had the opportunity to use both projects deeply enough, I would like to contribute to the blogosphere my observations and opinions :)

First, there are quite a few write ups comparing the two projects. Some focus on stats like community activity or #s of components. While relevant to some extent, I'd like to go a tiny bit deeper. So the following blog post is my thoughts about Apache Camel and Spring Integration, and (spoiler alert!) why I would choose Camel for integration projects.

Both projects aim to fill similar needs: light-weight integration library with full implementations of EIPs, for mediation and routing, as well as provide abstractions on top of commonly used technologies to interface with external systems. Some common technologies include Web Services (SOAP/REST), JMS or asynchronous messaging, File-based batch systems, TCP sockets, FTP/SFTP, RDBMS and an many others. Basically whenever two heterogeneous systems need to interact, either synchronously or asynchronously, and exchange data, a light-weight integration library could help you significantly. For those of you asking "isn't that what an ESB does?".. well... kinda... but I can write about that another time.

For those of us integrating systems, we find out two things really quickly about integration. #1 it's not sexy and #2 it's difficult.

Understanding the differences in the systems, both technical as well as semantic and how it's used to implement business functions is crucial. The code that you do end up writing should be focused on those business concerns and you should leverage existing commodity components where possible. Writing code to interact with the file system, or send messages to queues is definitely considered commodity code and just adds to the code base that you'll have to maintain. If you code it by hand/roll your own, you also accept the risk of introducing bugs into areas that are not crucial to the business logic or business semantics. In my humble opinion, that's an unnecessary risk.

So that's where Apache Camel or Spring Integration come in. They help make integration projects easier by providing access to commodity components that have been vetted by the community, as well as implement common EIPs like transformations, routing, filtering, splitting/aggregating, etc... again.. vetted by the community. If you code these things by hand, good luck :) Of course it can be done, people do it all the time, but it's an unnecessary risk for most projects.

Yes, so you can think of either of these two projects as "abstractions" above specific technologies. This abstract notion allows you to focus on "what the integration is supposed to do". And in an effort to solve this question, I believe Apache Camel shines.

Integrations are read FAR MORE often than they're written .. just the same as code. So just like you aspire to write nice clean code with short functions, descriptive variables, proper levels of data hiding, etc, etc, the same is true with coding for integration projects but taken to the next level. You want to code it so you can read it and understand it. Though with integration code, the full meaning and intent of "what is being integrated" ends up lost in piles of code even if your code is written neatly. You can leverage an integration abstraction library, but as good as they are for the purposes described above, what you want is clarity to be able to answer "what is being integrated".

Apache Camel brings to the table a Domain Specific Language and I believe this is a big key difference between the two projects. Using the DSL, you can very concisely and cleanly express "what is being integrated", even in the face of moderate to complex integrations which is where other projects begin to lack clarity. Apache Camel offers DSLs in Java (my favorite), Spring XML, Scala, Blueprint-OSGI, Groovy.. and for what it's worth, even Kotlin :)

When I was using Spring Integration, they didn't have a DSL. You dealt directly with the Channels and Components (pipes and filters) using Spring XML and Channels were the main abstraction. They were working on a Scala DSL back then, but as much as I love Scala, it's still not very widely used, so for the purposes of using it on integration projects in common language or XML, there weren't many choices. Basically you hooked together endpoints like jms-gateway or http-gateway with channels and connected the other end of the channel to EIPs like Splitter or Router. But for every component you wanted to connect up, you also had to pay attention to what Channel you used what its inputs were and what outputs it had.

For example, take a look at the Cafe Spring Integration Example. This example isn't super complicated, but it illustrates what I ran into. Imagine splitting channels and components among many Spring context files and you can see how this can get quite messy.

Of course, I don't expect one to be able to pick up exactly what each example is doing without knowing or have used each of the respective libraries, but without a doubt I find reading the expressive DSL represented in the Camel DSL to be easier vs trying to interpret the SI route/flow with all of its channels. This gets me closer to "what is this integration doing" without being bogged down by details.

Another very important part to writing integration flows is testing. I won't go on my usual rant about how you'd be a fool not to test your code, but even doubly so for not testing your integrations. As complex as they can get, and the mediation that's involved, you want to verify you've got it working!!

At the time, Spring Integration didn't have any good practices for testing routes specifically. Presumably because they already have a generic test framework for Spring itself. You can get by with this for sure, because we're all used to writing unit test or integration tests with Spring and mocking out collaborators with EasyMock or Mockito, right? And if you wanted any extra capabilities you'd have to build them out yourself.

But with Apache Camel, rich testing support comes out of the box, and it's easy enough to use as to encourage testing your routes. Camel's testing framework is built on top of some of the Spring Test features, so it ends up being the best of both worlds. For example, you can mock out parts of a route that hit live systems and focus on the routing and mediation capabilities. You can set expectations and assert behaviors just like you can with Mockito, but it's built right into the library and adds additional capabilities. A colleague of mine, David Valeri has an excellent Testing and Debugging blog as well as his talk at CamelOne

3a8082e126