Ray Ye

Hi Titi,

You are correct. All the answers given are wrong. I already posted this to their support team and it may be get corrected in their next release.

Cheers,

"The Business Delegate hides the underlying implementation details of the business service, such as lookup and access details of the EJB architecture. "

This is quoted from Oracle not me, if you don't agree with the official resource of the pattern.

Even as you said, "The main purpose of a business delegate is to decouple the client layer from the service layer", then BD is not for just delegation (and again I agree it uses delegation), it provides abstraction and encapsulation for business service components (EJBs).

We have to look at the intention of the design pattern. A lot of design patterns are using delegation, e.g., Wrapper (Object Adaptor), Chain of Responsibilites etc. Delegation itself is not the intention it is means of design/implementation. E.g. Favor object composition over class inheritance, in Gof Design Pattern book. Composition will always use delegation. So what is delegation? According to Design Patterns definition,

delegation
An implementation mechanism in which an object forwards or delegates a request to another object. The delegate carries out the request on behalf of the original object.


So it is an implementation mechanism. Not the purpose. We don't do delegation for the sake of delegation.

Back to Business Delegation, sure it does use delegation, but it is not the purpose. The purpose/intention is to encapsulate the EJB class from details of looking up/accessing EJB business service. This is also explained in Oracle's website (and book) Core J2EE Patterns regarding BD,

"The Business Delegate hides the underlying implementation details of the business service, such as lookup and access details of the EJB architecture. "

Yes, I did not say BD encapsulate business logic. It encapsulates the access to business service. And it is not simple delegation, it needs service locator to look up, and it may need to handle exception and retry access, etc. It may do a lot more than just delegation. But it encapsulates all these details to the client.

Hi everyone, I am preparing to be re-certified with OCMJEE6 and

Here is a question from EPractice Lab which they allow me to post here since I don't agree with their provided answer

Java EE Business Delegate patterns refers to which OO design approach
A. Separation of Concerns
B. Delegation
C. Encapsulation
D. Abstraction

Here is the quote from Oracle's Core J2EE Pattern, http://www.oracle.com/technetwork/java/businessdelegate-137562.html

Use a Business Delegate to reduce coupling between presentation-tier clients and business services. The Business Delegate hides the underlying implementation details of the business service, such as lookup and access details of the EJB architecture.

The Business Delegate acts as a client-side business abstraction; it provides an abstraction for, and thus hides, the implementation of the business services.

So it is a bit of everything here. But I think the main intention of BD is to hide the underlying implementation details to access EJB service. So I opt for C. The provided answer is B which I think it is just means of implementation details.

What is your opinions?

Thank you and Best Regards,

I think it is OK. My jar is about 1.3M and was uploaded with no problem at all.

Do you have kept separated for ALL EJB components (Session, Entity) or only for Entity? I've kept separated only for EJB Entity (to better depict separation of create/find messages regards other data access).

I did it only for Entity beens too (for the same reason as you mentioned). So you should be fine :-)

But i'm uncertain about sequence diagram detail level.

It is OK to be detailed. I did something similar as to separating Home interface from Business interface in my sequence diagram.

It is OK, you can take PartIII and then upload your assignment work.

How did you implemented the shopping cart?

I utilized HttpSession for web client and Swing client itself can hold the state.

Test: Sun Certified Enterprise Architect for Java 2 Platform Enterprise Edition Technology Part II (310-061)
Date Taken: 2006-08-15 09:33:41.107
Registration Number:
Site: on137
Grade: P
Score: 95
Comment: This report shows the total points that could have been awarded in each section and the actual amount of points you were awarded. This information is provided in order to give you feedback on your relative strengths on a section basis. The maximum number of points you could have received is 100, minimum to pass is 70.
Class Diagram (44 maximum) .......................... 39
Component Diagram (44 maximum) ...................... 44 Sequence/Colloboration Diagrams (12 maximum) ........ 12


a few notes:
1. Unlike most classic solutions for partII (I guess), only stateless session beans (no stateful session beans) is used in my design and it worked out
2. Quite amount of time is spent on sequence digram, it seems the effort and allocated score (only 12 points) don't quite match. The sequence diagram is probably too detailed in my case, but the devils are the in details, right?
3. Swing client and web client are treated differently, web client request is going through FrontController, whereas Swing client request is going through SessionFacade wrapped in Command.

Peer,

I think you are right. If we call jar author 3rd party vendor, then B and D are all right. As you pointed out, impersonation definitely makes D "may have signed jar" a right answer.

yes

The author's certificate (public key) was signed by CA. And author signed the JAR with his private key, this sigature will be compared with his certificate to insure it is from the author himself not anybody else. To the user of the signed jar, the jar author is the vendor, not 3rd party though (but 2nd party)

Sorry, I mean I don't think B is right.