Skip to content
Browse files

[3] Add Chapter 2: Enabling Technologies

  • Loading branch information...
1 parent 7732f17 commit 79fe8c286ba06377d2d3cefb3f0ccc902b98b1e6 @ALRubinger ALRubinger committed Sep 20, 2012
View
211 Chapter02-EnablingTechnologies.asciidoc
@@ -0,0 +1,211 @@
+== Enabling Technologies
+
+_"I get by with a little help from my friends." - Paul McCartney and John Lennon_
+
+There's a common misconception that the goal of a standard specification is to address _every_ problem. This couldn't be further from the truth; creating a standard is meant to address the 80% case in a manner that's been proven through experience in the field. The http://www.oracle.com/technetwork/java/javaee/downloads/index.html[Java Enterprise Edition] and its subsystems, governed by the http://www.jcp.org/en/home/index[Java Community Process] (JCP), is no exception.
+
+By its very makeup, the JCP is designed to strive for consensus among all participants in an Expert Group on a given technology. Where corporate sponsors and individual contributors disagree or determine that a feature is not yet mature enough to be adequately standardized, latitude is given to specification implementors. This helps to foster creativity and provides differentiation between vendors. In fact, on a http://java.net/projects/javaee-spec/lists/jsr342-experts/archive/2012-08/message/16[discussion regarding the Java EE7 Roadmap], Expert Group member David Blevins succinctly addressed the dynamic: "Vendors innovate, collectively we standardize."
+
+While it's not the goal of this book to provide exhaustive instruction on the complete featureset of Java EE, it is absolutely our intent to unify the development experience. Helping us along the way are a set of enabling technologies intending to smooth the rough edges of the EE Platform and fill the gaps left open by its specifications.
+
+The following open-source projects are all made freely-available for you to download, use, and modify (be sure to consult individual licensing terms).
+
+=== Bootstrapping
+
+For all the documentation surrounding Java EE and its use, the seemingly simple act of getting started gets quickly muddled:
+
+* How am I going to build my sources into deployments?
+* How should I organize my codebase?
+* How can my team best collaborate in parallel on the codebase?
+* What about libraries my code uses? How do I get those?
+
+There are a number of valid answers to each of these questions, and the flexibility of choice can easily turn into a burden. Because we'll be exploring fully-functioning examples which are intended to be reproduced in your own environment, by necessity we've had to make some decisions in the interest of keeping focus on the code as opposed to our development tools. The projects below, when combined, work very well together but are certainly not the only solutions to the bullets raised above.
+
+One approach to undertaking a new project is to first lay out the scaffolding on your local file system. This will create the structure for your source code, build descriptors, and other resources used by your project. Often this process is fairly rote, involving commands to make new directories and text files in some sensible layout. While there's no formal rule dictating how your project tree is organized, some build systems employ a convention; others instead choose to allow you total control over your project's build by encouraging you to script or otherwise instruct each build task.
+
+Our examples will be built using a _declarative build tool_ which has standard commands that do not change from project to project.
+
+==== Apache Maven
+
+image:images/ch02-enabling_technologies/maven.png["Apache Maven"]
+
+Perhaps the most prominent figure in the Java automated build tool landscape, http://maven.apache.org/[Apache Maven] positions itself as a "software project management and comprehension tool". For simplicity's sake, we may view it as a build tool; it's capable of compiling, testing, and assembling.
+
+One very nice feature of Maven is that it strives for _"convention over configuration"_. By following a set of recommended best practices, you're likely to trim down on the amount of metadata you'd otherwise need to explicitly define. Additionally, Maven actions (called _goals_) are bound to a documented http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html[lifecycle] which are common to all Maven-based projects. For instance, in order to compile, test, and package your project, the command +$> mvn package+ applies. This standardization alleviates us from having to declare or learn different build commands for each project.
+
+At the core of the Maven engine is a sophisticated _dependency management_ solution capable of resolving libraries by name from a http://search.maven.org/[Central Respoitory] (or additionally-configured repository) onto a user's local system. This feature allows us to skip the manual process of adding dependencies into our version control system, and allows us to instead fetch them on-demand as part of the build process. As an added bonus, the requisite dependencies for all projects consuming ours are well-documented and automatically fetched for us.
+
+*** INSERT IMAGE : Project A depends on B depends on C, gets all as requested from the Central Repo ***
+
+Maven is not without its detractors, however. It's been criticized for a few points, among them:
+
+* Maven Plugins versions are not bound to Maven Core versions, making guaranteed reproducible builds between different environments difficult to guarantee.
+* Project Object Model (POM, ie. +pom.xml+) syntax, the metadata describing a project's makeup, is verbose.
+* Transitive dependencies as a default trigger a lot of downloading on first build. Without care, a project may inherit more dependencies than are necessary or desired.
+* Deviation from the defined Maven standard is often difficult to reconcile.
+
+It _is_ possible to use Maven-structured repositories from outside Maven. In fact, standalone dependency manager http://ant.apache.org/ivy/[Apache Ivy] (often used in concert with task-based tool http://ant.apache.org/[Apache Ant]), does just that. Groovy-based http://www.gradle.org/[Gradle] seeks to provide the flexibity of Ant with the dpeendency management of Maven.
+
+That said, Maven continues to be a popular and widely-used tool in Java development, and will satisfy our requirements to build our examples.
+
+==== JBoss Forge
+
+image:images/ch02-enabling_technologies/forge.png["JBoss Forge"]
+
+If you've spent any time developing Java EE-based projects (or any nontrivial application, for that matter!), you've likely invested a good amount of energy in creating the project layout, defining dependencies, and informing the build system of the relevant ClassPaths to be used in compilation and execution. While Maven enables us to reduce that load as compared with undertaking project setup manually, there's typically quite a bit of boilerplate involved in the +pom.xml+ defining your requirements.
+
+http://forge.jboss.org/[JBoss Forge] offers "incremental project enhancement for Java EE". Implemented as a command shell, Forge gives us the ability to alter project files and folders. Some concrete tasks we might use Forge to handle are:
+
+* Adding _Java Persistence API_ (JPA) entities and describing their model
+* Configuring Maven dependencies
+* Setting up project scaffolding
+* Generating a view layer, reversed-engineered from a domain model
+* Deploying to an application server
+
+Because Forge is built atop a _modular, http://forge.jboss.org/plugins.html[plugin]-based architecture_, it's extensible to additional tasks that may be specific to your application.
+
+Overall, the goal of Forge is to ease project setup at all stages of development, so we'll be employing it in this text to speed along the construction of our examples.
+
+=== Version Control
+
+From the moment we collaborate on a project with others or would like to inspect the evolution of our code over time, we need some form of _version control_. Until recently, the most common paradigm for synchronizing access to a shared codebase was the _client/server_ model wherein developers may keep a local working copy and check their changes into a centralized server.
+
+*** INSERT IMAGE SHOWING CENTRALIZED VERSION CONTROL ***
+
+Some systems utilize file-level locking to ensure that no conflicts arise during development; others allow concurrent access at the file granularity but cue the developer to resolve line-level conflicts upon commiting changes upstream.
+
+Likely the widest-deployed client/server version control system (VCS) from the 1990s through the 2000s has been http://savannah.nongnu.org/projects/cvs[Concurrent Versions Systems], most often referred by its acronym _CVS_. While CVS has enabled teams to freely work on all files in the tree through _unreserved checkouts_, its shortcomings including non-atomic commits and absent tracking for file renames prompted the development of http://subversion.apache.org/[Subversion] (SVN), hier apparent to CVS. Boasting a wider featureset and greater stability as contrasted with CVS, SVN has enjoyed its reign from the mid- to late-2000s.
+
+These days, the centralized model has been superceded by _distributed version control systems_ (DVCS), which is differentiated by its ability to store the full repository including all history in any number of nodes.
+
+*** INSERT IMAGE SHOWING DVCS ***
+
+This layout creates a "pull model", where developers on a common project are given the authority over their own repository, free to incorporate changes from others (or not!). At first, this can be a confusing topic to grasp for users vested in the centralized "push model", but its our opinion that the benefits of this design easily justify the initial confusion inherent when considering many full-fledged repositories representing the same project.
+
+Some immediate gains to consider:
+
+* Repository operations such as committing and searching history are much faster
+* Network connectivity is not required to alter the respository's state
+* Every repository is a full backup of the codebase's history
+
+This is because each user is typically working on a local repository, and synchronization with a remote repository is only necessary when pushing changes to be visible by others.
+
+In this text, we'll be using the open-source DVCS _Git_.
+
+==== Git
+
+image:images/ch02-enabling_technologies/git.png["Git"]
+
+Originally developed to coordinate development of the Linux Kernel, Git is a DVCS whose usage has taken off in recent years, arguably due to the user-friendliness of the socially-aware hosting site http://www.github.com[GitHub]. In fact, this book's text and examples are https://github.com/arquillian/continuous-enterprise-development[hosted] on GitHub for all to participate.
+
+From a high-level, we've chosen Git for our projects as it enables:
+
+* True feature (topic) development. Branching is quick, easy, and cheap. You may work on feature X in isolation with the ability to put your changes _on top of_ development that may be occurring in the mainline branch.
+* Integration with 3rd-party systems built to respond to Git events. For instance, we'll be able to trigger builds and production deployments by pushing our local changes to a remote repository.
+* Rewriting of local history. Often it's handy to commit liberally, giving yourself many "save" points along the way. However, before making these (sometimes breaking) changes visible to the rest of the world, it's good practice to "squash" the mini-changes into a cohesive, singular commit. This helps keep the version history sane and facilitates later auditing if a bug should arise.
+
+Again, it is not our aim to fully delve into the mechanics of each tool we'll be employing. However, we will be issuing Git commands and explaining their use along the way. A very good reference on the myriad Git subroutines can be found in the http://git-scm.com/book[Pro Git Book] by Scott Chacon, available for free in digital editions and in print via online retailers.
+
+=== A Test Platform for Java EE
+
+Java EE 5 introduced a _POJO_ (Plain Old Java Object) programming model which freed developers from having to adhere to any particular class hierarchy for its business objects. The introduction of http://jcp.org/en/jsr/detail?id=299[Contexts and Dependency Injection] (CDI) in Java EE 6 further pushed the notion of simple business objects by providing _typesafe injection_.
+
+The benefit to objects that can be easily created using the +new+ operator is the same as their drawback; when we manually instantiate objects for use in testing, we're not dealing with the same enterprise components we have in the target runtime. An EJB becomes such only in the context of an EJB container; a Servlet is a Servlet only when created by a Servlet Container. Any time we circumvent the target runtime environment to handle object creation and wiring on our own, we're using _mock objects_.
+
+While many will advocate on the usefulness of mocks, by definition they provide an approximation of how your application will behave in a production environment. Remember that you're responsible for validating that the full bevy of code running on your servers is working as expected, including the bits you _did not write_. There are many not-so-subtle errors that may arise while leveraging the full potential of the application server in production, and it's best to be testing in an environment as close to the real thing as possible.
+
+True Java EE testing in this sense is an area left largely unspecified by the EE Platform, and we'll be examining some tools to help bridge this divide.
+
+==== Arquillian
+
+image:images/ch02-enabling_technologies/arquillian.png["Arquillian"]
+
+http://arquillian.org[Arquillian] is an innovative and highly extensible testing platform for the JVM that enables developers to easily create automated integration, functional and acceptance tests for Java middleware.
+
+Picking up where unit tests leave off, Arquillian handles all the plumbing of container management, deployment and framework initialization so you can focus on the business of writing test logic. Instead of configuring a potentially-complex test harness, Arquillian abstracts out the target runtime by:
+
+* Managing the lifecycle of the container (or containers)
+* Bundling the test case, dependent classes and resources into a ShrinkWrap archive (or archives)
+* Deploying the archive (or archives) to the container (or containers)
+* Enriching the test case by providing dependency injection and other declarative services
+* Executing the tests inside (or against) the container
+* Capturing the results and returning them to the test runner for reporting
+* To avoid introducing unnecessary complexity into the developer’s build environment, Arquillian integrates seamlessly with familiar testing frameworks (e.g., JUnit 4, TestNG 5), allowing tests to be launched using existing IDE, Ant and Maven test plugins — without any add-ons.
+
+The Arquillian project adheres to three core principles:
+
+* *Tests should be portable to any supported container*. Keeping container-specific APIs out of the tests enables developers to verify application portability by running tests in a variety of containers. It also means that lightweight containers can be used as a substitute for full containers during development.
+* *Tests should be executable from both the IDE and the build tool*. By leveraging the IDE, the developer can skip the build for a faster turnaround and has a familiar environment for debugging. These benefits shouldn’t sacrifice the ability to run the tests in continuous integration using a build tool.
+* *The platform should extend or integrate existing test frameworks*. An extensible architecture encourages reuse of existing software and fosters a unified Java testing ecosystem. Regardless of how complex it becomes, executing an Arquillian test is as simple as selecting “Run As > Test” in the IDE or executing the “test” goal from the build tool.
+
+*** NOTE: Get a better image for this
+image:images/ch02-enabling_technologies/shrinkwrap_runas_junit.png["RunAs > JUnit"]
+
+==== ShrinkWrap
+
+image:images/ch02-enabling_technologies/shrinkwrap.png["ShrinkWrap"]
+
+From the onset, ShrinkWrap was born from a need to more easily test Java Enterprise deployments. Traditionally defined as flat-file archives adhering to the ZIP standard, these have necessitated the introduction of some build step to package up all application resources. And a build step takes time:
+
+----
+$ mvn clean install
+... terrifying output trace ...
+[INFO] ------------------------------------------------------------------------
+[INFO] BUILD SUCCESS
+[INFO] ------------------------------------------------------------------------
+[INFO] Total time: 1:13.492s
+[INFO] ------------------------------------------------------------------------
+----
+
+But as developers, we live in our coding environments. Switching out of that mindset to run a build is wasteful. So we asked: "What if we could declare, in Java, an object to represent that archive?" What resulted was a Java API analouge to the "jar" tool, a virtual filesystem with an intuitive syntax.
+
+[source,java]
+----
+JavaArchive archive = ShrinkWrap.create(JavaArchive.class,"myarchive.jar")
+ .addClasses(MyClass.class, MyOtherClass.class)
+ .addResource("mystuff.properties");
+----
+
+This enables us to take advantage of the IDE’s incremental compilation features, allowing us to skip the build.
+
+*** NOTE: Get a better image for this
+image:images/ch02-enabling_technologies/shrinkwrap_incremental_compilation.png["ShrinkWrap Incremental Compilation"]
+
+This piece fulfills the design goal of Arquillian to run tests based on full-fledged deployments directly from the IDE.
+
+While ShrinkWrap is a standalone virtual filesystem, in our examples we'll be primarily exercising it as the deployment mechanism for Arquillian.
+
+=== Runtime
+
+Being simply a component model, Java EE needs a concrete implementation to provide the runtime services to our applications.
+
+==== JBoss Application Server 7
+
+image:images/ch02-enabling_technologies/jbossas7.png["JBoss AS7"]
+
+The latest community edition of the http://www.jboss.org/jbossas[JBoss Application Server 7] will be the target runtime for our examples. Written from the ground up, AS7 was designed with the following goals at the core:
+
+* *Speed*. Startup, deployment, and request processing demands leverage a concurrent state machine and constant-time ClassLoading.
+* *Efficiency*. Memory usage is kept to a minimum.
+* *Modularity*. Application libraries and server libraries are isolated from one another to avoid runtime conflicts
+* *Administration*. Centralized settings via Web Interface, HTTP, Java, and Command-Line APIs
+* *Compliance*. http://fedoraproject.org/wiki/Features/JBossAS7#Strict_Compliance[Java EE6 Full Profile Certification]
+* *Testable*. Uses Arquillian and ShrinkWrap in its own internal test suite
+
+Because a quick feedback loop is important in testing during development, the speed afforded by JBossAS7 makes it a compelling candidate for our target runtime:
+
+----
+08:23:26,759 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss AS 7.1.1.Final "Brontes" started in 1775ms - Started 133 of 208 services (74 services are passive or on-demand)
+----
+
+==== OpenShift
+
+image:images/ch02-enabling_technologies/openshift.png["OpenShift"]
+
+While getting our applications running on our own machine is a great step in developing, the beauty of the internet is that we can expose our content and services to the world at large. Until very recently, Java EE hosting typically involved a dedicated and expensive server colocated in a data center. With the rapid advent of virtualization and the Cloud, we're now able to gain public access much more easily, and at far reduced cost.
+
+OpenShift is Red Hat's free Platform as a Service (PaaS) for applications. While it supports a variety of frameworks bundled as "cartidges", we'll be using OpenShift's built-in JBossAS7 support. With just a little bit of initial setup, pushing changes from our local Git repository to the OpenShift remote will trigger a build and deployment of our application for all to see. We'll be relieved of the responsibility to obtain a server, install JBossAS, configure the networking and firewalls, or manually deploy new versions.
+
+=== On to the Code
+
+Now that we've familiarized ourselves with the technologies we'll be using throughout the exercises, let's dig in and create a new Java EE application, making it public to the world.
View
BIN images/ch02-enabling_technologies/arquillian.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN images/ch02-enabling_technologies/forge.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN images/ch02-enabling_technologies/git.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN images/ch02-enabling_technologies/jbossas7.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN images/ch02-enabling_technologies/maven.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN images/ch02-enabling_technologies/openshift.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN images/ch02-enabling_technologies/shrinkwrap.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN images/ch02-enabling_technologies/shrinkwrap_incremental_compilation.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN images/ch02-enabling_technologies/shrinkwrap_runas_junit.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.

0 comments on commit 79fe8c2

Please sign in to comment.
Something went wrong with that request. Please try again.