Seshagiri Rao Ananthaneni

Greenhorn
+ Follow
since Jul 05, 2004
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Seshagiri Rao Ananthaneni

Thank You Hassan,Parag and Ajith
Hassan,
My persistance strategy is mainly DAO's. I used composite entity too
I didn't mention any attributes or operations in class diagram
Followed Cade's architecture and this group members suggestions
Hi All,
I finally got the result after waiting for nearly 6 weeks. Here is my marks break up

My marks breakup:

Class Diagram (44 maximum) .......................... 44
Component Diagram (44 maximum) ...................... 40
Sequence/Colloboration Diagrams (12 maximum) ........ 12

I am thankful to Parag and other javaranchers for their valuble suggestions

Thank You All,
Seshu
i don't recommend to study Paul Allen and Joseph Bambara book. Its a first book(second if you consider Cade's book) on SCEA but not much help. Please check the links section of this group and scea_j2ee yahoo group. don't read everything choose from objectives
hi guys, i think first name is enough. should we give last name too? Ajith is not that particular!!.
[ July 29, 2004: Message edited by: Seshagiri Rao Ananthaneni ]
shouldn't be. will you call web tier from ejb tier?
you need to know only about DAO pattern from j2ee patterns and all GoF patterns for part1 exam
congratulations harish. your messages are very helpful
Yes it is nice and simple if you use jsp for both clients. I know one who got above 90 but because it was mentioned there in document it is better keep two. there are some advantages and disadvantages keeping two types of clients. it is upto you how you design
I will try to clear you but not sure how much it helps you. If you take the example in cade's book, all the navigation arrows pointing towards customer. that means customer don't know about other classes around it. this type of design is very helpful if you want to reuse customer(lightweight, so flexible). If you want customer to know about every class then customer becomes heavy. If you like to design in such way that customer knows about every object or some objects around it you can point the other way.
ranchers, you are allowed to differ or correct
[ July 12, 2004: Message edited by: Seshagiri Rao Ananthaneni ]
Hi Peter Bergoff,
i think your post took a new turn. have you understand the navigation or do we need to continue..
Rao
the answer is yes for assignment. hello guys, appreciate your responses if you tell us the advantages of keeping two types of clients
Thanks for your responses.I agree no system is 100% secure. I think the problem here is the way we are looking at the problem. I feel that creditcard details shouldn't be stored in database. If we store credit card details in database securing password is very important. hope you understand me.
Sorry for troubling you.one last message. i am giving these messages just to know experienced people thoughts before i start designing. yes your interpretation is correct for "he" and "your". sorry for using those. Password will also be compromised if hacker got access to database somehow and replace encrypted password with something he knows.don't say that it decrypt differrently, suppose hacker replaces with another encrypted password hacker knows.
May be my messages are not clear enough, i will take care before i post from now. yes, password is very critical in some systems. credit card number is critical than that in shopping cart(in my view). i explained reason for that in my previous message. can hacker do any thing other than that?
[ July 11, 2004: Message edited by: Seshagiri Rao Ananthaneni ]
thanks srinivas. my question remains same. we will definitely encrypt password and credit cards.
what will one do if password is compromised(in shopping cart) ?. he will see your records and may try to make purchase on his name but he can't make it becuase he doesn't know your credit card details. If credit card details are stored in database we may reuse it and will show it on web interface and we are allowing a person to purchase on another persons credit card and allowing him to know customer credit card number.
i think we don't have to store credit card in database. why should we?. we will take it from web and pass it to credit card processing system through secure protocol.can't we?
Thank you srinivas. I think even in class design, it should be the way. my question on the credit card is why should it be persistant risking the customer. is it a good design consideration?
[ July 10, 2004: Message edited by: Seshagiri Rao Ananthaneni ]