Continuous Enterprise Development in Java (2014)
Simplicity is the ultimate sophistication.
— Leonardo DaVinci
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:
Indicates new terms, URLs, email addresses, filenames, and file extensions.
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.
This element signifies a tip or suggestion.
This element signifies a general note.
This element indicates a warning or caution.