Continuous Enterprise Development in Java (Andrew Lee Rubinger and Aslak Knutsen) (Z-Library)

📄 File Format: PDF

💾 File Size: 7.2 MB

📖 Read Online ⬇️ Download

Registered users can read the full content for free

Register as a Gaohf Library member to read the complete e-book online for free and enjoy a better reading experience.

📄 Page 1

(This page has no text content)

📄 Page 2

(This page has no text content)

📄 Page 3

Andrew Lee Rubinger and Aslak Knutsen Continuous Enterprise Development in Java

📄 Page 4

Continuous Enterprise Development in Java by Andrew Lee Rubinger and Aslak Knutsen Copyright © 2014 Andrew Lee Rubinger and Aslak Knutsen. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://my.safaribooksonline.com). For more information, contact our corporate/ institutional sales department: 800-998-9938 or corporate@oreilly.com. Editors: Mike Loukides and Meghan Blanchette Production Editor: Kara Ebrahim Copyeditor: Kim Cofer Proofreader: Becca Freed Indexer: WordCo Indexing Services, Inc. Cover Designer: Randy Comer Interior Designer: David Futato Illustrator: Rebecca Demarest March 2014: First Edition Revision History for the First Edition: 2014-03-11: First release See http://oreilly.com/catalog/errata.csp?isbn=9781449328290 for release details. Nutshell Handbook, the Nutshell Handbook logo, and the O’Reilly logo are registered trademarks of O’Reilly Media, Inc. Continuous Enterprise Development in Java, the image of a Violet Turaco, and related trade dress are trademarks of O’Reilly Media, Inc. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and O’Reilly Media, Inc. was aware of a trademark claim, the designations have been printed in caps or initial caps. While every precaution has been taken in the preparation of this book, the publisher and authors assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein. ISBN: 978-1-449-32829-0 [LSI]

📄 Page 5

Table of Contents Foreword. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii Preface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix 1. Continuity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 The Zen of Prevention 1 Reactive Error Handling 1 Proactive Quality Policies 2 Software Development Processes 2 Serial Models 3 Iterative Models 3 Testing Is Development 5 Levels of Testing 5 Unit 6 Integration 7 Foundation Test Frameworks 8 JUnit 10 TestNG 12 Continuous Development 13 2. Enabling Technologies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Bootstrapping 15 Apache Maven 16 JBoss Forge 17 Version Control 18 Git 19 A Test Platform for Java EE 20 Arquillian 20 ShrinkWrap 22 ShrinkWrap Resolvers 27 iii

📄 Page 6

Experimental Features 35 Runtime 37 WildFly 37 OpenShift 38 On to the Code 38 3. Scratch to Production. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 The Development Environment 39 A New Project 40 Writing Our First Integration Test with Arquillian 48 Running the Application Locally 51 Running the Arquillian Integration Test 53 Deploying to OpenShift via JBoss Developer Studio 55 4. Requirements and the Example Application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Introducing GeekSeek 64 Featureset 64 Conceptual Data Model 65 Logical Data Model 66 Obtaining, Building, Testing, and Running GeekSeek 68 Use Cases and Chapter Guide 73 Chapter 5: Java Persistence and Relational Data 73 Chapter 6: NoSQL: Data Grids and Graph Databases 73 Chapter 7: Business Logic and the Services Layer 73 Chapter 8: REST and Addressable Services 74 Chapter 9: Security 74 Chapter 10: UI 75 Chapter 11: Assembly and Deployment 75 5. Java Persistence and Relational Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 The Relational Database Model 79 The Java Persistence API 81 POJO Entities 82 Use Cases and Requirements 83 User Perspective 84 Technical Concerns 84 Implementation 85 Entity Objects 86 Repository EJBs 90 Requirement Test Scenarios 93 Test Setup 93 iv | Table of Contents

📄 Page 7

CRUD Tests 95 6. NoSQL: Data Grids and Graph Databases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 RDBMS: Bad at Binary Data 102 Data Grids 103 RDBMS: Bad at Relationships 104 Graph Theory 105 Use Cases and Requirements 107 Implementation 107 Attachment 107 Relation 111 Requirement Test Scenarios 119 Attachment CRUD Tests 120 Transactional Integrity of Attachment Persistence 123 Validating Relationships 127 7. Business Logic and the Services Layer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 Use Cases and Requirements 132 Send Email on New User Signup 133 Implementation 134 Requirement Test Scenarios 139 A Test-Only SMTP Server 140 The Test 142 8. REST and Addressable Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 REST in Enterprise Java: The JAX-RS Specification 152 Use Cases and Requirements 154 Implementation 157 Repository Resources 157 The Representation Converter 161 The @ResourceModel 163 LinkableRepresentation 164 ResourceLink 167 Requirement Test Scenarios 168 A Black-Box Test 169 Validating the HTTP Contracts with Warp 171 Arquillian Warp 171 Test Harness Setup 173 The HTTP Contracts Test 174 9. Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 Use Cases and Requirements 178 Table of Contents | v

📄 Page 8

Implementation 178 Supporting Software 178 Requirement Test Scenarios 186 Overview 187 Setup 187 Security Tests 188 10. The User Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 Use Cases and Requirements 197 Implementation 198 Requirement Test Scenarios 201 Pure JavaScript 201 Functional Behavior 203 11. Assembly and Deployment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 Obtaining JBoss EAP 211 Running Against JBoss EAP 213 Using the EAP Remote Container 213 Using the EAP Managed Container 215 Continuous Integration and the Authoritative Build Server 218 Configuring the GeekSeek Build on CloudBees 218 Populating CloudBees Jenkins with the EAP Repository 220 Automatic Building on Git Push Events 223 Pushing to Staging and Production 224 Setting Up the OpenShift Application 224 Removing the Default OpenShift Application 227 Pushing from the CI Build Job to OpenShift 227 12. Epilogue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 vi | Table of Contents

📄 Page 9

Foreword 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 re‐ sponsibility 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 develop‐ ment cycle and attempts to install, run, and just keep it alive. Such an artificially sepa‐ rated 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 vii

📄 Page 10

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! —Adam Bien http://adam-bien.com viii | Foreword

📄 Page 11

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 effi‐ ciently 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 Plat‐ form 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. ix

📄 Page 12

This text does not detail a singular specification. Those volumes may be found else‐ where, 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 em‐ power 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 deter‐ mined by context. This element signifies a tip or suggestion. x | Preface

📄 Page 13

This element signifies a general note. This element indicates a warning or caution. Using Code Examples Supplemental material (code examples, exercises, etc.) is available for download at http://continuousdev.org. We offer a guide to get started in Chapter 4. This book is here to help you get your job done. All contents here are licensed under Creative Commons Attribution-ShareAlike 2.0 Generic, and we invite the community at large to contribute work including feature requests, typographical error corrections, and enhancements via our GitHub Issue Tracker. You may reuse any of the text or examples in compliance with the license, which requires attribution. See full license for details. An attribution usually includes the title, author, publisher, and ISBN. For example: “Continuous Enterprise Development in Java by Andrew Lee Rubinger and Aslak Knut‐ sen (O’Reilly). Copyright 2014 Andrew Lee Rubinger and Aslak Knutsen, 978-1-449-32829-0.” Safari® Books Online Safari Books Online is an on-demand digital library that delivers expert content in both book and video form from the world’s leading authors in technology and business. Technology professionals, software developers, web designers, and business and crea‐ tive professionals use Safari Books Online as their primary resource for research, prob‐ lem solving, learning, and certification training. Safari Books Online offers a range of product mixes and pricing programs for organi‐ zations, government agencies, and individuals. Subscribers have access to thousands of books, training videos, and prepublication manuscripts in one fully searchable database from publishers like O’Reilly Media, Prentice Hall Professional, Addison-Wesley Pro‐ fessional, Microsoft Press, Sams, Que, Peachpit Press, Focal Press, Cisco Press, John Wiley & Sons, Syngress, Morgan Kaufmann, IBM Redbooks, Packt, Adobe Press, FT Preface | xi

📄 Page 14

Press, Apress, Manning, New Riders, McGraw-Hill, Jones & Bartlett, Course Technol‐ ogy, and dozens more. For more information about Safari Books Online, please visit us online. How to Contact Us Please address comments and questions concerning this book to the publisher: O’Reilly Media, Inc. 1005 Gravenstein Highway North Sebastopol, CA 95472 800-998-9938 (in the United States or Canada) 707-829-0515 (international or local) 707-829-0104 (fax) We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at http://oreil.ly/continuous-enterprise. To comment or ask technical questions about this book, send email to bookques tions@oreilly.com. For more information about our books, courses, conferences, and news, see our website at http://www.oreilly.com. Find us on Facebook: http://facebook.com/oreilly Follow us on Twitter: http://twitter.com/oreillymedia Watch us on YouTube: http://www.youtube.com/oreillymedia Acknowledgments First and foremost we would like to give a huge thanks to the Arquillian community: wonderful, talented folks from around the world who have contributed their time and knowledge to help improve the project, from coding to writing to speaking to screaming on the Internet (yes, we pay attention to you). A special thank you to all the Arquillian module leads: Karel Piwko, Bartosz Majsak, Lukáš Fryč, Dan Allen, Stefan Miklosovic, Jakub Narloch, Gerhard Poul, John Ament, Jan Papousek, Bernard Labno, Ståle Pedersen, Ken Finnigan, Tolis Emmanouilidis, Ales Justin, Martin Gencur, Vineet Reynolds, Davide D’Alto, Jean Deruelle, David Blevins, Mark Struberg, Thomas Diesler, Romain Manni-Bucau, Logan McGrath, and Alexis Hassler. A big shout out to Sarah White and Cheyenne Weaver for giving us the visual identity and the storyline to play with. You make us look good! xii | Preface

📄 Page 15

And thanks to all the people who helped us throughout this book, correcting and com‐ menting on the content. Thanks to Meghan Blanchette for being so persistent on pushing us back to work. This probably (definitely) would never have reached revision if you hadn’t! And last but not least, a big thanks to our friend in code Adam Bien for the foreword. This book is for the community from which our work was born, raised, and continues to evolve. Preface | xiii

📄 Page 16

(This page has no text content)

📄 Page 17

CHAPTER 1 Continuity If everyone is moving forward together, then success takes care of itself. — Henry Ford The Zen of Prevention At times it may feel that the universe mischievously conspires to destroy our work. And to some extent this is true: nature doesn’t like order. This entropy manifests itself in many ways: we open a network socket, a router may fail. We write to a file, the disk could fill up. We fail to check for valid inputs, our program could blow up unexpectedly. Causes of potential failure are both infinite and inevitable. As guardians of our own code quality, we’re armed with two battle tactics: Be reactive, or be proactive. Reactive Error Handling Colloquially referred to as “firefighting,” a reactive position calls us to action. In most cases, an undesirable situation has already presented itself, and now we’re charged with fixing: 1. The initial cause of the error, if under our control 2. The unprotected areas of code that allowed the cause to wreak greater havoc 3. Any resultant artifacts that persist after the error is encountered Anyone who’s rifled through a database’s binary logfile to restore data to a consistent state can attest to the stressful waste of time incurred in handling emergency situations after a breach in expected execution. Dealing with issues as they arise also imposes a sense of immediacy; the activities of a normal workday may be suspended to address more pressing concerns. 1

📄 Page 18

Clearly, the reactive model is not our best option if it can be avoided. Proactive Quality Policies “Only YOU can prevent … fires” has been the plea of the United States Forest Service since 1947, underscoring the importance of limiting factors that contribute to disaster before they happen. Related to the prevention of errors is the issue of containment. In the case of failure we’d like to know as soon as possible and handle the problem prior to its leaking into other areas of the system, where it might cause greater harm. Consider this simple bit of code: public String welcome(String name) { return "Hello, " + name; } Assume a user were to accidentally pass null into the welcome(String) method. The String returned would be: Hello, null This is because the Java Language Specification Version 7 states in 15.18.1 that concat‐ enation with a single String operand will result in string conversion upon the other operand. The null pointer is therefore represented as the String “null” according to the rules dictated by 5.1.11. Likely this isn’t the result we’d been expecting, but we’ve put ourselves in this position because we didn’t code defensively. Enhancing the welcome(String) method to perform a precondition check would raise an Exception to the user and prohibit further normal execution flow: public String welcome(String name) { if (name == null || name.isEmpty()) { throw new IllegalArgumentException("name must be specified"); } return "Hello, " + name; } This fail-fast policy is equally as important at runtime as it is during development. Knowing how to limit our exposure to error remains a topic of vast research and re‐ finement. Luckily, the study of the software development process provides us with a number of models upon which we may base our own practices. Software Development Processes Methodology. Doctrine. Paradigm. Whatever we call it, our process (or absence of one!) is the script we follow on a day-to-day basis that guides our approach to building software. Typically inspired by the central themes we believe contribute to quality and 2 | Chapter 1: Continuity

📄 Page 19

efficiency, a model for development workflow may be a powerful tool in keeping you and your team from heading down an unproductive path. Many well-documented ap‐ proaches exist, and knowing their motivations can help inform your own decisions in choosing a sensible model for your project. Serial Models A serial, or sequential, process follows a linear path from project inception to comple‐ tion. As each stage in the development lifecycle comes to a close, the next one in turn is started. Prior stages are typically not revisited, and this model is often visualized as a series of steps, as illustrated in Figure 1-1. Figure 1-1. Waterfall Model Development flows from one stage to the next, forming the basis for the nickname “Waterfall,” often associated with serial models. Also called “Big Design Up Front,” this process relies heavily upon a full understanding of all requirements from the project onset. The general theory supporting Waterfall Design is roughly “measure twice, cut once”: by doing an exhaustive evaluation of all moving parts, the goal is to reduce wasted time by avoiding the need to go back and make corrections. In our opinion, this tack is best applied for projects with a long development cycle targeting a single release. Though this might fit the retail software mold, the never-go-back mentality of a serial process makes it a particularly brittle approach to building adaptable code; the model is not designed to support changing requirements. For that, we might be better served by looking to a more random-access model where any development phase may be re‐ visited (or many may be in-process at the same time!). Iterative Models In stark contrast to the linear workflow prescribed by the Waterfall Model, there exists a suite of well-known iterative designs built to encourage change and promote paral‐ lelism. By decomposing a large problem into more manageable components, we grant ourselves the option to solve each piece independently. Additionally, we might opt to take broad swipes on a first pass, further refining our solutions in repeated cycles; this is where “iterative” processes obtain their name. Software Development Processes | 3

📄 Page 20

Extreme Programming Also known simply as “XP,” Extreme Programming is a discipline that introduces a feedback loop into each phase of the development process. A practice that rose to pop‐ ularity especially in the late ’90s and early 2000s, XP lauds communication and other social aspects as centrally important themes. Figure 1-2 illustrates a typical workflow. Figure 1-2. Iterative feedback loops in Extreme Programming While the full reasoning behind XP is detailed by Kent Beck’s Extreme Programming Explained: Embrace Change, Second Edition (Addison-Wesley, 2004), some of its pri‐ mary tenets can be boiled down to: • Short development cycles • Daily, brief meetings • Pair Programming, Team Ownership, and Accountability • Doing only what needs to be done now, deferring nonessential work until later • Garnering feedback from all stakeholders, not only programmers, early and often • Test-Driven Development — The approach of first writing automated tests, then correcting/augmenting main code until it passes In fact, XP, along with other models, has both inspired and acts as an implementation of a larger collection of iterative policies as outlined by the Manifesto for Agile Software Development. 4 | Chapter 1: Continuity