1 You are designing an online shopping application to make it easier for customers to order products from your company. The aim is that the majority of customers buying over the phone will start using the web instead. When customers purchases goods online they will use credit cards and will require an instant response as to whether the sale has been approved or not. (Note the credit card validation is carried out by another very powerful system.) What type of messaging should be used? a) Synchronous messaging b) Asynchronous messaging c) You shouldn't be using messaging at all as it's not transactional. d) You could use messaging because it is transactional however it's not advised, as the system would never perform well enough for an instant response. I think d is the best answer,but SCEA@whiz give c 2 You are writing an Enterprise Javabean to represent a Flight in a Travel agency application. One of the developers recommended that you use Bean Managed Persistence (BMP) for the EJB. What is true about BMP? a) Improves your ability to move your EJB from one Application server to another. b) Reduces your ability to move your EJB from one Application server to another. c) Improves your ability to move your EJB from one data store to another. d) Reduces your ability to move your EJB from one data store to another. it seams d is correct,because question doesn't refer anything about DAO,but answer is c 3 You have a method that can't be executed in a transaction. What is the correct attribute in the deployment descriptor? a)Leave it empty this is the default. b)NEVER c)NOT SUPPORTED d)NO_TRANSACTIONS why not the answer is c but b? I think "a method that can't be executed in a transaction" doesn't mean "a method that can't be called in a transaction" Last question : Whether SCEA@Whiz's mock test harder than the real test or not? [ November 12, 2002: Message edited by: abner tan ]
For question 1, You can choose answer (a) as synchronous messaging mimic the synchronous call behaviour. But it not advisable to use Synchronous messaging when you can use the synchronous method call. So you are correct answer (d) make more sense.
Question 2 is straight forward as answer ( D) is correct. Reduces your ability to move your EJB from one data store to another
Question 3 there is two possible answers NEVER or NOT_SUPPORTED. Question says “method that can't be executed in a transaction” but it dose not say that method from which this method is called can not be executed in transaction. It may possible that that parents method may require transaction. If we put attribute NAVER then its parent method also cannot have transaction, because when transaction reach this method it will throw exception. But if we put attribute NOT_SUPPORTED then it is OK
Suppose the holiday shopping season is about to end. There's one Ranger Rick doll left in inventory in the whole world. There a very good or important customer who wants to buy it right now. If credit card authorization is not available - a) You sell the doll but don't worry about payment because it's not transactional? :roll: b) You tell your important customer to try again later and when they find time to come back Ranger Rick has already been sold. c) You tell your customer Ranger Rick is reserved, but credit card processing is backed up. We'll send you an email with your confirmation number as soon as the asyncrounous JMS transaction completes. Which answer makes you a happy customer or supplier? Which answer is enterprise quality? [ November 13, 2002: Message edited by: Rufus BugleWeed ]
Joined: Dec 19, 2000
This more of business decesion question rather then system architeracture. It just my view answer C make some sense.
All, The answer for Q1 is being changed in SCEA@Whiz. While JMS does not mandate a provider to implement Transaction support, if the provider supports transactions, JMS can too. There is a good article about it at: http://www.javaworld.com/javaworld/jw-03-2002/jw-0315-jms.html I believe that the author's original contention was that MOMs should be used for asynchronous processing only, whenever possible. The following is a cumbersome example of a messaging implementation (this is one model, there can be other implemenatations too): 1. Send a message to recipient 2. MOM Queues the request 3. Recipient is polling the server to check for messages 4. Recipient de-queues the message 5. Recipient processes the message 6. Recipient sends ack to MOM 7. MOM enqueues ack 8. Original sender polls for messages 9. Original sender dwqueues message 10. Original sender processes ack. In this example you see that two asynchronous calls are made to simulate a synchronous transaction, which is especially problematic, if the client is held up for response. If possible, a synchronous communication protocol should be used in such cases. However since transactions are supported by JMS, the answer will be modified. Q2. BMP definitely reduces the ability to change datastores (unless, as someone mentioned DAOs are used, which is not specified). This answer was already changed in the product and will be available with new downloads. This was a good discussion. Thanks for your inputs.
Sanjay Raghavan<br />SCJP2, SCEA-J2EE<br />Moderator - <a href="http://groups.yahoo.com/group/scea_prep" target="_blank" rel="nofollow">SCEA PREP</a><br />Co-Author - <a href="http://www.whizlabs.com/scea/scea.html" target="_blank" rel="nofollow">SCEA@Whiz</a><br /><i>Where did you sip your Java Today?</i>
Joined: May 14, 2002
I agree with Shakti too. This is a business question. E.g. In the toy store, you can take down the Credit Card Number and post a "Thank you for your purchase. You will receive an email confirmation of your transaction after your payment has been processed." Now take the example of a bank. A customer wants to make an online payment, but the account database is down. Would you still make the online payment? I am sure that most banks will tell their customers that the system is temporarily down for maintenance or something and politely ask them to check back later. So yes, I believe it would largely depend on the business situation.