Andrew Lee Rubinger and Aslak Knutsen - Continuous Enterprise Development in Java

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 developers 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, its 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 readingenjoy the lightweight Java EE development lifecycle!

Simplicity is the ultimate sophistication.

Leonardo DaVinci

Software development for the modern Web continues to evolve at a furious pace. In recent years weve seen the trend of client-side state move to the server, only to correct itself back again. Despite JavaScripts obvious utility, two engineers are likely to yield three opinions regarding its worthiness. HTML5 ushers an armada of rich-media and concurrency support right into the browser. The proven, 40-year-old relational data model has fallen out of vogue to defiant NoSQL systems, and our version-control stores have undergone both implementation and paradigm overhauls.

Our tools constitute an ever-changing buffet of prescriptions, and sorting through the array of options presents a dizzying exercise.

In the meantime, engineers face the same central challenges raised by building any multiuser program; we like our code elegant and maintainable. We need it to run efficiently and securely. We must assert its correctness.

In the Java space, many answers have come from a set of specifications released under the heading of the Java Enterprise Edition . The overarching goal of this effort remains: hide away the syntactic complexity inherent in software development, and attempt to provide a clean standard model upon which to build. In other words, the Java EE Platform comprises an evolving toolkit, and a fallible one at that.

So a few years back we set out to fill some of the holes left unspecified by Java EE, and ended up holding the reins to a test framework that inspired our imaginations and proved more versatile than initially envisioned. In fleshing out ideas to best share the lessons wed learned, it became clear that we didnt need to document any particular technology. Developers have been missing a cohesive map to navigate the murky waters of Java EE, its adjacent frameworks, and its services.

This text does not detail a singular specification. Those volumes may be found elsewhere, because weve found it makes little sense to begin our learning with the Solutions.

Instead, lets align our start with the Problems. Well take a use-casecentric approach to the testable development of enterprise Java, and after a bit of exploratory theory and requisite background, each chapter will tackle a single high-level issue. The solutions we propose may span from the user interface to persistent storage, touching upon a number of standards or third-party projects along the way. All examples are executable, and as proof run in production on the companion website.

The newbie should expect to meet the players in an enterprise Java system, and bring a blank repository from scratch to a fully deployed, live public application on the cloud. Coders of all stripes may find appealing approaches to testing against seed data, pushing events to the client, interacting with a distributed data grid, validating the user interface, and more.

Quite simply, well aim to make the complicated much less so. With luck, this will empower greater productivity and enjoyment in your work.

At least, thats been our experience while employing the techniques that inspired this book.