What skills concern the evaluators?

[Frank Silbermann]

What is the objective of Part II? Which of these issues do you think the evaluators are most concerned about?

Our skill using UML and UML tools

Our understanding of MVC web framework usage

Our understanding of when and where to use each J2EE facility (i.e. servelet, JSP, stateful session bean, stateless session bean, BMP entity bean, CMP entity bean, message-driven bean, container-managed transactions, user-managed transaction)

Our mastery of design patterns to produce a system that is fast and maintainable (a skill that is independent of whether J2EE technology is used)

[Ajith Kallambella]

If you ask me, only two -

How well you understand different tools provided by J2EE technology, and apply them relevantly( not blindly clone PetStore ) to solve a given problem.

How well you document your architecture - ( emphasis on clarity and notation ie., UML ) so that the implementation team can easily follow them.

IMO some of the things Sun doesn't seem to care(much) about include - your object model, persistence schema details, and general OOAD skills. I have personally seen and peer-reviewed a few SCEA submissions that barely scratched the surface of creating a good Object Model, but all of them have passed. Remember, it's all about J2EE and not so much about OOAD, although I strongly encourage everyone to consider this as an opportunity to learn and hone every skill expected from you as an architect when you go out there and work in the real world.

HTH

[Frank Silbermann]

Originally posted by Ajith Kallambella:
If you ask me, only two -

How well you understand different tools provided by J2EE technology, and apply them relevantly( not blindly clone PetStore ) to solve a given problem.

How well you document your architecture - ( emphasis on clarity and notation ie., UML ) so that the implementation team can easily follow them.

IMO some of the things Sun doesn't seem to care(much) about include - your object model, persistence schema details, and general OOAD skills. I have personally seen and peer-reviewed a few SCEA submissions that barely scratched the surface of creating a good Object Model, but all of them have passed. Remember, it's all about J2EE and not so much about OOAD, although I strongly encourage everyone to consider this as an opportunity to learn and hone every skill expected from you as an architect when you go out there and work in the real world.

HTH

Well, if I keep things simple and high-level, using the standard "business logic in the EJB tier, and GUI logic in the web and fat-client" then my solution is going to look pretty generic.

What I'd like to do is solve the problem creatively, using the EJB tier for database-oriented operations and integration with external systems -- but with cached static data (e.g. the flight schedule) and the business logic using it on the web and fat-client tiers. (My early training in Forte Tool makes me think of _partitioning_ the application rather than trying to make it more of a mainframe application with distributed GUI-generation.) With a pluggable service locator configured separately for web versus fat-client, I think I could deploy the same business logic classes to be called by both fat-client and front-servlet.

However, I worry that the grader might be annoyed by a non-conventional solution and fail it for not reflecting the usual J2EE "best practices."

Do you think I should go for it and present my ideas for minimizing remote calls via a portion of business logic on the client, or would you recommend a conventional EJB-centric design as being less risky?

[Louise Elliott]

As long as you state the reasons for your design and show that you realise there are other ways to do things I think the examiner will be OK.