Passing the Java EE 6 Enterprise Architect Certified Master Part 2 and 3 (1Z0-865 and 1Z0-866)

The "Plan"

I finally got my result for the assignment and essay tests for the Oracle Certified Master, Java EE 6 Enterprise Architect  (1Z0-865 and 1Z0-866).  I wanted to take this opportunity to share some of my experience on this endeavor.  If you want to read about part one of the certification, my notes are available here.

I downloaded my assignment on June 30th, and spent the next few days reading and re-reading the assignment.  I set myself a very aggressive (and overly optimistic) timeline to finish the assignment in 4 weeks.

Week 1

In week one I wanted to brush up on some UML, since this was weak area for me.  I used two books that were available in my local public library:

• "Fast track UML 2.0" by Kendall Scott
• "Learning UML 2.0" by Miles, Russ

I also wanted to prototype some aspects of the application.  Working with J2EE 6 is fast enough that a simple application can be created painlessly.  It was also a good opportunity to think how I would create a green field application under "perfect" circumstances, something that is rarely possible in the real world.  This prototype would also allow me to validate some of the architectural decisions.

Week 2

Continuing with the prototype, the idea was to test some of the more complicated aspects that would be required to complete the assignment.  Some of these technologies I was comfortable with, while others proved a learning experience:

• Authentication (using JASPIC)
• RMI
• JSF

Week 3

The plan was to create all of the diagrams during the third week.  For the most part the plan was to follow the diagrams as shown in "Sun Certified Enterprise Architect for Java EE Study Guide" by Mark Cade and Humphrey Sheil.

For the UML diagrams I tried free different tools:

JDeveloper

Pros: Nice looking diagrams.  Very good Java round tripping. I was already somewhat familiar with this tool, since I had used it at work to create some basic diagrams.
Cons: Not suitable to create component and deployment diagrams.  A memory hog prone to crashing every so often.

StarUML

Pros: Simple to use.
Cons: UML 2.0 support was lacking.  Some people mentioned that diagrams could be 1.x UML compliant, but I wanted to focus on 2.0 diagrams.  The diagrams were not very aesthetic.

Visual Paradigm Community Edition

Pros: Nice looking diagrams and plenty to format
Cons: The Community Edition only support one diagram per type.  This only proved to be a problem in the sequence diagrams, in which I had to create one file per diagram.

I ended up using Visual Paradigm, which proved to be the most mature free UML tool I could find.

Week 4

In week for I was hoping to review everything, create the HTML, and write the top 3 risks, and all of the assumptions.

How everything went down

All in all, my four week plan took seven weeks.  While I was able to meet most of my objectives for the first three weeks (including a mostly complete prototype), I underestimated the time required to do the diagrams.  I had to familiarize with a new tool (Visual Paradigm), and learn parts of UML that I had never learned.  As other people around the net mention, the sequence diagrams take a lot of time to complete.  The last three weeks were spent refining my design, simplifying as much as possible, ensuring that the design was elegant, and not just workable.  This required redoing some of the diagrams. I would stop working for a day or two, and then review my design from top to bottom, making changes as needed.  The more iterations, the less I was changing, until in week seven I felt comfortable with the finished product.  I submitted my assignment and signed up for the essay the very next Saturday.
As a rough estimate, I would say I spent  around 150 hours total preparing the assignment.  I could have done it in less time if had not done a prototype, and if I didn't have to try several new UML tools.
For my solution the sample shown in the Cade and Sheil book was main resource, and I can recommend it as a good concise resource.  Even though the book is targeted at SCEA 5 (OCMJEA 5), it's worth nothing that the assignment is the same  for OCMJEA 5 & 6.

I also bought the training tool from EPractizeLabs SCEA 5 Part 2 and 3 Certification Training Lab. In my particular case this tool wasn't very valuable, primarily because I bought it once I had done most of the work, so it just helped me verify that there wasn't anything else for me to do. This training lab provides more sample solutions than the single one presented in the Cade and Sheil book, but it becomes evident that in any solution you're always covering the same aspects.
I finished my certification before the " OCM Java EE 6 Enterprise Architect Exam Guide" by Allen and Bambara was available, so I do not have a comment on how useful their material is.

Looking back, my tips and recommendations

• Read and read and read the assignment until have three things clear:
• What your application needs to do: the functional requirements.
• How your application should operate.  These are the Non Functional Requirements (NFR), and includes aspects such as performance, security, availability, etc.
• What systems you have to integrate with, and how you can integrate with them.  This includes what protocol to use, async vs. sync integration, etc.
• Ensure that you implement the business object model as described in the assignment.  You can augment it, but do not change it.  If it doesn't make sense, read it again until it does.  If it still doesn't make sense, add assumptions so that it does make sense.  
• As you're designing the solution keep a list of risks and assumptions.  This will make your life much easier later on.  I did not do this so I spent a considerable amount of time going back and forth and trying to remember some of the justifications I had though about
• Keep in mind all of your NFR, and make sure you address them in your design and your assumption.  Even if you think something is obvious, write it down.  You're the architect, so everything is either something you have to design, or something you assume is already in place.  Either way, document it.  I'm talking about things like network connections, databases, external systems, clients, etc.  The NFR normally taken into account are performance, scalability, reliability, availability, maintainability, extensibility, manageability, and security.  If you need to refresh some of these concepts you can take a look at my notes for the part 1 exam.  
• If something doesn't feel right, don't be afraid to change it.  I redid my diagrams several times.  Some changes were very significant, for example changing from one technology framework to another.  Other changes were minor, such as polishing naming conventions to make it easier for the instructor to understand what I was doing.  The biggest change I did was to convert most of my business logic from Stateless Session Beans to CDI Managed Beans, since EJB provided no useful benefit to solving the problem at hand. I did keep some Message Driven Beans (MDB) and Singleton Session Beans that had specific requirements. 
• When I do an assignment I normally try to do what's required, nothing more, nothing less.  In this case in particular I did do a few extra diagrams to explain some of the trickier elements that were not evident in the required diagrams.  This included a diagram of the JMS queues, a package diagram to make it easier to understand my class diagram, and an activity diagram detailing how the chosen platform would support one the NFR.  Of course this is dependent on your solution, but I feel some extra clarification can be helpful.
• Don't be afraid to be specific.  I chose a specific Application Server (Weblogic in my case), and I justified it since it had particular features to help me meet the particular NFR of my assignment.  The same applies to the other aspects of the deployment, server specs, OS specs, database specs, security and firewalls, physical server security, application management.  Remember, you're the architect, so every detail in ensuring a successful solution is part of your job.   

The essay and the wait...

The essay part has a duration of 120 minutes, and be prepared to use all of the time.  I'm sure I could have kept going for at least a couple more hours.  If you did the assignment correctly, and addressed all of the functional and non functional requirements, you should have more than enough to fill two hours of writing.  

Be ready to justify your choice of technologies and architectures, specially compared to other technologies that could have been used in those cases.  This will show that you have a well rounded knowledge of the Java ecosystem, and can make an informed decision between all of the different frameworks out there.  This includes technologies such as persistence mechanisms (JPA, Hibernate, JDBC, NoSQL) and web frameworks (JSF, Spring MVC, Struts, etc.).  Do you need a full blown EAR vs a simple WAR?

In this part I took special care to justify what I thought was a very controversial part of my design.  I will not go into details, suffice to say that I did not have one of the pieces that is almost always present in a modern web application.  I had already justified this in my assignment, but I went the extra mile in the essay and described how I would have done it in the "traditional way" if my assumptions were not applicable.  I also explained all of the potential downsides of the "traditional way".

The grading took almost three (nerve-wrecking) weeks, but I've read of greatly varying times.  I passed with 147 out of 160 possible points, which makes me feel confident of my process.  Unfortunately the score report does not shed any light on what I could have done better.  Only time will tell how valuable this certification will be for me, but I can at least say that the learning process helped me to structure many of the activities I have already been doing, and solidified some of my weaker areas.  

If you have any questions, feel free to ask. 

And if you're on your way to become an OCM, best of lucks!

Passing the Java EE 6 Enterprise Architect Certified Master Part 1 (Exam 1Z0-807)

Last Saturday I passed the 1Z0-807 test, and I wanted to share some of my experience, specially since there seems to be little information about this test (compared to other Java certification tests at least). You can also take a look at my study notes.  You can see the my notes for part 2 & 3 here.

My total time to prepare was around 6 weeks. It was a slow time at the office, so I think I was doing around 15-20 hours of reading / studying per week.

Going into the studying phase I felt I was very weak in the EJB and JSF parts of the material, since it's not something that I actively use at work, while on the other technologies I felt I had a moderate to strong grasp on the material.

I think 6 weeks was more than enough time to prepare if you have a background working with database driven Java web applications (even if not using the full Java EE stack as in my case).  Your pace may vary, and honestly I signed up for the test before I had started studying, so the time constraint was my motivation.

Books that I read to prepare for this test:

• "The Java EE 6 Tutorial" by Eric Jendrock et al. (you can get it here) 
• "Real World Java EE Pattern" by Adam Bien (the second edition) 
• "Sun Certified Enterprise Architect for Java EE Study Guid" by Mark Cade and Humphrey Sheil 
• "Bitter Java" and "Bitter EJB" by Bruce Tate 
• "SOA in Practice" by Nicolai Josuttis

 Books that I had read in the past that helped:

• "Design Patterns: Elements of Reusable Object-Oriented Software" Erich Gamma,Richard Helm,Ralph Johnson,John Vlissides 
• "Enterprise Integration Patterns" by Gregor Hohpe 

The biggest issue I had was the lack of a proper study guide for this test.  The study guides I found were for the previous version of the test, based on Java EE 5, however most of the material is relevant.  I found the Java EE 6 tutorial very useful to make sure I figured what were the gaps that I needed to fill.  An specific guide for this test is supposed to be available very soon, so you might have better luck than I did.  If and when it becomes available, by all means read it to guide yourself.

In general I recommend getting through the material as described by the outline once, and then practicing and practicing some more.  Get as many practice questions as you can.  Some of those questions have subjective answers, but the more you practice the better chance you will have. Currently the only test simulator is from EPracticeLabs, and while not awesome I think is more than enough to make it through.

Relevant things that I found are not directly mentioned in the outline but are significant in the exam:

• Design patterns and anti-patterns (covered by the books listed above)
• Security (specially risks and how to mitigate them)
• When to use a technology. For example when to use EJB or just a web container.  When to use DAOs, JDBC, or JPA.  When to use durable subscribers in JMS.  For this I would recommend you practice until you can detect the hints that the give in the questions regarding portability, scalability, etc.

Regarding the exam itself I can point out:

• The exam was what I expected based on the practice questions I had seen. No surprise here.
• There were many scenario questions with incomplete information.  So it get's down to eliminating obvious wrong answers and then some luck picking from what's left.
• Only multiple choice questions (pick one, or pick X).  No drag and drop or anything like that.
• Time is plentiful.  The give you 150 minutes (two and a half hours).  I'm fast at taking tests, but it took me thirty minutes to do my first pass, and probably ten minutes to review.
• Some questions can get ambiguous if you over think them.  For example, one-tier is a mainframe application, two-tier is thick client, three tier is web based application.  Don't over think about a contrived three tier application with thick clients talking and sharing business logic with EJBs unless specifically told so on the questions.
• Finally, they didn't give me result right away.  They said I would get an email in 30 minutes with the result, but it arrived in a matter of five minutes or so after finishing the test.  I haven't taken an Oracle test in more than 3 years, but I don't remember this being the case.  

You can take a look my study notes below.  They do borrow material from some Java EE 5 notes that are floating around in the internet:

• http://java.boot.by/scea5-guide/
• http://rieck.dyndns.org/architecture/scea5.html

Here's the direct link to the document.

If you have any questions, feel free to add a comment and I'll try to help you.

You can now see the my notes for part 2 & 3 here.

Measuring coverage for Unit and Integration tests with Maven, Jenkins, and SonarQube

Measuring coverage for Unit and Integration tests with Maven, Jenkins, and SonarQube. This blog post provides a very simple example of integrating Maven, Jenkins, and SonarQube, in particular to properly get coverage metrics of integration tests. While the basic integration Maven, Jenkins, and SonarQube was really simple (including code coverage metrics during unit tests, getting the integration data to display in Sonar was more complicated, and required me to piece together this configuration from several posts around the internet.

These tools are very easy to install, and provide the basic framework for serious quality development. Hopefully you will find this information useful.

This tutorial assumes that you have installed and setup the following tools:

• Maven A Java build management system.
• Jenkins A continuous integration (CI) system
• SonarQube A software quality mangement system.   

If you want some pointers on getting these tools setup, you can find plenty of resources in the web:

• Maven download and installation
• Jenkins installation
• Sonar installation

Project setup 

We will start looking at the pom.xml, which is most critical part of this tutorial. If you're familiar with Jenkins a and Sonar, the rest of this tutorial might be redudant for you.
pom.xml

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>test.tutorials.multi</groupId>
    <artifactId>mod2</artifactId>
    <packaging>jar</packaging>
    <version>1.0-SNAPSHOT</version>
    <name>Coverage Maven Application</name>


    <properties>
        <sonar.jacoco.itReportPath>${env.WORKSPACE}/target/jacoco-integration.exec</sonar.jacoco.itReportPath> <!-- 1 -->
    </properties>

    <build>
        <plugins>


            <plugin>
                <groupId>org.jacoco</groupId>
                <artifactId>jacoco-maven-plugin</artifactId>
                <configuration>
                    <propertyName>jacoco.agent.argLine</propertyName> <!-- 2 -->
                    <destFile>${project.build.directory}/jacoco-integration.exec</destFile> 
                    <dataFile>${project.build.directory}/jacoco-integration.exec</dataFile> <!-- 3 -->
                </configuration>
                <executions>
                    <execution>
                        <id>agent</id>
                        <goals>
                            <goal>prepare-agent</goal> <!-- 4 -->
                        </goals>
                    </execution>
                </executions>
            </plugin>

            <plugin>
                <artifactId>maven-failsafe-plugin</artifactId>
                <version>2.6</version>
                <configuration>
                    <argLine>${jacoco.agent.argLine}</argLine> <!-- 5 -->
                    <reportsDirectory>${project.build.directory}/surefire-reports</reportsDirectory> <!-- 6 -->                 
                </configuration>
                <executions>
                    <execution>
                        <goals>
                            <goal>integration-test</goal> 
                            <goal>verify</goal> <!-- 7 -->
                        </goals>
                    </execution>
                </executions>
            </plugin>           

        </plugins>
    </build>


    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.11</version>
            <scope>test</scope>
        </dependency>

    </dependencies>

</project>

1. This property lets sonar know where to find JaCoCo reports for the integration tests. The ${env.WORKSPACE} prefix enables the Sonar plugin to find these files.
2. The JVM argument required to inject JaCoCo into the integration tests with be stored in a property named jacoco.agent.argLine .
3. The destFile and dataFile properties indicate where JaCoCo will output its files.
4. The

   prepare-agent

   goal will setup the JVM argument that we will reuse later.
5. Property will inject the required JVM arguments to enable JaCoCo integration. Since JaCoCo does instrumentation at runtime, building and injecting the proper parameters is all that's required to get coverage information.
6. Changing the reportsDirectory property is optional, and will cause the Failsafe plugin to output it's results to the same directory used by the Surefire plugin. The Surefire plugin executes Unit Tests in Maven, and it's results are read by SonarQube, and displayed as "Unit test success". Sending Failsafe's results to the Surefire report directory will trick Sonar into display the information. If you have a CI server such as Jenkins displaying this information, this "trick" might be superfluous.
7. The Failsafe plugin will run in the integration-test and verify goals.

Other than the pom.xml, the test project includes to very basic tests, a unit test, and an integration test. Each one covers 50% of the classes in the projects.  You can get the complete source code here. You will find a minimal example from which you can work up.

Setting up a job with Sonar support in Jenkins

There's several ways of running SonarQube against a project:

• Using the SonarQube plugin for Jenkins
• Using the stand alone SonarQube Runner
• Adding it to your Maven (or Ant) build

In this tutorial we will use the first option.  Personally I prefer to keep the pom as clean as possible, and have Jenkins perform extra steps such as analyzing code quality, deployment into package managers, etc.

Make sure that you install the Jenkins SonarQube plugin:

The SonarQube plugin must be configured with one or Sonar installation.  Most shops will only have one Sonar installation.  This can be done in "Manage Jenkins" -> "Configure System"

In this case, we're using the defaults, since our SonarQube installation is running on http://localhost:9000, and we're using the embedded database, so there's no need to configure any of the database information.

It is also useful to check "Skip if triggered by SCM Changes" and "Skip if triggered by the build of a dependency", to prevent Sonar running after every commit.  Running Sonar once a night is normally enough for most projects.  This assumes that you have one nightly build scheduled for every project that you want to analyze with SonarQube.

We will then set up a simple Maven job in Jenkins:

We will check this project out of Source Control Management.  I'm going to use SVN to access a directory inside my git repository.  For real projects, I would recommend having a one git repository per each project:

Finally, we just add a "Post-build Action", to invoke SonarQube.  This will use the configuration for the SonarQube instance we configured before.

Finally you can start a build manually.  This will cause to project to first be built as usual using Maven, and the analyzed by Sonar:

The results

After the build is run successfully by Jenkins, you can see the results on your SonarQube installation.  Make sure that you have the "Integration Tests Coverage" widget in your dashboard.  To add it, log into SonarQube, and click on "Configure widgets".

You can see how Test Coverage for Integration Tests is reported separately, and that there's a metric for "Overall Coverage", which joins the coverage for unit tests and integration tests.  If you drill down can see much more detail about your project, so I encourage to click around and see what Sonar has to say about your code.

Source Code

As always the code is available for you to download and play with. Clone it from it from github:

git clone https://github.com/aolarte/tutorials.git

The finished code is contained in directory coverage.

References

This post was put together with tidbits of information from other postings around the net:

• Separating Integration and Unit Tests with Maven, Sonar, Failsafe, and JaCoCo
• Tracking Integration Test Coverage with Maven and SonarQube
• Easy Unit and Integration Code Coverage