Jatin Sutaria

Thanks Rob,

I guess I could do this if this is my only requirement. There are other use cases that may require clustering capabilities. I am not too sure if I can use the DNS level filtering for specific use cases ?. If that is the case, keeping clustering in mind, can we do something to achieve the goal?

Regards,
JS

Hello,

I have a cluster of 2 servers running on different JVM's in different geographical locations - US and IN.

My requirement is getting an ability to dispatch requests to specific servers based on client's location - If some one in US hits the cluster URL, he should be dispatched to the server in US.

W.r.t this I have following queries -

1. Do we have an ability to do load balancing based on clien't i/p in Apache Tomcat? If yes, would appreciate if I get some pointers.

2. Secondly, if i can't do the former can I redirect client requests from server 1 - US to server 2 - IN before I hit any business logic in any of the servers. If that is possible I can have a servlet in front that decides where to delegate requests to based on client i/p and then do the redirection?

Thanks,
JS

Madhan Sundararajan Devaki wrote:I believe, EJB2.1 and EJB3 are completely different specifications and may not be compatible with each other.

I know am a bit late but still for others who wander over here...

J2EE 5 specification is backward compatible with Ejb 2.1 and as such you can have both defined within a single application.xml file.

~Jatin Sutaria

Thanks every body!

Originally posted by Kayman:
jumpingjoy:

Any tips for the rest of us??

Here's what I did and should have done better:

My class diagram listed domain entities only. I also had a class glossary explaining each of the class. What I, think, could have done better is to have more stereotyping to explain the relationship between classes in a more visual way.

For sequence diagrams, I had one generic SD explaining the framework, putting the focus on technical aspects. Rest of my SD'd were more focused on solving the business problem. I am not sure why i lost out some marks on SD. Whether it was too much detail not conveying what it wanted to convey or me not drawing a SD for login or miss-allocation of responsibilities to business beans, I wish could have known more.

Component diagrams, for me, were the tough things. I so much wished I had CADE to refer to at least for the cd's. I ended up showing both the logical and actual view. Components wise, I think, had done enough. But to attribute a reason to not getting a full score in this, in the hindsight, it has to be packaging. I could have done with improved packaging.

I had put indicators on how to get performance, achieve security and related stuff.

Thanks,
Jatin

Thats a good point!

Apart from that, if you can manage to convince yourself that journey is the destination, one can learn a lot of things. As has been emphasized earlier, a certification isn't enough to qualify as an architect in real world scenarios, but one can gain a lot while preparing.

It is difficult to attain that level of 'Nirvana', where-in knowledge is the goal and you work irrespective of results, but if you are able to do that, then you should fear nothing.

Thanks,
Jatin

I got the results within 4 weeks. Infact, today is the last day of the fourth week. Here is my score card:

Test: Sun Certified Enterprise Architect for Java 2 Platform Enterprise Edition Technology Part II (310-061)
Date Taken: 2006-08-31 17:47:40.123
Registration Number: naesyd50e7
Site: ii004
Grade: P
Score: 88
Comment: This report shows the total points that could have been awarded in each section and the actual amount of points you were awarded. This information is provided in order to give you feedback on your relative strengths on a section basis. The maximum number of points you could have received is 100, minimum to pass is 70. Class Diagram (44 maximum) .......................... 39 Component Diagram (44 maximum) ...................... 40 Sequence/Colloboration Diagrams (12 maximum) ........ 9

I had around 19 classes in my class diagram, and all of them were domain classes.
I had 2 component diagrams, one logical and one physical.

My sequence diagrams were, i think, quite detailed. My architecture was event-driven and was a simplification of WAF.

I would also like to take this oppurtunity to thank every body around on this forum. Discussions on this forum opened up so many perspectives and helped me form my own. The suggestion i can give is to form a story line that is consistent and logical and stick to it until something drastic happens.

Thanks again,
Jatin

Congratulations! Indeed a great score. Keep it up

Hello,

Here's what i think:

Originally posted by Samuel Pessorrusso:

My doubt is if it would be a good approach to mix these two things:

client -> SLSB -> SFSB (for confirming, pricing, etc...)

It should be good as long as you have a mechanism in place that allows to access the same SFSB instance through the stateless bean. But isn't confirming and pricing stateless operations. Why you would want to involve a stateful session bean for that. Is there a need to go to the cart to perform stateless operations on it. why can't your form bean objects (POJO objects that correspond to entities) go directly to stateles session beans for stateless operartions.

Originally posted by Samuel Pessorrusso:


client -> SFSB (just to set the selected Flights and Segments into the Shopping Cart)

Think it looks OK, but would still prefer a session facade in front of SFSB.

Thanks,
Jatin

Congratulations dude!

Can you share your insights regarding the framework you chose. Did you follow WAF or Struts or did you had a simplification of either.

Jatin

Yes it is. Thanks for the link.

As of now, i am inclined to have a SLSB invoke DAO to implement 'Search Flight' function. So i can have Segment/Flight/.. as simple Java structures rather than entity beans.

Jatin

Hello All,

Information posted on Javaranch seems to suggest that DAO is better than Local Entity beans for read operations even without their remote invocation overhead.

However, a valid point was also made out that changing a table structure can lead to a change in CMP mapping and DAO SQL.

Could some one throw more light on the performance difference between the two considering the typical (search flight..) read operation(s) of the assignment as a context. Is the performance difference too pronounced to over look the reduced maintainability that may come as a result of using DAO's as well?

Thanks,
Jatin

You can buy your assignment froma prometric centre such as Karrox(if you r in Mumbai).
Try to search for the same in google for the city you stay in.

Originally posted by Jonathan Gerrish:
Hi Jatin,

Agreed. FMS implementation must not be changed. We must assume some kind of interface for loading credited milage into the loyalty system, I think your ideas for reengineering are definately sound ones.

What I am not certain of, is whether defining the mechanism for crediting loyalty points is within the scope of this assignment. We know that somewhere in the system as a whole, this process must happen, but within the context of the assignment, there are no use cases, neither textual references to any process for crediting milage.

One thing that is important to me is to control scope creep. As I said before, I am interested in satisfying the requirements, no more, no less.

Yes, agreed. Identifying an exisitng interface between legacy FBN with IMS d/b and FMS is not in scope. But the point i was trying to make is i want to maintain the interface spscifics same for the new FBN system with FMS system as well ,as said before. Further i am trying to justify that what is going to change is the implementation to this interface and not the interface.
So this interface can be defined as following:
It is a set of offline backend processes that reads data from FBN's d/b and updates the FMS's Oracle database. So thus, the interface is not a java interface.

So lets see how this assumption of the interface holds for legacy and new FBN system.
For legacy system
Backend process programs read from IMS database and deposits the read files in some location in some format. Another set of back end process programs reads these files, analyses them and upadtes the FMS's Oracle database.

For new system
Backend process programs read from FBN Oracles's database and deposits the read files in some location in same format as before. Another set of back end process programs reads these files, analyses them and upadtes the FMS's Oracle database.

So in the new system, what is expected to change is just the backend process programs that read, now, from FBN's Oracle database instead of IMS database.

Originally posted by Jonathan Gerrish:
[QB}
I think it seems to be somthing we acknowledge would happen, but we do not include it in the design.
[/QB]

I think, if you justify why the interface would remain the same, i see no harm in including this as a note.

Originally posted by Jonathan Gerrish:
[QB}
Do you think this is a component that the examiners would be looking for in our solutions?
[/QB]

No, i think just mentioning this as as assumption may be enough
My other open questions are:-

Originally posted by Jonathan Gerrish:
[QB}
1) How would you consider the interface for the FMS? ie: what CGI scripts could be available (ShowMilage / RedeemMilage - ie: use milage to pay for flight).

2) Should we consider error conditions, eg: what happens if either milageRedemption or Booking fail?
[/QB]

For the first question, for me, no screen scraping is needed, one can directly call the CGI/Perl web page dierctly from a web or swing application. And interface may be offline as defined above.

For the second question: yes; i think one should consider the error condition; since mileage redemption and booking operations work on the same databse(please refer my previous post), there can be quite a few scenarios in which error conditions can be addressed. One, not exactly sure though, is to fail the booking if redemption fails.


Your comments!

Regards,
Jatin

Originally posted by Jonathan Gerrish:


Hi,

Yes, I agree, I think we can assume the legacy system would not have been able to access the FMS database. The requirements don't state whether there is some backend process to credit milage, or if its a manual task for travel agents, as you say there must have been some other way out, not detailed in the requirements. As such I think this is beyond the scope of the project.

hello Jonathan,
Since we are reusing the existing FMS system, we should be using it the same way as existing FBN system with IMS database have been using it, otherwise there can be a risk of changing the FMS system (implicitly). In my opinion, only the implementation of the interface between legacy FBN with IMS database to FMS system needs to be changed (and not the interface), keeping the FMS system as it is.

Therefore, it is important, for me, to arrive at a logcal guess of what would have been the original interface. It could well be a set of background processes which had read the original IMS database and updated the FMS tables in case of legacy FBN system. So, if one have substantiate this guess, one can assume that the interface between the new FBN system and FMS system could also have background processes that now would read from FBN's Oracle database and update the FMS database.

Do the above guess answer your question. I guess, it needs some more discussion done below

Originally posted by Jonathan Gerrish:

My main issue is surrounding the redeption of milage.

i am assumping that redemption of mileage implies awarding mileage travel to a customer, and may logically lead to reduction/debiting the miles that has been accrued by a customer. Kindly confirm.

Originally posted by Jonathan Gerrish:

We would only want to show the Milage Redeption option on the payment screen if the user has a loyalty account, and has sufficient milage allowance to make a redemption. Then if they chose that option we'd attempt to redeem the milage. This to me implies an interface to the milage system like this:-

Interface LoyaltySystem {
boolean isRedemptionPossibleForItinerary(Itinerary it);
void redeemMilageForItinerary(Itinerary it)
}

My worries were around what happens if either of the systems fail at the redemption.... any thoughts?

Thanks, Jon

Thats why i had thought of a Mileage table in FBN's database (also in legacy FBN IMS d/b(please see my previous post). Now if you extend the assumption further what if you also assume some more background processes that reads FMS database and populates the Miliage table of FBN's database and does vice-versa as well. (This assumption can also hold for legacy FBN system with IMS database. Also, demerits were discussed in the previous post, regading having not most upadted Miliage data in Miliage table in FBN's database.

Now, new FBN system is as separate from FMS as was legacy FBN system. and You just worry about Mileage table in FBN's Oracle databse, as you are not going to update the FMS system at the same time and question of FMS system failing does not come in to equation.
I assume i am hitting the same ball as you and if it is, how do you find this approach?.

Thanks,

Jatin

Originally posted by Jonathan Gerrish:
Jatin, Hi...



Its atomic in the sense that the travel agent ensures that either both actions succeed, or both actions fail. Error conditions are not explicitly defined in the usecases. ie: what happens to the booking if the loyalty system is down. But you could expect that a travel agent would handle the error condition better than leaving either one of the systems in an inconsitent state?

Has anyone had good scores without the use of transactions, and what level of error handling have you guys assumed? What functionality have you assumed that the milage system provides?

Cheers, Jon

To keep it atomic, one may need to have a component that can update both the databases at the same time. Since, such a component would not have been possible in legacy FBN system, one can presume that legacy FBN may have used some other way out. More or less this should be the way the new FBN system should adopt, since re-usability of FMS looks to be an important requirement.

Since We say accruing mileages is the responsiibility of a backend process, one option can be to have a 'Mileage' kinda table in FBN and assume another such backend process that can map FMS system with this table(read from FMS...write into this table). So, you can have an atomic transaction woring now on the same database. Problem could be data in 'Mileage' table would not have most updated data and extent of stale data may depend upon the frequency of this backend process. What do you think of this?

Jatin