Eduardo Mineo

Ranch Hand
+ Follow
since Sep 26, 2011
Eduardo likes ...
Mac OS X jQuery Java
Merit badge: grant badges
For More
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Eduardo Mineo

Marcin Cinik wrote:Thanks Eduardo,

For JMS I would just give "JMS API" as required interface (even though JMS API is not an interface).
When it comes to JAX-WS generated client I propose to have "" as provided interface.

The deployment diagram should rather depict machines / application servers / protocols / DMZ / firewalls / load-balancers in my opinion.

Well, is up to you to decide, but it seems to much detail for Component Diagram and I was punished because I explained too much in my diagram. I think you should point only the internal and external components, its tiers, and link them. In deploy, you explain how machines/servers/hosts/tiers communicate with each other, by http, https, jdbc, rmi, iiop, corba, jax-ws, jms, etc.
I think this kind of information should be in deploy diagrams (the integration technologies). In component diagrams, I connected my components with 'uses' relationship only, as cade/sheil example. My components that consume jms/ws was described only with a uses relationship with external components in integration tiers, also as cade/sheil example.

Good luck

Congratulations, Suresh. I've just received my SCEA certificate and my gold card. It's very rewarding.
12 years ago
Hi Shekar, how are you?

shekar hari you know what is "part 3 short answer" in part 2 exam? Is it part 3 exam? For part 3 exam, do we need to wait till we get part 2 exam results?

Yes, it's the essay. And no, because Oracle will grade part 2 and part 3 together. So, you must submit your project, take part 3 essay, where they ask you generic questions about your project (mostly what have you done to handle non-functional requirements), and then wait for your results.

shekar hari wrote:How soon you waited to take part 3 after your part 2?

I was desperate. I took part 1 on 9 Sep. I submitted part 2 on 25 Sep and took part 3 essay on 27 Sep. The result came 18 Dec. My resubmission was on 2 Jan and I got my pass on 12 Jan.

12 years ago
By the way, you can use whatever software you like, since it is uml 2 compliance
I've used magic draw, the same Sun has used to draw use cases in assignment. I liked it
It took me 10 days in order to get my results in pearson site after my resubmission

Amandeep Singh wrote:Since the question says which is the design pattern to avoid having lots of conditional statements, then Builder Pattern makes the sense, I wasn't knowing about this earlier.

Hi Amandeep. I don't see builder as a mechanism to avoid if-else statements. In order to avoid it, you must use polymorphism. Since the problem is about avoiding if-else to instantiate modules (or classes if you please), the only right answer is Abstract Factory. Lasse Koskela, a colleague from Java Ranch, wrote a very good book about Test-driven Development. One of the refactoring he did was a removal of if-else statements for instantiate objects in a parser example. He was creating a parser of a template where there would be variables in the form of ${name}. So, the whole idea was to break the template into segments of two types: PlainText or Variable. He says:

An essential part of our grand plan of avoiding ugly if-else blocks by means of polymorphism is to embed the varying functionality into the different implementations of the polymorphic concept of Segment objects. (Test Driven: TDD and Acceptance TDD for Java Developers, p.123)

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)


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.

12 years ago

Eduardo Mineo wrote:-1, passed after resubmission. I'm very disappointed with Oracle in so many ways, but later I'll write about my certification process. Thanks everyone whom contributed to this wonderful forum.

Even though I passed in resubmission, I got today (16/1) the pass e-mail from Oracle. That was nice, at least.

joey cole wrote:How long did you have to wait for the results of your resubmission?

Sorry, I forgot.

Step 1: 9 Sep
Setp 2: Submit 25 Sep
Step 3: 27 Sep

Fail result: 18 Dec (124/160 pts and obtuse reasons to fail me, which I will write about later)
Resubmission: 2 Jan
Pass result: 12 Jan

And good luck for everyone.
-1, passed after resubmission. I'm very disappointed with Oracle in so many ways, but later I'll write about my certification process. Thanks everyone whom contributed to this wonderful forum.
Chris, I think you should read this:

The most important part is this:

When SFSBs should be used in web systems

Systems that have JSP/servlet front-ends should use HttpSession objects to store session-oriented state on behalf of a client. Applications that manage an HttpSession object and an SFSB for a single client wind up duplicating effort that does not need to be duplicated. There are two reasons to use an SFSB in conjunction with an HttpSession object:

  • Your application server does not provide cache management of HttpSession instances and your system is expected to have a large number of concurrent clients. Containers for SFSBs can activate and "passivate" the state of instances to and from a secondary store. This allows a container to create an upper limit to the number of instances that will exist in memory at any given point in time. The number of concurrent clients can exceed the limit of SFSB instances in memory because the container can swap idle instances to and from the secondary store. The container will never allow more than the limit of SFSB instances to exist in memory, subsequently placing all additional instances into the secondary store. This provides a greater level of scalability to the system through effective memory management.

  • Many application servers provide similar cache management of HttpSession objects. Because HttpSession objects are similar to SFSBs, they can also be made passive and active. Cache management behavior of HttpSession objects is not required as part of J2EE and is considered a vendor value-add. If your application server does not support HttpSession cache management -- and you need to control the total number of session-oriented instances in memory at any given time -- you should place the bulk of your session-oriented data in an SFSB instead of an HttpSession object. You will still need to maintain an HttpSession for each client, but the only item in the HttpSession should be a reference to the SFSB for that client. If the only item in the HttpSession object is a reference to the SFSB, the amount of memory consumed by each HttpSession object is minimal and cache management of these instances is not needed. The bulk of memory consumption will occur within the SFSBs, which have a standardized strategy for allowing a container to perform cache management.

  • Your session-oriented objects need to receive notifications on the lifecycle of the transactions they participate in. SFSBs can implement the SessionSynchronization interface. The SessionSynchronization interface contains three methods that a container invokes as a transaction migrates through the lifecycle the SFSB is participating in. An SFSB might implement the SessionSynchronization interface as a way to return the data of the SFSB to its original state whenever there is a transaction rollback. HttpSession instances do not have a mechanism that allows them to receive transaction notifications. This means that any data that is modified in an HttpSession during a transaction will not be reverted if the current transaction is rolled back. All changes to data in an HttpSession object are always durable despite the outcome of any executing transactions. If this behavior is not appropriate for your system, placing all data into an SFSB instance that implements SessionSynchronization will give you the appropriate behavior.

  • And make sure you really understand what "client" means when you are talking about this subject. In a standalone application that connects directly to the EJB Container, the user is a direct client of your Stateful Sessionbean, therefore it's easy to keep the state between calls. But when the scenario moves to a web application, the user client (web browser) is an indirect client of your Stateful Sessionbean. The direct client, in fact, is the web container, so, you have to think about how you will link users(browsers) with stateful sessionbeans stubs in order to assure each user has its own instance of stateful bean. And that would be storing the reference in an HTTPSession.
    Hi, Sadanand.

    If you take a look on this forum and search for "experience part 2" you will find a lot of information on how present your architecture, but I don't think it's a good idea since it may be quite dangerous to follow the template or toc from someone else. What you must have in mind is what your assignment requests on Deliverables section. It's up to you to decide the way you will explain and structure your architecture.

    best wishes,
    Very good, congrats. I also got Big Smokes assignment and took essay on Set 27, but I'm still waiting for results.
    12 years ago