Mule in Action, 2nd Edition – Want to be an integration developer? Here’s a good start – #bookreview


Mule in Action, Second Edition

David Dossot, John D’Emic, Victor Romero

(Manning – paperback)


An enterprise service bus (ESB) can help you link together many different types of platforms and applications–old and new–and keep them communicating and passing data between each other.

“Mule,” this book’s authors note, “is a lightweight, event-driven enterprise service bus and an integration platform and broker.  As such, it resembles more a rich and diverse toolbox than a shrink-wrapped application.”

Mule in Action, Second Edition, is a comprehensive and generally well-written overview of Mule 3 and how to put its open-source building blocks together to create integration solutions and develop them with Mule. The book provides very good focus on sending, receiving, routing, and transforming data, key aspects of an ESB.

More attention, however, could have been paid to clarity and detail in Chapter 1, the all-important chapter that helps Mule newcomers get started and enthused.

This second edition is a recent update of the 2009 first edition. Unfortunately, the Mule screens have changed a bit since the book’s screen shots were created for the new edition. Therefore, some of the how-to instructions and screen images do not match what the user now sees. This gets particularly confusing while trying to learn how to configure a JMS outbound endpoint for the first time, using Mule Studio’s graphical editor. The instructions seem insufficient, and the mismatch of screens can leave a beginner unsure how to proceed.

The same goes for configuring the message setting in the Logger element. The text instructs: “You’ll set the message attribute to print a String followed by the payload of the message, using the Mule Expression Language.” But no example is given. Fortunately, a reviewer on Amazon has posted a correct procedure. In his view, the message attribute should be: We received a message: #[message.payload]  –without any quote marks around it. (It works.)

Of course, this book is not really aimed at beginners–it’s for developers, architects, and managers (even though there will be Mule “beginners” in those ranks). Fortunately, it soon moves away from relying solely on Mule Studio’s graphical editor. The book’s examples, as the authors note, “mostly focus on the XML configurations of flows.” Thus, there are many XML code examples to work with, plus occasional screen shots of the flows as they appear in Mule Studio. And you can use other IDEs to work with the XML, if you prefer.

Indeed, the authors note, “no functionality in the CE version of Mule is dependent on Mule Studio.”

Overall, this is a very good book, and it definitely covers a lot of ground, from “discovering” Mule to becoming a Mule developer of integration applications, and using certain tools (such as business process management systems) to augment the applications you develop. I just wish a little more how-to clarity had been delivered in Chapter 1.

Si Dunn

Arquillian Testing Guide – For better integration testing & functional testing on the JVM – #programming #bookreview

Arquillian Testing Guide
John D. Ament
(Packt Publishing – Paperback, Kindle)

If you have some experience with integration testing and functional testing on a Java virtual machine (JVM), John D. Ament’s important new book can help you get up to speed with the Arquillian testing platform’s numerous features and capabilities.

Arquillian “leverages JUnit and TestNG to execute test cases against a Java container,” Ament explains. The Arquillian framework, he adds, has three major sections: “test runners (JUnit or TestNG), containers (Weld, OpenWebBeans, Tomcat, GlassFish, and so on), and test enrichers (integration of your test case into the container that your code is running in.)” Also: “ShrinkWrap is an external dependency for you to use with Arquillian; they are almost sibling projects. ShrinkWrap helps you define your deployments, and your descriptors to be loaded to the Java container you are testing against.”

Ament’s 224-page book shows how to write simple code for various Java application tests but also explains how to develop rich test cases that you can run automatically.

The author uses the JUnit test container in his examples but explains how you can use the TestNG test container, if you prefer.

While the book is aimed at readers with intermediate experience, newcomers to Java testing can learn from it, too. Before diving into the process of explaining Arquillian, Ament describes “the fundamentals of a test case,” from an Arquillian perspective, of course. And he devotes a chapter to “The Evolution of Testing,” from the early days of manually testing single units to the advent of automated testing with powerful new tools. (Manual testing, by the way, is still important and will not go away soon, Ament indicates. “There is likely no removing manual testing for functional applications,” he writes.

“Manual testing should be considered when performing user acceptance testing, where you need to validate that the application functions the way you would expect end to end. From a quality assurance standpoint, it’s the most direct way to make sure an application works the way expected.” But, he warns, “a developer shouldn’t wait until this point to begin testing….”

He also devotes a chapter to the basics and the process of container testing. “Arquilian is all about testing your code inside a container,” he says. “Containers represent what your application will run on.” His text examines each of the “three primary ways that Arquillian can interact with a container — embedded, managed, and remote.”

Embedded containers, he notes, “typically run on the same JVM as your test case. Next are managed containers, which Arquillian will start up for you during the test process and shut down after the tests are run but run in a different JVM. Finally, there are remote containers, which are assumed to be running prior to the test and will simply have deployments sent and tests executed.”

The book’s remaining chapters take the reader deeper into the testing processes and how to use of Arquillian’s features and extensions.

Arquillian is not software you can learn to use effectively in a single weekend of hacking. You must learn it by using it and using it a lot, Ament emphasizes. “Run as many tests as you can with Arquillian…[y]ou make the best use of Arquillian when you use it throughout 100 percent of your tests.”

Arquillian Testing Guide is available through several sources, including Amazon and Packt Publishing.

Si Dunn