Summary

In this chapter I have given an example of how one might approach a real problem using the software fortress model. The most important lessons in this chapter are these:

• Plan on several iterations when developing a software fortress architecture. Even with a relatively simple problem, I used two iterations.

• Use the TADs and SADs to help you analyze the overall complexity of your architecture.

• Don't get carried away in creating software fortresses. Software fortresses are not objects. You don't need many of them. Unless there is a good reason for having functionality in different fortresses , don't do it.

• Drawbridge communication is expensive. Don't do too much of it, and when you do do it, make it count.

• When you must use a synchronous drawbridge, do as little of the work as possible synchronously.

• When using asynchronous drawbridges, use heterogeneous technologies. There just isn't enough benefit (at least today) with the homogeneous asynchronous drawbridges .

• When using synchronous drawbridges, use homogeneous technologies where possible because they offer more guard support (at least today) than do the heterogeneous synchronous technologies.

• Treat all input to a presentation or Web service fortress with great suspicion.

• Authentication in a presentation or Web service fortress is a tough problem, and you will probably have to live with some trade-offs.