13.2 Group Two: Enterprise Architecture Questions

The questions in this second group are targeted at the enterprise-level architects , those who are responsible for making sure the different fortresses work together as a single, well-oiled machine.

Question 9: Do we have the right number of fortresses?

Be sure you have the right number of fortresses. If you have too many, you will have various problems:

You will spend too much time on interfortress communications. Drawbridge communication is relatively slow compared to intrafortress communication.
You will sacrifice transactional protection for closely related work. Transactions should not flow across drawbridges .
You will find it hard to scale your system. Cluster algorithms logically work best at the fortress level.

So you don't want to have too many fortresses. But you also don't want to have too few fortresses. Too few fortresses, in the extreme, is no fortress architecture at all!

Question 10: Are all drawbridge requests idempotent?

Make all of your drawbridge requests idempotent. I discussed the idea of idempotency in Chapter 10 (Internet Fortresses). In theory, idempotency is a drawbridge feature that is most important for presentation and Web service fortresses because of the high (relative) rate of drawbridge failure for those types of fortresses. However, all drawbridges have some risk of delivery failure. The best protection you have is to design your drawbridges so that all requests are idempotent. Then if there is ever a question as to whether a request was delivered, the request can be delivered a second time without risk.

Question 11: Are all drawbridge requests for substantial work?

Many people think the software fortress architecture will not perform well because of the cost of drawbridge communications. They are right about the cost of drawbridge communications, especially as compared to the relative speed of component-to-component communications, or the lightning speed of object-to-object communications. However, these people are missing the point. It is not the cost of the drawbridge communications that is significant. It is the ratio of the cost of the drawbridge communications to the cost of processing the work request.

Let me give an example. Is 10 milliseconds for a drawbridge delivery expensive or not? It depends. If it takes 200 milliseconds to complete the work request, then the cost of the drawbridge adds only 5 percent. If it takes 1 millisecond to complete the work request, then the cost of the drawbridge adds 1,000 percent.

Do not use a drawbridge for idle chatter! Sending one 500-byte infogram will cost about the same as sending one 50-byte infogram and about one-tenth the cost of sending ten 50-byte infograms. Make every request count. Design your fortresses so that you send more information in fewer infograms. Do not try to improve overall performance by eliminating fortresses; instead, improve performance by eliminating infograms (or at least get rid of as many as you can).

Question 12: Do we have any tightly coupled transactions across fortresses?

Never allow a tightly coupled transaction to span a drawbridge. As I discussed in Chapter 3 (Transactions), a tightly coupled transaction guarantees that a collection of updates will be done either en masse or not at all. You should use tightly coupled transactions frequently within the fortress, but they should never be allowed to leave the fortress. If they do, then an unlucky fortress is going to be forced to hold open database locks until another lazy, worthless fortress decides to return from its coffee break. This is serious violation of the prime directive, which is, of course, that the fortress is the trust boundary.

Question 13: Are all drawbridges heterogeneous asynchronous?

For drawbridges, I strongly favor the heterogeneous asynchronous flavor. I discussed this in Chapter 6 (Asynchronous Drawbridges). However, the use of heterogeneous asynchronous drawbridges is not a hard-and-fast rule. It is not uncommon, for example, to find a homogeneous synchronous drawbridge connecting a presentation fortress to a back-end business application or treaty management fortress. But there is no question that the preponderance of synchronous communications in the world today is due much more to ignorance than to technical necessity. If you are in a design review, subject every drawbridge that is not heterogeneous asynchronous to a serious cross-examination as to why it was designed the way it was.

Question 14: Does all interfortress communication pass through drawbridges?

Make sure all interfortress communication passes through drawbridges. Keep in mind that the technology doesn't enforce this rule. Technically, there is no reason that the presentation fortress couldn't make a component-style method invocation directly to a business application component. It would probably even be faster to do so. Do not succumb to this temptation . Communication needs to pass through well-defined and monitored ports, which is the role of the drawbridge and the guard. Make sure the walls of the fortress are designed in such a way that direct communication through the fortress walls is impossible ; no holes in the ceiling, no back doors, no trap doors, no hidden tunnels.

Question 15: Have we considered all of the risk factors inherent in our presentation and Web service fortresses?

Do everything you can to protect your Internet fortresses. Review the security recommendations I made in Chapter 10 (Internet Fortresses). Take them as a basic starting point. Assign security specialists at your company who keep up with current threats.

Keep in mind that it is ultimately impossible to protect either presentation or Web service fortresses. If somebody wants badly enough to break into them, chances are they can. So look at your presentation and Web service fortresses very carefully . Ask yourself what the implications will be when the horrid ones do penetrate these fortresses. What damage could they do to your Web site? How difficult would it be to fix the damage? What proprietary data and algorithms could they look at? Do these fortresses contain information that would allow them to penetrate deeper into your enterprise?