 |
|||||||||
|
|||||||||
|
|
The example is one that I use all the time. In fact, I am so inspired by this particular example that I have actually coded it up myself a few times, and at one point considered developing it into a commercial product that I could sell. Alas, time constraints prevented me from getting any such effort off the ground.
Picture a large restaurant with multiple services they offer. They might have three or four different themed dining rooms (including one that is an arcade). Each of the dining rooms has waitstaff that service the dining room. There is a host(ess) waiting at the entrance to each individual dining room that gives you an estimate on how long your wait will be, might give you a "pager" if the wait is particularly long. To make things more interesting, there are actually two separate kitchens. One kitchen is often used for catering and in-house buffets and also supplies "bar food" to the arcade area while the other kitchen has more normal operations. The first kitchen can be used for overflow if the regular dining rooms start creating too much demand. They also have a website that shows the menu, services, and even lets people make reservations online. The reservations made online need to be available for the host of any dining room, and the hosts need to be able to know the current average meal time and current status of each dining room to give an accurate estimate to customers. In addition, the owner of the restaurant wants the waitstaff to be able to take orders on PDAs so that orders can be sent back to the kitchen without the waitstaff having to make unnecessary round trips. All of this stuff must be able to communicate seamlessly with every other part of the system, and it needs to be done in a way that is scalable, easy to maintain, secure and reliable with failover. The system should be expandable so that if the restaurant owner opens five more restaurants in his chain, the software will work just fine, and if he wants to log all the activity so it can be put in a warehouse in the future - he wants the system to be able to handle that expansion quickly and cheaply.
I have actually heard some or all of these requirements from clients in the past (though not specifically for the restaurant industry). Now picture the solution:
What I like about this architecture is that if you look at the requirements for the application, you might think that it is a huge daunting task and will take a truckload of time and money and resources to build. The fascinating part about it is that if you design things in a peer "bus" style service-oriented fashion, you can produce small, entirely functional pieces of the overall system in extremely short periods of time. As each new component is made available, it can simply be rolled out into the restaurant for additional functionality without disturbing any of the existing applications/services running.
As new functionality is desired, it can be rolled out independently of any of the other pieces of the system that are currently running. For example, to create an application that keeps track of all restaurant activity and then stores that activity in a database suited for data warehousing and OLAP, ROLAP, etc - all you need to do is create an application that listens to all of the various back-end peer meshes and logs the activity.
I realize that restaurants might not be up your alley as programmers, but I thought I would try and shed a different perspective on the architecture I am using to build the Ulysses Agenda application to see if it might inspire some people to start thinking about using WCF and WPF in some unbelievably cool and creative new ways.
