Contradiction in preparing itinerary

[Daniel CarMichael]

If login is a pre-condition, how come a customer who has not logged in can proceed until he needs to confirm the flights?

[Alex Pisarev]

Originally posted by Daniel CarMichael:
If login is a pre-condition, how come a customer who has not logged in can proceed until he needs to confirm the flights?

That's not the only place in the assigment where I met such a doubtful requirments.
Alex.

[Gennady Shapiro]

Yeah, its not 100% consistent. What I think is happening here is dealing with 2 types of clients Web and Swing.
While most web systems allow you browse and search as anonymous (which is perfectly ok) they make you log in when you attempt to access URL which is transaction-critical, like in this case.
On the other hand, the Swing client nornally connects to the app server in the beginning with proper credentials by initializing InitialContext object with correct name and password. You could, of course, let your Swing client browse some info and THEN login but that would involve switching JNDI contexts. But this is almost never done.
So the pre-condition to log in comes from having your swing client be logged in at all times, and the alternative flow "not logged in" case comes from the event if the web clients happens to be not-yet logged in.

[Vivek Viswanathan]

Thank you Gennady, that was helpfull I did not see it from than angle.

[Lipman Li]

Originally posted by Gennady Shapiro:

On the other hand, the Swing client nornally connects to the app server in the beginning with proper credentials by initializing InitialContext object with correct name and password. You could, of course, let your Swing client browse some info and THEN login but that would involve switching JNDI contexts. But this is almost never done.

could you please elaborate the statement "but that would involve switching JNDI contexts"? I could not understand why sitching JNDI contexts involved here?
thanks

[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.

[Christian Corneau]

What about using the addToEnvironment() method. Will the container be able to authenticate at that time??

[R Krishnan]

Hi Gennady,
Wont the same JNDI switching be required in the case of web clients.

[Gennady Shapiro]

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 ]

[SC Johnson]

Stop and think about it a little. Or better yet, go to a real airline's web site. Notice you can search for flights, and build an itinerary without logging in.
The use cases state when you *must* be logged in to perform certain tasks -- in fact, they're throwing you a huge hint on how the solution will be architected! See above post about fast-lane readers for more detail.
<soap-box>
I've noticed certain ranch members are always bad-mouthing the part 2 assignment (not the original poster in this thread, mind you), citing conflicting requirements, etc. I can only suggest reading the requirements fully and --heaven forbid-- go through an OOA/OOD process to design a solution.
I know of only -1- problem in the assignment, and the assignment itself calls attention to it!
If anyone has aspirations of becoming a java architect, they'd better get used to having worse requirements than Sun gives you in part 2!!!
</soap-box>

[Gerald Davis]

SC Johnson
Can you dig it