Gennady Shapiro

Jas, I think I do have a clue.
A few things, #1. Now I think they were expecting a high level conceptual diagram remotely related to the deployment diagram. For example, in a real system you would not inherit ba737, ba757 from an AbstractAircraft, you would have a common Aircraft and customize it from AircraftInfo that reads planes' properties from DB, and that's how I presented it. I think what they were expecting was a OO view of the system.
#2. I now think that CreditCard, CreditCardManager, Email, etc have no place on this diargam....
Things like that, the class diagram should be kept simple and concise.
I could be totally off on this though.

I finally got my results on the Part II.
I scored 90%, lost all point on the class diagram. Hint: if you are thinking of modeling your class diagram after Sun J2EE Arch. Study Guide's case study -- don't. I've knocked this book before, but I will not be redundant saying it's a piece of sh*t.
Thanks to everyone who participated in our discussions, particularly to Alex Pisarev who contested everything I said which made it for some interesting discussions.
Oh yeah...check out my new signature:
Gennady Shapiro, SCJP, SCJD, SCJWCD, SCJA

I added one extra sequence digram describing MVC workings in regards to my design and add that all other sequence diagrams omit MVC components for simplicity.

Most likely they will ask about the most common gof patterns used by j2ee. So I sincerely doubt they will ask about flyweigth or interpreter.
What you also have to realize is that they will not go into patterns details, implementations, etc. They'll give you a J2EE element and ask you what GoF pattern it implements, or vice versa.
The design patterns is one of the easy part and you get 2-3 questions on it, no more.

Originally posted by R Krishnan:
Hi Gennady,
Wont the same JNDI switching be required in the case of web clients.

The answer is two-fold.
1. Not really. Your Web component can run some Fast LaneReaders bypassing the EJB tier. The basic search operations should allow unauthenticated access to this. The Swing app on the other hand must use EJB for anything, therefore must get InitialContext for everything.
So this answers questions posed by FBN spec.
2. More generally, I am not quite sure. Suppose you have 2 Web components: one is configured to run as anonymous and another as 'athenticated.user'. The anonymous component creates the InitialContext with 'anonymous'-security context that is propagated to target beans. Now, the user accesses the protected web resource, gets authenticated thereby changing his security context. At this point the question is whether or not the new security context will be propagated to beans via the established InitialContext. I suspect that No, but if anyone cares to run some tests I'd be interested to hear the results.
[ May 17, 2002: Message edited by: Gennady Shapiro ]

In its simples form...when you create an initial context you pass (among others) ID/Password to it as parameters. If your Swing app were to log in as 'anonymous' the system might allow it browse flights but not make reservations. The components that make reservation are protected therefore when you attempt to access them you will get an exception. At this point (or prior to exception) you may want to log in with real credentials and that involves closing your anonymous initial context and creating a new one, this time with good id/password. Thats what i mean by switching context. This technique may work in some cases but you lose session data when you do it, plus it's a very slowest operation.

I have to say we have had great discussions lately. It helped a lot!
This forum was full of "How do I begin?" and "Here's my results!" until recently, there was very little else. So keep it moving, I just submitted my assignment.

They give you a description of business, its model (which is a simplified class diagram) and a few very descriptive use cases. All you need to do is to draw 1 class diagram, 4 sequence or collaboration diagrams and 1 component diagram.
Thats all.

great! where is it?

The spec gives a few very specific numbers:
1 app server
2 web servers
5 sec agent response time
10 sec web customer response time
200/35 - 600/20 number of users
3 sec TransMaster response time
How do you consider these details in your design?
For example, 5 sec agent response time calls for faster UI than web customer so you make it Swing and make your app EJB-centric.
How do you consider scalability (going from 200 to 600 customers) in your design?

We all kinda know what might be coming on Part III test.
So I wonder what design features/patterns people use to improve scalability, maintanability, etc, etc.
I'll start:
DAO
VO
MVC
FastLane Reader
Any other ideas??

I followed SCEA Study Guide component diagram.
P.S. I've knocked this book before (and rightfully so) but it gives you an idea of what they might expect to see on your diagrams.

Your message was edited since you quoted content from the actual assignment. Please read our policy on SCEA questions and refrain from discussing actual assignment issues.

[ August 13, 2003: Message edited by: Ajith Kallambella ]

I kinda followed Amanda's suggestion and made component-deployment diagram. Separated clients, Web-tier, EJB-teir and EIS-tier.

Do you guys have a component diagram for every use case or jam everything into a single one?
I have one big component diagram.

I stand corrected.