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).
DBPrism components
Wrappers: DBPrism accepts requests from different sources, then it needs to adapt them to the internal representation using components called wrappers, which are also responsible for returning the generated XML or HTML.
Engine: A component that implements the core functionality of DBPrism framework, it uses generic components in an internal format and doesn't deal with database-dependent information such as types of arguments supported by stored procedures, representations of generated pages, and so on. The engine uses the concept of the DAD to get the necessary information about username and password, as well as the type of database of a specific connection; this DAD is defined by the site administrator in the prism.properties file. This file also includes transactions defined by URL demarcation, connection pooling information, and other DBPrism parameters.
Adapters: Components that talk with database-dependent components. DBPrism includes one adapter for every database supported; by default it includes support for Oracle 7.x, 8i, 9i, and Oracle Lite, but the design permits future add-on support for other databases (see Figure 2).
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:
Matchers: Attempt to match a URI with a specified pattern for dispatching the request to a specific processing pipeline. Matchers help specify a pipeline processing for a group of URIs.
Generators: Used to create an XML structure from an input source (file, directory, stream, DBPrism, etc.). DBPrism generates the dynamic XML inside the database by executing a stored procedure.
Transformers: Used to map an input XML structure into another XML structure. For example, XSLT Transformer, Log Transformer, SQL Transformer, and I18N Transformer.
Aggregators: Content aggregation means that an XML document could be composed (aggregated) by many sub documents.
Serializers: Used to render an input XML structure into some other format (not necessarily XML), for example, HML Serializer, FOP Serializer, Text Serializer, and XML Serializer.
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.
<map:match pattern="/index.html">
<map:generatesrc="static/index.xml"/>
<map:transformsrc="stylesheets/static-xml2html.xsl"/>
<map:serialize type="html"/>
</map:match>
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
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.
Architecture
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:
Database metadata: The "lower level" of the metadata repository: tables, keys, columns, key columns, etc. This kind of metadata can be almost completely reverse engineered from the database dictionary.
Presentation metadata: Screen and reports definitions: the presentation metadata is created by the application developer when he or she defines the application. For this, a separate application was built (using MetaBOX, of course...).
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:
Multirow screens: Database records are shown one below the other.
Single-row screens: A single database record is shown.
Input screens: A collection of fields that have no relationship with a database record is shown; this is used for collecting user input, e.g., when running a wizard.
DML screens: A record can be deleted, updated, or inserted.
Search screens: For entering criteria used by Oracle Text and then cached in an internal cache.
Result screens: For browsing through the search results in cache (thus avoiding the need to search again when the Next Page button is pressed).
List of Values (LOV) screens: Multirow screens that are shown in a separate window when the user wants to find one or more values and put them in a field on the main screen.
Menus
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:
System tasks:
-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.
MetaBOX Tasks:
-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....
Server: The name of the server running the Web server
Port: The port on which the servlet engine (OC4J, Orion, Tomcat) listens
dbprism: The name of the DBPrism application deployed on the servlet engine
Webdemo: The DAD to use
demo_ie_mr: The name of the stylesheet (DEMO_IE_ MR.XSL). This is an input argument to the Cocoon Pipeline, defined as:
<map:match pattern="*/**">
<map:generate src="/webdemo/{2}"/>
<map:transform src="stylesheets/{1}.xsl"/>
<map:serialize type="html"/>
</map:match>
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).
Features
MetaBOX builds stateless applications, thereby allowing for simple deployment on the Internet. Some of its features are:
Domains (either enumerated or based on a query)
Oracle Text queries and caching of retrieved records
Generating menus based on database roles
Default values
Exporting/importing applications' metadata
Wizards determining a sequence of screens, based on user input and database data
Assigning (multilingual) error messages to database constraints
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:
Use of PL/SQL: With the MetaBOX concept "wrapper-stored procedures" are used. This means that every client application encapsulates the MetaBOX logic with an application-specific PL/SQL procedure: the wrapper. In this wrapper-stored procedure various tasks can be performed, such as the initializing of the application and adding application-specific logic. This existence of a wrapper-stored procedure allows you to use the robustness of PL/SQL programming language to tackle complex calculations and data operations. Object-oriented programming, creating complex data types, autonomous transactions...all this can be done with PL/SQL. Also, PL/SQL can wrap Java code stored in the database.
Logic in the database: Another way to manage complex applications is the use of views together with triggers instead of triggers alone. This feature of the Oracle RDBMS allows a data modeler to develop a complete set of tables, views, and triggers separated from the MetaBOX application. To store as much business logic as possible in the database with triggers and views is always a good thing. Anyone who has migrated an application from a client/server platform to an Internet-based platform knows that any logic stored in the screens needs rebuilding (and retesting). But logic stored in the database can be reused without a problem. In addition, putting the logic in the database instead of the user interface (screen) also reduces duplication of code when other applications operate on this data (e.g., batch procedures).
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.
Use of XSLT: The last part of managing complexity within the MetaBOX concept is the use of XSLT. Where Cascading Stylesheets (CSS) can give your screen another color or font, XSLT can create new buttons, assign new logic to these buttons, etc. Within the MetaBOX concept a set of general-purpose stylesheets is used by different applications. These general-purpose stylesheets perform functions such as determining the type of a field, retrieving a domain, printing the label on screen, and so on. In short, they perform the basic things that no application programmer wants to do time after time. To make sure the application developer can add his own application-specific code, the XSL:IMPORT element is used in conjunction with a "placeholder." Placeholders are present in the imported stylesheet and they can be overruled by the importing stylesheet - thereby allowing for application-specific output. This concept is shown in Figure 10.
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.
Conclusion
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.
Resources
www.dbprism.com.ar/dbprism/doc/Home.html
http://xml.apche.org/cocoon
www.importalis.com
http://otn.oracle.com
