Continuous Enterprise Development in Java (2014)

Foreword

Adam Bien

http://adam-bien.com

Even ancient J2EE was never just about development.

From the advent of enterprise Java there has been a strictly defined holistic role concept. Component providers, assemblers, system administrators, and server providers have clear and distinct responsibilities, but these have been rarely upheld in the real world. Because of politics and organizational structures, often the developer assumes the responsibility of all these roles, with the possible exception of system administration and operations. The developer’s main goal is development, and the well-intentioned role separation collapses quickly.

In the “real world,” a dedicated operations department takes the results of the development cycle and attempts to install, run, and just keep it alive. Such an artificially separated model works, but is far away from being optimal. Sometimes it gets even worse, and signing off documents becomes more important than software quality.

If you are only interested in quick hacks, you will hate Java EE, application servers, and probably this book altogether. Packaging, deployment, monitoring, and management sounds like bloat and is bloat, if you are only focusing on development.

However the “DevOps” movement also considers operations and development as a single unit. Who needs beautiful code that cannot be properly installed in a predefined environment? DevOps is nothing groundbreaking; rather, it’s a “back to the roots” movement.

This book is not just compatible with the “DevOps” ideals; it pragmatically shows how to build a Java EE application from scratch and also patches holes in the Java EE spec. Automation of project and archive creation, pragmatic integration of Maven builds into the process, and testing on all levels are deeply explained with concrete code. Rather than focusing on best-case scenarios, this book shows you how to test the inconvenient, including examples with SMTP servers or Message Driven Beans.

Although the tools, libraries, and frameworks introduced in this book were initiated by Red Hat employees, this book will be equally valuable for you if you are not using JBoss or WildFly at all. In fact, I used Arquillian, ShrinkWrap, and Forge to test applications on GlassFish and TomEE at the same time. Also, in my workshops I use Arquillian to test plug-ins, extensions, and sophisticated dependency injection without deploying mocks to a production archive.

It was fun to read this book on the flight to JavaOne 2013 in San Francisco; I learned a lot. I wish you happy reading—enjoy the lightweight Java EE development lifecycle!