13.3 Group Three: Fortress Architecture Questions

The questions in this third group are targeted at the fortress-level architects , those who are responsible for the individual fortresses .

Question 16: Are we considering fortress-appropriate technologies?

You wouldn't believe how much time is spent by presentation folks arguing about which is better: COM+ (a .NET technology) or EJB (a J2EE technology). Similar hours are wasted by business application folks arguing about the merits of ASP.NET versus JavaServer Pages.

If you are a presentation programmer, COM+ and EJB are technologies that are totally irrelevant to your life. You should be debating ASP.NET versus JavaServer Pages. If you are a business application fortress person, you are in exactly the opposite situation.

One of the advantages of the software fortress approach is that it helps partition the confusing collection of software technologies into manageable segments. When you're looking at different technologies, first understand to what fortresses they belong. Then consider them only if they are relevant to your type of fortress. Ignore them otherwise .

Question 17: If we must use a synchronous drawbridge, do we have an asynchronous back end?

As I said earlier, my preference is for heterogeneous asynchronous drawbridges . I also pointed out that this option is not always desirable, especially when you're connecting to an Internet fortress. If you find yourself in a position where you really need a synchronous drawbridge, try to back it up with an internal asynchronous communication as soon as possible.

One good strategy is to have the guard accept the synchronous request. Then the guard breaks up the request into two segments. The first segment is the part of the work request that must be done synchronously. That part is done, and the result is returned to the requesting fortress. Once the synchronous portion of the request has been completed and the result returned, the guard makes an internal asynchronous request for the remaining work.

For example, suppose you're writing a system to process credit cards for stores. You have a presentation fortress that accepts Web requests to process a credit card and a business application fortress that does the credit card processing. Keep in mind that the store has an impatient customer waiting for a cashier to complete the purchase.

The cashier fills in the credit card and customer information on the browser (using emissary code) and sends that information to the presentation fortress. The presentation fortress validates the input information and ensures that the request is authenticated, as well as it can. Then it sends the request to the business application fortress.

The business application guard accepts the information en masse and splits it into the synchronous segment and the asynchronous segment. The synchronous segment is the segment that must be completed before the guard can send a return infogram back to the presentation fortress.

Let's say that the only information the presentation fortress really needs back is an authorization code. The synchronous segment will then include the following steps:

Verifying the customer information
Checking that the purchase is within the customer's credit limit
Assigning a unique authorization code to this particular purchase

The asynchronous segment is the actual posting of the sale to the customer account. This does not need to take place immediately; it can be done in five minutes or even five hours.

Figure 13.1 illustrates this architecture.

Figure 13.1. Synchronous Drawbridge with Asynchronous Back End

The ideal situation, then, is to use an asynchronous drawbridge wherever possible. Where it is not possible, back up the synchronous drawbridge with an internal asynchronous request as soon as possible, encompassing as much of the overall workload as possible.

Question 18: Are we using more than one technology base within a single fortress?

Using more than one technology base within a single fortress will cause you many integration problems. J2EE and .NET are not exactly compatible stablemates, and neither are the programmers who work in those technologies. This rule is true even when two J2EE-based technologies are being usedsay, IBM's WebSphere and BEA's WebLogic. You can use them both, but keep them out of each other's face. One fortress, one technology.

Question 19: Have we designed a scale-out architecture?

Sooner or later, if you're lucky, you will have to accommodate a lot of users. Or maybe if you are not so lucky. Therefore you need to plan a strategy for increasing your workload capability. As I have discussed, there are two approaches: scale-up (replacing your small machine with a large machine) and scale-out (getting more small machines and managing them as a loosely coupled cluster). The best approach is to use both. Scale up the data strongbox, and scale out everything else. Because most data strongboxes don't require a lot of scaling (and even if they do, there aren't many architectural issues in doing so), you can focus your energy on scaling out everything else.

The approach of scaling up the data strongbox and scaling out everything else has the advantage of dovetailing nicely with improved reliability. It has the disadvantage of requiring that you design your system appropriately. I have discussed the scale-out architectural requirements in the fortress-specific chapters (Chapters 10 and 11), but in general the most important requirement is the incorporation of a load-balancing algorithm, such as IP load balancing or asynchronous drawbridges. Make sure that you have planned your architecture so that it is consistent with the scale-out approach.

Question 20: Have we designed a fortress architecture that can leverage loosely coupled clusters for reliability?

Assuming that you built your system to scale out using loosely coupled clusters, you are very close to getting high reliability for free (well, for very low cost). I have discussed the architectural requirements in the fortress-specific chapters, especially Chapters 10 and 11, but the most important requirements have to do with state management, transactional integrity, and idempotency. Being sure you understand these issues, design your fortresses properly to leverage loosely coupled clusters not only for scalability but also for reliability.

Question 21: Have we designed adequate security for each of our guards ?

Building good guards is probably the toughest job in the software fortress architecture. The guards need to deal with encryption, authorization, authentication, and a seemingly unlimited number of other security- related issues. One could write a book just on guard design. The task is very specialized. Go through an exhaustive review of everything the guard is expected to protect against and how the guard will do this.

Question 22: Have we built effective walls around the fortress?

Having good guards is of little value without good walls. The walls are what guarantee that the guard will be used. Many technologies can be leveraged to provide automatic fortification of the walls. If this is a business application fortress, use the role-based security that is part of your component infrastructure to ensure that components inside the fortress accept requests only from other processes inside the same fortress. Use data strongbox (database) security to deny access to processes outside of the fortress.

During your design review, try to imagine how someone might be able to break through the wall, decide if the risk is great enough to protect against, and if so, make sure you have taken adequate precautions .

Question 23: Are we using only homogeneous synchronous communications within the fortress?

In general, asynchronous technologies are too slow for communications inside the fortress. The major exception to this rule is when you are creating a back end for a synchronous drawbridge, in which case you will want to make a single asynchronous request inside the fortress. I discussed this topic earlier, in Question 17. The typical intrafortress communications technology should be homogeneous synchronous.

There is no reason for having heterogeneous synchronous intrafortress communications because heterogeneous synchronous is slower than homogeneous synchronous, and it provides no benefit other than its support for heterogeneity. Heterogeneity is never an issue inside the fortress, as I discussed in Question 18.

Question 24: Do all of our outgoing communications pass through envoys?

It is much easier to maintain a fortress if all outgoing communications pass through envoys. The envoys protect the business logic from changes in the drawbridge technologies and, to some extent, from changes in the treaty. With envoys, the business logic need understand nothing about the underlying interfortress communication system.

Question 25: Is all of our data being stored in the data strongbox?

This seems like a silly question. Where would you store data other than in a data strongbox? In fact, however, too many programmers think they can write a more efficient database than the database vendors can. They believe they can optimize the transactions, do better caching, or do faster disk I/O. Do not allow this. Databases are highly specialized. It is too easy to write a caching algorithm that works fine for one machine but then corrupts the database when that one machine turns into a cluster. My advice is simple: Use the data strongbox. Don't write your own. Buy one from a vendor that knows what it's doing.