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 doesnt 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, its 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 youll probably find very little of
your UI code to be truly reusable.
Now, lets 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, youll 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 isnt 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, its
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 archthe piece that
holds the rest of the technologies together in a simple and elegant manner.
Introducing Oracle XSQL
271209 Ch01.F 12/9/02 2:00 PM Page 5