David Sheth

I think option two would be your best solution. I'd like to specifically address what you listed as the "con" of that approach, and show why that don't apply:

Issues like failed messages, then re-trying failed messages by publishing to a failure queue etc.

First, you need to differentiate between transient failures, when you want to try again, and permanent failures, when you don't. Sometimes you don't know the difference, in which case you want to simply retry all failures a certain number of times before giving up on a particular message. You need to do this sort of analysis if you choose the scheduler approach or the JMS approach.

Using the JMS approach, you don't have to manually record how many times you have tried a specific message. Simply roll back the transaction, which will cause the message to go back onto the JMS Queue, where it will be automatically tried again the next time it is removed from the queue. Although not part of the spec, all JMS servers that I know of allow you to configure for a certain number of retries, after which you can take some other action. Again, that is the same thing that you'd have to do manually if you were to use the scheduler approach, and so that is why I'd recommend JMS for your particular case.

Just click on the link in my message above, and in the resulting page, scroll down to where I posted the list of books. The reason why I originally posted that list is because the original url where Sun posted that list was no longer available.

You don't want to use the books for the previous version of the exam. Fortunately, Sun posted a list of the books they recommend for SCEA 5. I posted that list to the form a while ago, here: https://coderanch.com/t/155965/java-Architect-SCEA/certification/FREE-SCEA-Beta-Certification-Exam

As I've mentioned before, on that list, you'll note an EJB3 book recommended by Sun. That book is indeed well worth reading, but I would also add Java Persistence with Hibernate (Bauer/King) to your reading list, as it goes into more of the theory of ORM and why certain choices were made in JPA. You might also want to add Patterns of Enterprise Application Architecture (Fowler).

You can find reviews of some of the books on my blog.

I posted the list a few months ago when someone asked for it:

https://coderanch.com/t/155965/java-Architect-SCEA/certification/FREE-SCEA-Beta-Certification-Exam

On that list, you'll note an EJB3 book recommended by Sun. That book is indeed well worth reading, but I would also add Java Persistence with Hibernate (Bauer/King) to your reading list, as it goes into more of the theory of ORM and why certain choices were made in JPA. You might also want to add Patterns of Enterprise Application Architecture (Fowler).

I've reviewed some of the books on that list on my blog, and now that part II is over, I'll be adding more reviews of books on that list.

You mentioned

If I dont keep the data in a cache then I need to re execute the query for next subset of data.

However, if your dataset is large, and you have a large number of users, you may run out of memory if you store a large dataset for each user. Instead, you may want to take advantage of the built in pagination features of EJB3/JPA--in particular, the setMaxResults and setFirstResults methods. You would need to run a new query for each page that a user sees, but your memory consumption would be much less. This is a tradeoff that we make in our applications for large lists.

It's not quick, but Java Security is a big topic, and Chapter 5 of Core Security Patterns, which is the J2EE Security Architecture chapter, covers what you need to know in only 56 pages, so that's what I recommend. However, you may need to at least skim chapters 2 (Basics of Security), 3 (The Java 2 Platform security) and 4 (Java Extensible security Architecture and APIs) to fully understand chapter 5.

I don't normally post links to my own posts, but for the second time today one of my old posts applies, so here is the link:
Core Security Patterns

No, these are not "approved" by Sun. As I mentioned, I made notes regarding which patterns I thought were still useful, and which I thought were obsolete. My thoughts are based on what changed in the spec from J2EE 1.4 to JEE 5.

When I read through Core J2EE patterns again in preparation for part I of SCEA 5 beta, I made notes regarding which patterns I thought were still useful, and which I thought were obsolete. I incorporated these notes into a book review, which you may find useful:

Core J2EE Patterns book review

83%.

I wonder if they are going to break down the percent in each area. That would be useful for determining which areas each tester should learn more about.

We primarily use Eclipse to develop, and so spent quite a bit of time looking for a free UML plugin for Eclipse. We found some, but none that were as comprehensive as the UML tools built directly into Netbeans. So, now we just switch to Netbeans when we need to do UML, and so I'd recommend giving that a try as well.

That's exactly why many people are using Seam, as it does the same thing for JSF that JEE5 did for EJBs--eliminate the configuration files in favor of sensible defaults that may be overridden by annotations and/or xml.

UML Distilled - by Martin Fowler

� Java Design (Objects, UML, and Process) - by Kirk Knoernschild

* Addison-Wesley (2002)
* ISBN 0-201-75044-9

� http://java.sun.com/developer/technicalArticles/WebServices/soa3/

� SOA Using Java Web Services (Paperback) - by Mark D. Hansen

� Developing Java Web Services: Architecting and Developing Secure Web Services Using Java - by Ramesh Nagappan, Robert Skoczylas, Rima Patel Sriganesh

� http://www.EnterpriseIntegrationPatterns.com/

� Enterprise Java Beans - by Richard Monson-Haefel

� Java Enterprise in a Nutshell - by David Flanagan, Jim Farley, William Crawford, Kris Magnusson

� EJB v3.0 spec

� EJB v2.1 spec

� Core Servlets and JavaServer Pages, Vol. 1 (2nd Edition) - by Marty Hall, Larry Brown

* Prentice Hall PTR; 2 edition (August 29, 2003)
* ISBN-13: 978-0130092298

� Core Servlets and JavaServer Pages, Vol. 2 (2nd Edition) - by Marty Hall, Larry Brown, and Yaakov Chaikin

* Prentice Hall PTR; 2 edition (December 1, 2007)
* ISBN-13: 978-0131482609

� Core JavaServer Faces (2nd Edition) - by David Geary, Cay S. Horstmann

* Prentice Hall PTR; 2 edition (May 9, 2007)
* SBN-13: 978-0131738867

� Servlet v2.5 spec

� JSP v1.2 spec

� JSF v1.1 spec

� Designing Enterprise Applications with the Java 2 Platform, Enterprise Edition - by Nicholas Kassem, Enterprise Team

* List Price: $37.95, Paperback - 368 pages 1 edition (June 2, 2000)
* Addison-Wesley Pub Co
* ISBN: 0201702770

� Java 2 Platform, Enterprise Edition: Platform and Component Specifications - by Bill Shannon, Mark Hapner, Vlada Matena, Eduardo Pelegri-Llopart, Larry Cable, James Davidson

* List Price: $44.95, Paperback - 800 pages 1 edition (May 26, 2000)
* Addison-Wesley Pub Co
* ISBN: 0201704560

� Enterprise Blueprints: http://java.sun.com/blueprints/enterprise/

� Java EE 5 Performance Management and Optimization (Pro) - by Steven Haines

� Design Patterns and Contracts - by Jean-Marc Jezequel, by Michel Train and Christine mingins

� Design Patterns - by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Grady Booch

� Core J2EE Patterns: http://java.sun.com/blueprints/corej2eepatterns/, http://www.corej2eepatterns.com/

� Core J2EE Patterns: Best Practices and Design Strategies (2nd Edition) - Deepak Alur, John Crupi and Dan Malks

* Publisher: Prentice Hall / Sun Microsystems Press
* ISBN:0131422464; 2nd Edition (June, 2003)

� J2EE Blueprints

� Java 2 Network Security, by Marco Pistoia, Duane F. Reller, Deepak Gupta, Milind Nagnur, Ashok K. Ramani

� Core Security Patterns: Best Practices and Strategies for J2EE, Web Services, and Identity Managemen

Although I've been using JSF for some time, I saw that second edition of the Core JSF book was recommended by Sun as preparation for the exam, so I picked it up and read it a few weeks ago.

One of the authors was actually on the JSF spec committee, and I found the book to be quite good at explaining the reasoning behind the design decisions made by the JSF spec committee. With knowledge of this reasoning in place, the actual implementation details of JSF are pretty straightforward.