12.2 Service Fortresses

The term service fortress refers to a miscellaneous assortment of fortresses that provide shared functionality that is needed by multiple fortresses within the enterprise.

Many people confuse service fortresses with linked libraries. A linked library can be either shared (meaning that the same binary is shared by many processes) or unshared (each process has its own binary). A linked library may be written in an object-oriented programming language.

A service fortress differs from a linked library in that it also represents a significant amount of shared data. It is the data strongbox more than the shared functionality that defines the service fortress. The rule of thumb, then, is that if only functionality needs to be shared across the enterprise, the implementation should be a linked library. If the functionality also needs to share significant amounts of data across the enterprise, the implementation should be a service fortress. Sometimes the distinction between shared libraries and service fortresses may seem arbitrary.

Linked libraries and service fortresses are not mutually exclusive. For example, a service fortress that is providing compensatory transaction management (a topic I will discuss in more detail shortly) could also provide a library used to request transaction management. In this case the library is linked to the donor fortress and becomes, in whole or in part, the envoy. Recall that the envoy is the code responsible for preparing the request on the donor side and passing it over the drawbridge to the receiving guard.

When the envoy is implemented as a linked library, the drawbridge between the two fortresses becomes an implementation detail of the service fortress. In general, only the envoy and the guard need to agree on the drawbridge, and both, in this scenario, are provided by the same party.

The most common service fortresses, in my experience, are those dealing with broadcasting, data sharing, security, and loosely coupled transaction management. Most are likely to be fortress veneers on a purchased technology. I'll take a look at each of these in turn .

12.2.1 Broadcast Service Fortresses

Broadcast service fortresses can broadcast information to many other fortresses. In a credit card system, a broadcast fortress could be used to broadcast information about stolen credit cards. In an insurance corporation, a broadcast fortress might disseminate information about new policies. In a manufacturing environment, a broadcast fortress might be used to solicit bids for subcontracted materials and components .

The most common broadcast model considers two types of fortresses: those that create information, often called publishers ; and those that want to hear about that information, often called subscribers . The broadcast fortress receives the information generated by the publishers and makes sure that it is sent to the various subscribers. Figure 12.3 shows how publishers, subscribers, and broadcast fortresses are related .

Figure 12.3. A Broadcast Fortress and Its Users

12.2.2 Data-Sharing Fortresses

Data-sharing fortresses share information throughout an enterprise. A data-sharing fortress is usually just a fortress overlaid on a shared database, and technically it may be just the database. My own preference is not to use data-sharing fortresses because they make ownership of the data difficult to manage. But in some cases sharing a certain amount of data might make sense. Figure 12.4 shows how a data-sharing fortress might be related to others in the enterprise.

Figure 12.4. A Data-Sharing Fortress and Its Users

12.2.3 Security Fortresses

Most security systems are based on a trusted authority. I discussed the main approaches to security in Chapter 7 (Guards and Walls). The two most common types of systems are shared-key systems, like Kerberos, and public/privatekey systems, like Secure Sockets. Both types depend on trusted authorities, although the role of the trusted authority is quite different for each. In both cases, the ultimate goal is to create and transport a temporary shared key that can be used as a basis for securing the drawbridge connecting two or more fortresses. Figure 12.5 shows the relationship between a security fortress and its clients .

Figure 12.5. A Security Fortress and Its Clients

12.2.4 Loosely Coupled Transaction Management Service Fortresses

A loosely coupled transaction management ( LCTM ) service fortress manages transaction-related communication, particularly that communication needed to coordinate loosely coupled transactions. Because the work of an LCTM fortress can be relatively complicated, I'll look at it in more depth.

I discussed the general ideal of transactions in Chapter 3 (Transactions), both the tightly coupled (strong transactional guarantee) and loosely coupled (weak transactional guarantee) variety. I also pointed out that we don't allow tightly coupled transactions to cross fortress boundaries, even if technically we are allowed to do so.

Let's consider an example of where an LCTM fortress might come in handy. Suppose I wanted to set up the ObjectWatch Web site to allow clients to sign up for classes through a browser-based interface. I know that most people who take my classes are high-level architects or CTO types. I also know that even though I teach classes in perhaps 20 locations throughout the world, most of the students will be traveling to the class and will therefore also need a hotel room.

Given that most students will need a hotel, I decide to negotiate a favorable rate with a major hotel for each workshop and allow students to book the hotel at the same time that they book the seat in the class. Suddenly my system is rather complicated because I have various outcomes to consider.

Suppose Kate wants to take the upcoming workshop in Paris , a city in which we have negotiated a special package with the Star Plaza. She decides she wants both the workshop seat and the hotel room. Our system must be able to handle either of the following possibilities:

The Paris workshop could have a seat available, and the Star Plaza could have a room available.
Either the Paris workshop or the Star Plaza or both could be sold out.

Overall, several fortresses need to coordinate their work as follows :

The ObjectWatch CustomerGateway presentation fortress will deal with Kate's browser.
The ObjectWatch WorkshopBooking business application fortress will book Kate's workshop seat.
The hotel's PartnerGateway Web service fortress will accept programmatic Internet requests for room bookings. There will probably be other back-end hotel business application fortresses behind this one, but that is not my concern.
The bank's PartnerGateway Web service fortress will accept programmatic Internet requests for credit card charges. Like the hotel's fortress, this fortress will have other back-end fortresses that don't concern me.
The ObjectWatch PartnerGateway Web service fortress will accept programmatic Internet responses from ObjectWatch partners .

A fortress overview document (FOD) maps out the overall relationships of these fortresses. I described FODs in Chapter 2 (Diagramming Software Fortresses). A FOD for the hypothetical ObjectWatch (my company) system might include the figure shown in Figure 12.6.

Figure 12.6. Hypothetical ObjectWatch Architecture

Kate's browser will be hooked up to my CustomerGateway fortress, which will be hooked up to my WorkshopBooking fortress. The CustomerGateway fortress will communicate with my WorkshopBooking fortress to book Kate a workshop seat. To book a seat, the WorkshopBooking fortress needs to communicate with a bank's PartnerGateway fortress (to charge Kate's credit card) and the hotel's PartnerGateway fortress (to book Kate's room).

The fortress communications are shown in the SAD (sequenceally diagram) in Figure 12.7. SADs were first discussed in Chapter 2 (Diagramming Software Fortresses). As a reminder, in Figure 12.7 PF stands for presentation fortress , BAF for business application fortress , and WSF for Web service fortress .

Figure 12.7. SAD for ObjectWatch Architecture

Most of the time, the communication between fortresses is boringly routine:

Kate enters her information.
The system checks if a workshop seat is available. It is.
The system checks if a hotel room is available. It is.
The system charges Kate's credit card and tells Kate her seat is reserved.
The system books the workshop seat.
The system books the hotel room.
The system tells Kate she has a confirmed seat and hotel room.

But a million things can go wrong, any of which turn this routine sequence of interactions into a bewildering minefield of error conditions. For example, between the time the PartnerGateway fortress told us there was an available room and the time we actually booked the room, the hotel could sell out. Now we have sold Kate a workshop seat she doesn't want (because she has no hotel room) and we have already charged her credit card!

We can solve this problem by introducing another fortress whose only roles are to keep track of how each of the other fortresses is doing in terms of successfully accomplishing its workload, and to make this information available for each of the participating fortresses.

This fortress is the LCTM (loosely coupled transaction manager) software fortress. It plays a role similar to that played by a distributed transaction manager (DTC) in a tightly coupled multiple-resource transaction, as described in Chapter 3 (Transactions). It lets each one of the fortresses with responsibility for its piece of the overall loosely coupled transaction know how the loosely coupled transaction as a whole is making out. If, for example, the PartnerGateway fortress fails to book the seat, the LCTM fortress will deliver the bad news to the WorkshopBooking fortress so that it can release Kate's seat.

Widely accepted standards for LCTM fortresses would be great. If such standards existed, it would be possible to construct workflows between fortresses very easily, as long as each one knew how to work with the same LCTM fortress. The closest we have to an accepted standard for LCTM fortresses is something called the Business Transaction Protocol (BTP), which has recently been adopted by a group called the Organization for the Advancement of Structured Information Standards (OASIS).

BTP as a standard has problems. First, it is overly complicated. It tries to solve every possible coordination problem rather than solve the typical problems in a straightforward manner. Second, although the BTP authors include many important companies (such as Sun and Oracle), the two most important companies in the area of Web service transactions (IBM and Microsoft) are conspicuously missing. Third, the standard is barely off the press. It is still in version 1.0, and as I write this, it was finalized less than six months ago. If the standard survives at all, we can expect major changes over the next few years as the comfortable academic world of theoretical white papers meets the unforgiving dog-eat-dog world of the watch-your-back Internet.

Although BTP is far from universally accepted, it is still a good basis for discussion. Using the BTP terminology, then, I will describe in general how an LCTM fortress might work.

First let me introduce some BTP terms from the perspective of software fortresses. I will list them in an order that allows one term to be defined in relationship to others:

Business transaction. A business transaction is a group of tasks that need to be coordinated in a loosely coupled fashion. In my example, the combined task of booking both a workshop seat and a hotel room is considered a business transaction.

Coordinator . The coordinator is the one coordinating the communications between the fortresses with respect to the business transaction. In my example, the coordinator is the LCTM fortress.

Initiator. The initiator is the one starting the transaction. In my example, the initiator is the CustomerGateway fortress that starts the transaction on Kate's behalf .

Context. A context is the information uniquely identifying a specific transaction. The context flows with the workflow as part of the infogram passing over the gateway(s). Different fortresses use the context to know which transaction they are currently processing. In my example, Kate would have a unique transaction context that would be different from, say, Mike's. When the CustomerGateway fortress asks the WorkshopBooking fortress to book a seat, it includes in the request the information describing Kate's context.

Create. Create is a message from the initiator to the coordinator asking it to create a new context. In my example, the CustomerGateway fortress would ask the LCTM fortress to create a new context for Kate's workload.

Enroll. Enroll is a message from a software fortress to the controller that it wants to participate in the business transaction. When the fortress receives an infogram, it examines the accompanying context to see if it has already notified the controller that it is part of this transaction. If not, it enrolls at that time. In my example, the WorkshopBooking fortress would enroll with the LCTM fortress upon receiving the "book room" request from the CustomerGateway fortress, as would the PartnerGateway fortress upon receiving the "book hotel" request.

Confirm. Confirm is an instruction from the initiator to the coordinator (LCTM) that the transaction is ready to finalize. In my example, the CustomerGateway fortress will tell the LCTM fortress to confirm the transaction once both the WorkshopBooking and the PartnerGateway fortresses have indicated that they have accepted their respective bookings.

Cancel. Cancel is an instruction from a particular fortress that the transaction has been canceled . The fortress issuing the cancel request can be the initiator or any of the participants . The cancel request is the opposite of a confirm request. In my example, the WorkshopBooking fortress might be told to cancel the transaction if the PartnerGateway fortress could not book the hotel room.

The sequence of completing the business transaction (booking both a workshop seat and a hotel room) looks like this:

Kate enters her information into the ObjectWatch CustomerGateway fortress.
The CustomerGateway fortress passes the request to the ObjectWatch WorkshopBooking fortress.
The WorkshopBooking fortress asks the LCTM fortress to create a context for Kate.
The WorkshopBooking fortress books a seat using Kate's context.
The WorkshopBooking fortress asks the bank's Partner Gateway fortress to bill Kate's credit card using Kate's context.
The bank's PartnerGateway fortress agrees to do so.
The PartnerGateway fortress (or a downstream bank fortress) enrolls with the LCTM fortress using Kate's context.
The WorkshopBooking fortress asks the hotel's PartnerGateway fortress to book a hotel room using Kate's context.
The PartnerGateway fortress agrees to do so.
The PartnerGateway fortress (or a downstream hotel fortress) enrolls with the LCTM fortress using Kate's context.
The WorkshopBooking fortress tells the LCTM fortress to confirm (finalize) the business transaction using Kate's context.
The LCTM fortress asks each of the fortresses that had previously enrolled with Kate's context to prepare to finalize the transaction. Each agrees or refuses.
If each fortress agrees, the LCTM fortress tells each in turn to confirm (finalize) the transaction.
Each fortress assumes that what it has done on behalf of Kate's context is now finalized.
The LCTM fortress tells the WorkshopBooking fortress that the business transaction was successfully completed.

All of this may seem complicated, but from the perspective of any single fortress, there isn't too much to it. Here is the algorithm from a participating fortress's perspective:

The fortress is asked to do something using Kate's context.
The fortress enrolls with the LCTM fortress using Kate's context.
The fortress does whatever it does (e.g., book a room).
The fortress is told to prepare the transaction using Kate's context.
The fortress decides it is either willing or not willing to do so.
The fortress is told either to confirm or to cancel the transaction using Kate's context.

Notice how close all of this is to the way in which transactional resources coordinate with a distributed transaction coordinator, as discussed in Chapter 3 (Transactions). In fact, the algorithms are almost identical. The LCTM fortress is very similar to a distributed transaction coordinator (DTC). A participating fortress is very much like a transactional resource. Table 12.1 compares the two systems.

Table 12.1. Comparison of Tightly Coupled and Loosely Coupled Transactions

Functionality	Tightly Coupled	Loosely Coupled
Work unit	Transaction	Business transaction
Coordination	DTC	LCTM fortress
Participant	Transactional resource	Software fortress
Algorithm	Four-phase commit	Modified four-phase commit
Transactional guarantee	Strong	Weak

The last item in Table 12.1 is the critical differentiator between the coordination of a business transaction (loosely coupled transaction) by an LCTM fortress and the coordination of a tightly coupled transaction by a DTC. The difference is in the degree of the transactional guarantee.

When asked to commit a tightly coupled transaction, a transactional resource, such as a database, makes a strong guarantee that it will either commit the work (make the work absolutely permanent) or roll it back (make the work absolutely disappear). There is no middle ground.

A software fortress coordinated by an LCTM fortress has a great deal of leeway in its interpretation of commit/confirm or rollback/cancel. A hotel might interpret a commitment to hold a room as just a commitment to hold any room, not necessarily the one that was promised . Or it might interpret the commitment as just a promise to find a room in any hotel in the same city.

The interpretation by the fortress of what commitment means is not the problem of the LCTM fortress. However, it may be an important factor in the willingness of other fortresses to form collaborative relationships with that fortress.

The BTP may or may not become a widely adopted standard for LCTM fortresses, or even for transactions spanning the Web. In any case, it is representative of the communications and treaties that must occur among fortresses that want to define overall business transactions, fortresses that want to be part of those transactions, and fortresses that will be needed to coordinate the overall communications among the interested parties.