s khosa

Ranch Hand
+ Follow
since May 15, 2003
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
In last 30 days
0
Forums and Threads

Recent posts by s khosa

Problem with this approach is:

BD -> SessionFacade (SLSB) -> serviceAppFacade (SLSB) -> serviceApp

- What would happen to exception handling particulalry if you are using/executing multiple/nested transaction. Who tells what and to whom and how !!!... in case exceptions occur.

Again no design is perfect....as long as you can plan out/justify things around it you should be fine.

Thanks
well ...lets assume the session has timed out...what will happen is the your User.isinRole() method can throw an error...maybe null pointer...and you should have code in their to redirect him to login page again...and i think container security manager class will do it on its own. Login page is configured in web.xml

Hope this makes sense.

PS: Looks like you are pretty close to finishing your assignment..:-)..I still have not started mine..:-)
Order as per my understanding has two parts in this business process. One is -prepayment reservation (e.g most of the internation flight seats can be reserved for a paeriod of 72 hrs before payment) and then there is actual booking once payment is made. Unless I am missing something conceptually, i would believe that we would need to issue order based on our individual assumptions. If we choose to assume that we will not let users reserve seats without actual payment being made then there will be one complete order as soon as user prepares itenary and pays for it (all together)

However if you choose to reserve seats for x amount of time, and then make payment to ocnfirm it, you would need some sort of temp order at reservation point and confirm it once payment is made. You would also need to clean up the expired bookings for which payment has not been.

So it depends how much fun you want to have in this assignment..:-))))

Thanks
Should we even be mentioning that if we are using ContainerManaged Security? Since container would have access to request object it can always decided whether the user request is in Role or not. This is an implicit service task that container would perform for any call in your system whether its for POJO1 or POJO2. Even we really have to show something of that sort, we would be indicating that in class diagram through some sort of security manager class( e.g SecurityManager class used by EJB container.

I hope i understood the issue correctly.

Thanks
It would a simple java component using Transaction API. And i would presume any EJB object e.g SessionBean when it has to bill user or update user Mileage account can initiate a transaction using it.

Thanks
hmm....with static only issue i see is if my mistake u implement a singleton pattern in your controlling component ( or singlethreaded model in case os servlets) which contains this static thingie... you would automatically loose all the benefits of pooling. Am i right?

Thanks
hmm..we seem to be exchanging too many responses between two of us..:-)))

1) You can show swing classes (if that gives you a satisfaction...:-)..) but as a norm in sequence diagram we can mark the any UI component as JSP. But again its a personal preference. Atleast I am not aware of any rules regarding this

3) Not sure whether there is a need to show EJBContainer. I am going to mark it as a generic swing component or name it something meaningful. I think its not worth the effort to research this one for EJB Client Container implementation

Showing login in sequence diagram is a personal preferance. I think one can show it as a seperate sequence diagram since login is a generic sequence that users have to perform for all other aspects of business application

Thanks
Ricardo,

Just wanted to clarify. Your suggestion would work fine for web client, but for a desktop client you would need to to JNDI look ups for the Session Bean, right?

Thanks
My 2 cents. I would not complicate it that much. I personally think Part2 needed not be overkilled with too many patterns. I would think about putting a custom pattern with a TransactionController which initiates/rolls back transaction and this interacts with SessionBean for all transactional aspects that your system needs. You can differ whether this is the best solution but looking at effort vs benefit, i think this would work fine.

Thanks
I would assume that the payment has to be confirmed via a synchronous process since no business we like to confirm good/service purchase with a customer without payment received confirmation..:-). Starting from customer's credit card submission to payment confirmation has to be in one thread.

Thanks
_S
You can assume that you have an SMTP mail client running on your server and send an notification email. The simpler, the better. Can use JMS also, but for sending a simple email, JMS would be overkill.

Thanks
I think the solution lies in what sites like amazon.com do. Your unpaid itenaries are just like items in your shopping cart. Suppose i add 4 books to my shopping cart and feel lazy enough not to pay for them today. When i log back in couple of days later, i DO expect to see these items in my shopping cart. So Persistence is needed 100%.

BUT the big catch is whatif the amazon has run out of these books in the inventory within last 4 days. So we might need to make some assumptions here.

- either we recheck the avalaible stock of books when user is selecting a particular book for payment.
- or we let user pay for the books, only to revert back to them later with an email saying book is out of stock.

This is typical of real time transaction processing systems. eventhough expectation is that any point all end user transaction data should be live, but business or real life usage scenario also mandate that we are forced that snap shot of data and store it with regards to a particular user session, and then sync it up with real time data at a later stage based on user interaction.

Hope this helps.

I agree with Saha regarding persisting the unpaid itenaries.

Thanks
Ok...i needed some coffee at that time..:-(. They are showing valueObject in the class diagram.
http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html

But i still think showing Transfer object would not hurt. Again as an architect your role would be to hand off the design document to the developers, and they should be able to start coding from that point..:-)

But its a matter of choice. I would atleast show the main DAO class and its mapping with the Entity/Session Bean. I think this would make it better as far as readability goes.

BTW, thanks for asking all these questions. They sure have helped me in introspecting the way I want to design the application...though i am feeling plain lazy right now and dont plan to start on it for another few weeks..:-)

Thanks
Why would you not show to TO as part of class digram? My guess is you should because TO would be something like a composite object and it would share a relationship with the business object that is generating it. Infact i checked on sun's j2ee patterns guide for this and they have shown TO as part of class diagram.

Thanks
Hi,

Do we have to list/mention technology aspects of our implementation in sequence diagrams for part2? E.g If we are using Entity Bean, should we be listing calls to Home/Remote interface as part of Sequence diagrams for part 2?

Also, should we be listing these details for class diagrams? I have seen listing mentioning around 40-50 classes for some of the submissions discussed on this list. I understand that this is highly subjective and it depends how granular you want to go, but whats the right approach from SCEA Exam perspective. I feel there should not be more than 14-15 classes for this subsmission at tht high level.

Any pointers?

Thanks