Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it fo开发者_如何学Ccuses on one problem only by editing this post.

Closed 5 years ago.

Improve this question

I am interested how to they to the following:

(because of my English some phrases can be strange :) )

Let assume that we need a software for a big airline company with 200 airports far away each other, each having 10 software clients.

The system uses 3 tire architecture.

Is there only one middle tire (probably cluster of application servers) that all clients connects to, or each airport has his own database, application server (independent identical systems) and over night the dbs are synchronized to a central warehouse?

If all clients connect to the same middle tire, and this tire is very very far away, how do they handle connection errors ? Can they afford the internet latency ?

Regards

---

I guess just an FYI: for a real airline, the 2-tier approach (more or less) is used. For example, the biggest GDS (Amadeus) really gets by with just a presentation layer (coded in Java) and a data/comms tier (one copy (heavily RAIDED) sitting in one place). This is critical, as real-time accuracy is important for an airline (eg. you need to control booking down to the seat-level or you lose complete control over inventory). This data/comms tier is mainframe based, lives in Germany at a single data centre and has 8 real-time redundancy backups. That gives you an indication of how important it is to have a single version of the data, regardless of where it's consumed. Amadeus uses almost NO distributed data at all. What makes it able to handle the huge transaction volumes on the one database is the simplicity of the data model (eg. the PNR concept for passenger journeys). So.. the key factors are : extremely high reliability, and great comms speed working within a simple data structure environment. Mainframes and assembler to the rescue! There is even a customised OS to do all this: TPF - sold by IBM with its core components built over 40 years ago. It provides ultra-high transaction rates, and extreme stability. It's correspondingly very expensive as you might expect.

---

It depends!

• What internet connections exists, bandwidth / latency / reliability.
• How much data will be transferred.
• What are the availability requirements, is this flight control or work time reporting?
• How often will data change
• Should changes from one user propagate to other users at other airports as soon as possible?
• Are there synchronization requirements, like booking of flight tickets (if one airport books a seat on a given flight, other airports must immediately be blocked from booking that seat on that flight)

---

There are many different ways to develop a n-tier architecture. The one they choose depends on their specific requirements.

If they need to absolutely make sure the software can operate even if there is no Internet connectivity, and up-to-date data is not important, then they could use a database at each location.

If they can tolerate network connectivity problems but they need to ensure all data is up-to-date, then it could be a web application, with all tiers in one location, with a web browser acting as a thin client.

Or a rich client could connect to a middle-tier application server at a central location.

In any case, connectivity problems are outside of the domain of the software -- in this case, it becomes important to establish a service level agreement (SLA) with the network provider and arrange for backup connections to ensure reliable network operation.