[Bernstein09] Section 3.7. Database Servers Versus Transactional Middleware

3.7. Database Servers Versus Transactional Middleware
Adatabase server is a relational database system that runs as amultithreaded server. It supports stored procedures that can be invokedby an RPC-like protocol. And, of course, it supports transactions. Ittherefore offers many of the main features of transactional middleware.It’s interesting to compare database servers to transactionalmiddleware, to see where these two technologies are similar anddifferent.
Storedprocedures are written in either a proprietary version of SQL or ageneral-purpose programming language, and can issue SQL requests to thedatabase system, just like a transaction server running in anapplication server. Thus, a request controller can directly call storedprocedures, instead of first calling a transaction server, which inturn calls a database server. Said differently, the transaction serverapplication can be written as a stored procedure. In fact, the requestcontroller application can be written as a stored procedure too.
Figure 3.9shows the process structure of transactional middleware and databaseservers. Most relational database systems today offer this databaseserver structure, including those from IBM, Oracle, Sybase, andMicrosoft. So why might one buy a transactional middleware product ifthe database server supports most of the facilities that we’ve beendiscussing in this chapter?
Figure 3.9. Transactional Middleware and Database Server Configurations. The database server architecture eliminates the request controller layer of the transactional middleware.

Onereason is scalability. In a multitier system running undertransactional middleware, if a machine becomes overloaded, one cansimply reassign request controller and transaction server processes toanother machine. Today, this isn’t very easy with most databaseservers, because the application runs in the same process and thereforeon the same machine as the database server. Spreading the workloadacross multiple database servers requires a request controller outsidethe database servers to distribute the load and to multiplex sessionsacross a large number of users (seeSection 2.6, Scaling Out a System).We expect this scalability advantage of transactional middleware willdecrease over time as database servers add more functionality tosupport partitioning and scalable data sharing. The capabilities of webservers also are growing, however, and are increasingly being used toroute requests directly to a database on behalf of a web browser client.
Likescalability, the issues that distinguish transactional middleware fromdatabase servers are changing with each new product release, so anylist of feature distinctions we give here would be quickly outdated.However, we can identify general areas where functionality differencesoften are found. The main ones are as follows:
Choice of programming language: Some database servers offer a more limited set of programming languages for stored procedures than application servers offer for transaction servers. And even when database servers support standard languages, they impose restrictions to ensure compatibility with the database software.
Implicit transaction bracketing: Many database servers require explicit bracketing of transactions using Start, Commit, and Abort, rather than allowing components to be tagged with transaction attributes, such as Requires New, Required, and Supported. The explicit bracketing of transactions makes it more difficult to compose them.
Transports: A TP system can offer both secure and reliable transport (written to a journal) between client and server. Most database systems don’t offer this.
Debugging: Some database servers offer weaker debugging and development tools than are available in a general-purpose program development environment. The latter are usually fully available when using a transaction server.
Interoperable distributed transactions: Most database servers offer distributed transactions with two-phase commit. However, they often do not offer distributed transactions across database servers from different vendors and other transactional resource managers, such as record-oriented file systems and queue managers. This usually requires a two-phase commit protocol implemented by transactional middleware or the underlying platform.
Communications efficiency: Some database server protocols are more efficient for pipelined transfer of large data sets than transactional middleware protocols.
Protocol support: Application processes running with transactional middleware can use all platform-supported protocols. By contrast, some database servers have limited protocol support. For example, they may not support HTTP, so remote requests to a database server need to pass through an application process, such as a web server.
Multitransaction workflow: Some transactional middleware products have more functionality than database servers in support of multitransaction workflows, such as the ability to configure resource dependencies and transactional compositions.
System management: Some transactional middleware products offer a richer system management environment than a database server offers. For example, it may allow prioritization of applications, application-based load control, remote name resolution, geographical entitlement, or application-based security.
Overthe past decade, the functionality gap between database servers andtransactional middleware has been getting smaller. Only time will tellwhether this trend will continue or transactional middleware will addfunctionality fast enough to stay ahead of database servers for decadesto come.