Hi everyone.
I'm glad I have passed this tough
test and now I'm a
java architect. I was very upset with Oracle, as a lot of people here still is, but, mostly because I failed in my first attempt (Big Smokes). Not entirely because I have failed, since I wrote my architecture in two weeks in order to reach the deadline. So, there were a lot of gaps that I realized through my waiting. But they failed me with the wrong reasons. I would argue extensively the points, but that would make this story very bitter and I don't want this because I'm very happy. So:
Part 1
The test is tough. I saw people saying here they got 100%, 95% and I thought it would be piece of cake. It wasn't. I got very well prepared, though, but still the same, get yourself very very very prepared. Pearson Vue gave to me an online test for free (I don't know why, I just got an e-mail telling me to take the test) and I recommend you take it as well. It's not cheap, but it helps.
Be confident you know everything about JAX-WS, JAX-RPC, JAXR,
SOAP, JMS and security. You must know what is JCE, JSSE, SAML and when to use it. When to use CORBA, RMI and Java-IDL. It's not trivial and you must know the details. Keep in mind they know you have studied everything about Design
Patterns, EJBs (and you must, of course), but they will test your knowledge in Java EE as a whole and will reward you for knowing every piece of it.
Part 2 and 3
It took me two weeks to prepare my assignment. It wasnt perfect, as I said, but I still think it was enough to pass. I got in first attempt 124/160, but failed on my questions and risks. So, in my second attempt, I wrote an additional document explain thoroughly how my architecture would handle each capacity and I wrote this time as I was writting to a nephew.
They loved my deploy diagram, even though I would change a couple of things after a month I submitted. I wrote 2 diagrams, one for tiers and another one for servers profiles. In tiers diagram, I defined a firewall, a load balancer and a trust domain (I think it is very necessary and I didn't hear anyone talking about that) where business, persistence and integration tiers lay. I explain with a comment on firewall that no connection should be allowed other than HTTP and HTTPS (also very important).
In profile diagram, I explain how each server would be deployed, which operation system, database, web/application server and its artifacts.
There were important errors on my class diagram that was not severely punished. I think they could fail me and I would not complain, but they gave me 30/40. You MUST put DAO in class diagram if they are cited on component diagram. Reading some topics, I tought it wasn't necessary. It is! And I didn't described the types of classes properties, neither methods arguments because my diagram became a mess, but in second attempt, I cleaned up my diagram and could fit all needed information.
My component diagram was a masterpiece (seriously), but they thought it was too detailed, so they gave me 35/40. I generalized some components in order to let the diagram simpler. Don't explain too much. I followed the structure of Cade/Sheil, but I explained a lot more. You must explain only a bit more.
On my sequence diagrams, I was mislead (maybe this
word is too strong) by Cade/Sheil example. I made all the sequences, but seeing Cade/Sheil example, they did'nt mentioned the actors, so I cut off the actors from my sequences. Oracle complained. So, PUT YOUR ACTORS and forget Cade/Sheil example.
I rewrote the risks and mitigation because I thought I didn't get what they wanted. They told me my risks were generic. Come on, I talked about transactions awareness, security and availability risks and I related each risk with the project. So, how come generic? And generic risks are not risks? Anyway, I was studying test management in December and I was reading
this book that explain what risk is, and what is risk mitigation. I followed its concepts:
Risk is the possibility of a negative or undesirable outcome. In the future, a risk has some likelihood between 0% and 100%; it is a possibility, not a certainty. In the past, however, either the risk has materialized and become an outcome or issue or it has not; the likelihood of a risk in the past is either 0% or 100%. (Foundations of Software Testing, p.151)
and...
Risk-based testing involves both mitigation - testing to provide opportunities to reduce the likelihood of defects, especially high-impact defects - and contingency - testing to identify work-arounds to make the defects that do get past us less painful. (Foundations of Software Testing, p.152)
In the end, I may have mixed the concepts of mitigation and contingency. You must have this two concepts in mind and know how to separete one from another in your assignment.
Good luck.
--eduardo