| "The usefulness , or utility, of a network equals the square of the number of users." Metcalfe's Law Let's begin in the middle. The fact is that pure client/server is rare; it's just a simple way to talk about the subject. We usually ignore the fact that there might be something between the client and the server. This something has various purposes and goes by various names , like "Distributed Application Services," "Transaction Monitors," "Middleware," and "Middle Tier ." Whatever it's called, middleware usually becomes necessary when there's more than one transaction per second. Middleware's functions are as follows : -
To take the communications job out of the server's hands. Setting up connections, receiving messages, monitoring for timeout or network error, logging what's going in or outall of these functions could be done by the server, but throughput should get better if the server can concentrate on database management. -
To make basic error tests, such as whether the client is fetching when there's no result set available. We say "basic" error checks because we don't expect the middleware to understand SQL. The middleware package only knows that "execute SQL SELECT statement" and "fetch" are different message types. Therefore the middleware won't need to parse any SQL statements to determine whether an ordering error exists. -
To enforce business rules. If the client is requesting something at the wrong time from the wrong place, the middleware can catch that error. -
To customize the query. This is not easy, and it is a feature of more expensive middleware. The software must be able to parse the SQL statement in order to determine whether the syntax is correct for the specific server and, if not, fix it. -
To keep a pool of duplicate queries. This isn't easy either. If User SAM executes a SELECT * FROM Table1 statement and later User SUZIE also executes SELECT * FROM Table1 , then it might seem like the middleware can reuse SAM's connection to answer SUZIE's question. In fact, though, that's impossible unless the middleware knows that SAM and SUZIE are working with the same schema and similar privileges, and that SAM didn't change Table1 . It's good to write SQL statements that won't confuse the middleware. Here are some tips. -
Avoid unnecessary syntax shortcuts. Often these work with only one brand of DBMS. -
Use the same spacing and comments every time you repeat a statement. -
Always add schema qualifiers to table names. You might find yourself programming your own piece of middleware. When you do, remember to keep the tiers separate. The conventional separation logic is as follows: -
If a task is related to keyboards or screens, then the client handles it. -
If a task is related to databases, then the server handles it. -
If a task is related to message massages, then the middleware handles it. Notice that the middle tier doesn't do much on the way back; that is, server-to-client isn't much affected by the middle. The Bottom Line: Middleware Middleware's functions are (a) to take the communications job out of the server's hands, (b) to make basic error tests, (c) to enforce business rules, (d) to customize the query, and (e) to keep a pool of duplicate queries. Write SQL statements that won't confuse the middleware. Avoid unnecessary syntax shortcuts, use the same spacing and comments every time you repeat a statement, and add schema qualifiers to table names. If a task is related to keyboards or screens, then the client handles it. If a task is related to databases, then the server handles it. If a task is related to message massages, then the middleware handles it. |