|By Marcelo Ochoa||
|November 25, 2002 12:00 AM EST||
This article shows how to build database Web applications using Oracle, two open-source frameworks, and MetaBOX software. Building database Web applications is commonly a repetitive task; many such applications are based on insert/delete/update statements of tables in a form of simple rows, multiple rows, or master/detail combinations.
To make this kind of application, many products offer different solutions - we can divide them into procedural or declarative approaches. These products provide wizards or code generators to help developers in the developing stage.
Depending on which technologies these generators use - pure HTML or XML - developers need to work more or less to get the desired output and maintain their applications. The procedural approach requires developers to know what they need and how to obtain it. Code generators for this approach generally use some kind of metadata from the applications such as tables, views, primary keys, foreign keys, and so on, and generate templates of the code for the application. An example of this approach is JSP generator of Oracle9i JDeveloper.
Developers who work with the declarative approach handle more abstract concepts such as table usage, permissions on these tables, primary keys, foreign keys, LOVs, and so on.
Both approaches have benefits and drawbacks. For example, the declarative approach has good productivity, portability, quality, and performance behaviors, but it's less flexible, and the performance improvement is for a certain application's domain.
On the other hand, the procedural approach is good for performance and flexibility, but the environment is less productive and less portable, and the quality of the code depends on the developer's skill. This article will explore a product developed on top of two open-source projects, named MetaBOX, that provides declarative development for Oracle Web applications. It uses XML as the key technology to decouple presentation from content, because many of a Web application's changes involve presentation concerns.
MetaBOX uses the DBPrism Servlet Engine framework as a connector for the Apache Cocoon framework and generates the application's XML code inside an Oracle database running a stored procedure. This means that you use the database engine not only to execute SQL statements, but also to directly return a complex XML representation of the application data stored inside as well.
What Is DBPrism?
DBPrism is an open-source framework based on servlet technology to generate XML from a database. It began as servlet replacement for the Oracle Web Server PL/SQL Cartridge; then it was extended to generate XML into the database side, transforming it in an active database.
Other technologies, such as Apache XSP or Oracle XSQL Servlet, generate XML into the Web server side and use the database only to return SQL. They can use stored procedures, but 99% of these applications put the logic into the Web server side.
How does it work?
DBPrism is a middleware component that interprets a request from different sources and executes a database stored procedure using the information coded into the request.
DBPrism automatically transforms, for example, a standard HTTP request into a stored procedure call using the arguments extracted from the URL. After this execution DBPrism collects the generated XML, or HTML, and returns it to the requester.
Working as stand-alone servlet, DBPrism is fully compatible with the Oracle mod_plsql component, providing seamless integration with applications developed with Oracle WebDB or Oracle Designer Web Server Generator.
DBPrism also includes a DBPrismGenerator for the Apache Cocoon framework, which provides the framework with a new functionality and gets the XML from the database side, executing a stored procedure. This kind of XML generation moves application logic closest to the data and leaves presentation concerns to the Web server layer (see Figure 1).
Note about DADs: DBPrism uses the concept of DAD extracted from the URL information. This means, for example, for a URL like http://server:port/xmlj/samples/DEMOj.startup, that xmlj will be used as the DAD name; then in the prism.properties file there will be an entry identified by the key "xmlj", with the information to connect to the database. This information includes not only username and password, but also the type of database, for example, 8i or 9i; default page if no stored procedure is given in the URL information; and other database-specific information.
What Is Cocoon?
Apache Cocoon is an XML publishing framework from Apache Software Foundation. It uses XML and XSLT transformations as basic technologies and includes sophisticated implementation for caching, content aggregation (portal aggregation), and so on.
Cocoon is designed for scalability and performance because it uses a pipeline SAX-based approach, which means that Cocoon doesn't make in-memory, DOM-based representations of XML documents. Consequently, it doesn't require a great deal of memory to process large XML documents or multiple concurrent requests.
The Cocoon framework design provides multiple points of interaction to extend or customize components. As a basic mechanism for getting the XML source, Cocoon provides generators that interact with most data sources, including file systems, RDBMS, LDAP, native XML databases, and network-based datasources. DBPrism provides a new high-performance generator for Cocoon that includes support for parallel content aggregation and Edge Side Included Invalidation Protocol (www.w3.org/TR/esi-invp).
Cocoon's endpoints are serializers; they adapt content delivery to the capabilities of different devices like HTML, WML, PDF, SVG, RTF, and so on. You can run Cocoon as servlet (our approach) as well as through a powerful, command-line interface.
Separation of concerns (SoC)
Many products, such as Oracle XSQL Servlet or Sun's JSTL XML Utility tags for JSP, provide server-side transformation of XML using XSLT, but the most important innovation that Cocoon adds is the SoC-based design, which divides the development stage of a Web application into four separated areas joined by clear "contracts" that define their operability and concerns.
This concept allows separated people with common skills in different working groups to increase their productivity, while reducing management costs.
The pyramid of contracts defines the four areas of concern and the five contracts between them (see Figure 3).
The Cocoon pyramid model of contracts
Removing the contract between style and logic solves many of the problems of Web site development, because graphics designers and programmers have different skills. Developers concentrate their efforts on the application logic and content without taking into account presentation concerns. Graphic designers don't work with application logic; they concentrate their efforts on the look and feel of the application. MetaBOX software addresses two of these concerns, logic and content, using the declarative programming model.
Figure 4 shows the execution flow into the Cocoon system for every request. The request starts evaluating a regular expression matcher and defines which execution plan is used to generate the desired output. A particular execution plan could involve the following components:
A part of sitemap.xmap file is shown below. Sitemap.xmap file is a configuration file used by Cocoon to define its component and portal URL matching configuration.
The pipeline example shown in the preceding code defines a matching expression for the /index.html page of a particular Web site. This home page will be generated by loading a static page "index.xml" located in the "static" directory, then it will be converted using a stylesheet "static-xml2html.xsl" located in the "stylesheet" directory, and finally it will be serialized to HTML format.
MetaBOX is a software product based on the concept of self-describing systems. It enables software developers to build Web applications for the Oracle platform - applications that can be tailored to the personal preferences of individual end users.
As content and presentation are separated from each other in the MetaBOX concept (inherited from the pyramid model of Cocoon), applications are more manageable. This separation makes it possible to change the look and feel of an application completely, without having to change its code. All the output produced by MetaBOX is in XML format, and the look and feel is defined in XSL stylesheets (and Cascading StyleSheets when HTML is generated). This makes MetaBOX compliant with W3C-endorsed and supported standards. MetaBOX is developed using standard Oracle8i/9i components, allowing seamless integration with existing Oracle applications.
MetaBOX has all the benefits provided by declarative programming, plus personification, support for different media types, and multilingual support.
MetaBOX is based on a three-tier architecture. This means that client, Web server, and database tiers could all reside in different hardware.
The MetaBOX repository could manage different applications (client applications) with one instance of MetaBOX at runtime. This means that different applications will use the same MetaBOX engine, and this engine will generate the correct output for each application based on the user's input (request) and the application's metadata stored in the MetaBOX repository.
The Web server sends the client's instructions to the appropriate application. The application processes a user's request by calling one or more PL/SQL procedures. PL/SQL is Oracle's procedural programming language, which runs entirely in the database. PL/SQL is the fastest way to process data into the Oracle platform. The MetaBOX itself is built entirely with PL/SQL and consists of a number of stored procedures (packages).
The result of any command sent to MetaBOX is always an XML document, and it is returned to the Web server tier for rendering to the target output by Cocoon, which uses the appropriate XSL stylesheet. Users see the result in a Web browser or in another device such as a PDA or a PDF viewer.
Building Web Forms Using Metadata
Two types of metadata
Within the MetaBOX concept, two kinds of metadata can be stored for every individual application:
Types of screens MetaBOX can generate
Building a metadata-based environment means you have to think about what functionality your environment will support. MetaBOX supports the following screens, which are typical for data-oriented applications:
All these screens can be created in a declarative way: the application developer inserts records into the metadata repository, for example, when creating a new screen a record is added to the SCREENS/FORMS table.
Building screens with MetaBOX
Using MetaBOX to build a screen involves the following preliminary steps:
-Setting up Apache, which includes specifying virtual paths to image-files, CSS-files, etc.
-Setting up the application-specific XSL stylesheets at the specified locations; for a typical application these can be taken from the Console application.
-Setting up the DBPrism configuration: setting up a DAD.
-Setting up the Cocoon configuration: defining one or more pipelines.
-Creating the application.
-Reverse engineering the lower-level metadata.
Then the browser-based Console application can be used to create the first form (see Figure 5).
In this example, a DEMO application was created, after which the EMP(loyee) and DEPT (department) tables (from the Oracle Scott demo schema) were reverse engineered. An EMP record can reference a DEPT record with a foreign key.
In the screen capture, the application developer is about to start the form wizard, by which forms (screens) are created. We will create a multirow screen for the EMP table (see Figure 6).
In Figure 7, the Name is used for calling the form from the browser. The Title will be the title of the HTML page when the form is shown in the browser. The Description is for reference only. The Stylesheet can be used within the Console framework to identify the virtual path. When the form is called from a menu, the stylesheet will transform the data into the HTML Multirow screen. The TYPE=OUTPUT identifies the form as a screen that will show data from the database. The Browse Set Size determines how many records are shown on each page. Table Name names the table from which the data will be retrieved. (Note: this could very well be a view, in which records are sorted.) The last property of a form determines whether a reference to the database column is added to each Form Column (field). This must be Yes for any form that interacts with the database.
After clicking Finish on the last confirmation screen, the form is created. The form appears in the outliner menu of the Console application (see Figure 8).
Now the form is ready to be run on DBPrism/Cocoon. So in our browser we request: http://server:port/dbprism/webdemo/demo_ie_mr/scott.wrapper.webdem?p_con....
So Cocoon uses the first argument (DEMO_IE_MR), after appending the .XSL extension to indicate the stylesheet to use to transform the source (XML) coming from: /webdemo/ scott.wrapper.webdem?p_context_name=FORM_NAME&p_context_value=MR_EMPLOYEES.
The part starting with "scott." is the call to the application's wrapper stored procedure that will generate the XML.
As you can see, a fully functional screen is generated, with the ability to browse (next/previous page), filter, and sort. Of course the individual fields could be hidden, removed, reformatted, or given another label (see Figure 9).
MetaBOX builds stateless applications, thereby allowing for simple deployment on the Internet. Some of its features are:
How to take care of complexity
While creating simple applications is faster, easier, and cheaper when using metadata systems, this does not mean that using metadata makes it impossible to create complex applications. Within the MetaBOX concept, complexity is handled in three ways:
The rule is simple: think data. Put your code as close as possible to your data. The Oracle platform has many features (sometimes unknown to most servlet programmers) that can help you do this.
The general-purpose stylesheets have these placeholder templates in every part of the HTML, so the controlling application can steer the content of the HTML, while many difficult tasks (like drawing a field with a select box - a domain) are done automatically in the imported general-purpose XSLT logic.
Of course, the imported XSLT logic in the general-purpose stylesheets is quite complicated. However, in this concept, solving a problem once allows you to reuse your solution in a constructive way.
Using XML/XSLT in conjunction with metadata is a fine combination. The techniques are similar in the way they allow reuse of general-purpose code. Using these techniques together with the XML publishing framework Cocoon leads to robust, flexible, and database-centered applications.