Continuous Enterprise Development in Java (2014)

Preface

Simplicity is the ultimate sophistication.

— Leonardo DaVinci

Software development for the modern Web continues to evolve at a furious pace. In recent years we’ve seen the trend of client-side state move to the server, only to correct itself back again. Despite JavaScript’s 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 we’d learned, it became clear that we didn’t 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 we’ve found it makes little sense to begin our learning with the Solutions.

Instead, let’s align our start with the Problems. We’ll take a use-case–centric 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, we’ll aim to make the complicated much less so. With luck, this will empower greater productivity and enjoyment in your work.

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

Conventions Used in This Book

The following typographical conventions are used in this book:

Italic

Indicates new terms, URLs, email addresses, filenames, and file extensions.

Constant width

Used for program listings, as well as within paragraphs to refer to program elements such as variable or function names, databases, data types, environment variables, statements, and keywords.

Constant width bold

Shows commands or other text that should be typed literally by the user.

Constant width italic

Shows text that should be replaced with user-supplied values or by values determined by context.

TIP

This element signifies a tip or suggestion.

NOTE

This element signifies a general note.

WARNING

This element indicates a warning or caution.