As already discussed, the user interface (UI) tier only knows how to present the data to the user. The database stores the data, usually for a variety of purposes beyond any one particular application. This leaves a lot of work to be done by that middle layer. A lot  of  architects  like  to  refer  to  the  middle  layer  as  containing  business  logic.  This euphemism seems to imply that the middle layer is a pristine set of simple, easy rules like  “fill  the  warehouses  to  80  percent  of  capacity”  and  “offer  10  percent  discounts across the board.” The client takes care of all the messy UI stuff, while the database does the hard work of managing the data. When you peel back and examine that middle layer, it usually doesn’t look like the drawings on the whiteboard. Instead, you find a lot of hard-coded SQL and UI code deep in the middle layer. Though many application development teams do their best to  separate  a  presentation  layer  and  a  database  layer,  it’s  hard  to  define  the  lines sharply. Even if you use a scripting language like Java Servlet Pages (JSP), the snippets of code usually have dependencies deep in the system. What if the UI designer decides they want a slightly different set of data returned, or they want it ordered in a different way? Then you have to find the SQL statement and change it. That might have reper- cussions elsewhere in the system. You might have to create a new class. Thus, to make a relatively simple UI change, you are forced to make changes at the database layer. When the system inevitably has to be extended, then you’ll probably find very little of your UI code to be truly reusable. Now, let’s assume, for a moment, that a particular application has achieved a good separation between the various layers. Everyone read all of the design pattern books and spent a lot of time at the whiteboard before coding started. They all had enough time to do the separation correctly, and the management or customer understood how important it is. There is still another problem: The output of the system is HTML. What if you want to make the data available to Web services or to a new platform such as wireless? Then you have to port the UI layer to an entirely new type of user interface. Because  the  code  was  written  with  only  HTML  in  mind,  you’ll  probably  have  to rewrite all of the interface widgets. If the system is perfectly designed, this is a lot of work. Now, imagine if the system isn’t perfectly designed. The Web is the greatest accidental application development platform ever. It started as an internal project at an academic institute in Switzerland and has grown into one of the great technological forces of our time. It has its complexities and intricacies, but it is infinitely adaptable. The key to the success of the Web is to understand it as an evolv- ing technology. The art of developing Web applications is also evolving, and a success- ful Web application developer is always on the lookout for the next evolution. Now, it’s time to see how XSQL greatly simplifies the process of developing for this platform. XSQL as a Keystone Technology XSQL is  a  keystone,  rather  than  a  cornerstone,  technology.  The  Oracle  RDBMS  is  a great example of a cornerstone technology. There are many companies whose entire businesses are built around their Oracle databases. Java and HTTP are also cornerstone technologies.  However,  XSQL  is  more  like  the  keystone  of  an  arch—the  piece  that holds the rest of the technologies together in a simple and elegant manner. Introducing Oracle XSQL 5 271209 Ch01.F  12/9/02  2:00 PM  Page 5