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.
- "Fast track UML 2.0" by Kendall Scott
- "Learning UML 2.0" by Miles, Russ
- Authentication (using JASPIC)
For the UML diagrams I tried free different tools:
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.
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.
How everything went down
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 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.