WebIndicium

(Design principles)

Alexander Bykovsky, Ruben Mikaelian

WebIndicium is a technology for highly data intensive, dynamic web applications.

It is not a language like Java or Perl. It is not a set of tools and libraries like ASP.

It is just a way to implement a modern application.

The basic concepts of WebIndicium are:

- Do not invent a wheel (no languages, no libraries, no custom solutions)

- KISS (Keep It Super Simple)

- Use existing proven and standardized technologies

- Separate the data and its representation

- Integrate data and business rules

We have everything to keep it simple.

Integration of data and business rules has been implemented in relational databases powered by SQL.

Separation of data and its representation has been implemented in XML powered by XSLT transformation.

Representation has been implemented in HTML, DHTML and related browser technologies.

Assemble everything together has been implemented in Service Oriented Architecture (SOA).

Implementation has been implemented in Object Oriented Design and Programming (OOD, OOP)

What’s left to do? Just keep it simple!

Integrating the data and the business rules.

In most cases, the web application is nothing more than a web interface for preexisting or predefined data structures. Web application is defined by some set of business rules which are valid in underlying data structure. Data structures currently are implemented using modern relational databases, such as Oracle, MSSQL, DB2, etc. Implementation of data structure must support static and dynamic data content, provide an efficient data extraction and data manipulation mechanisms. All of this and much more is implemented by any SQL database. Database tables store data and static business rules. Stored procedures help with data integrity and data manipulations. Views build dynamic virtual data representation. Finally, database keeps your data and rule integrity. It provides security, using proven and reliable built-in mechanisms.

This figure represents three main database subsystems.

The bottom one contains user’s data. It literally has everything - odd rules, fuzzy defined relations, weird logic and anything else.

Next layer is the “Data Structure Adapter” - the most challenging part of any project. When underlying data structure becomes very complex and business rules get ambiguous, creating such an adapter becomes real challenge. “Data Structure Adapter” provides mapping between custom data and preexisting rules to the representation acceptable by the “Interface Engine”.

The top layer is the “Interface Engine”.

“Interface Engine” is the working horse of the system. It implements a set of services in accordance with client’s requested functionality. Service can be as simple as returning static sets of data, or it can generate a request to build complex dynamic output and modify underlying user’s data as well. All this is glued together by SQL.

The key part of this architecture is encapsulation of the services implemented by the system. Introduction of “Data Structure Adapter” completely insulates the rest of the system from the user’s data details and business rules. Technically speaking, to port an application to another business domain, we only need to redesign “Data Structure Adapter”. It means: to rewrite some SQL code.

Its time to demonstrate, how the real world model looks like.

The figure below describes a generic structure of a web application server based on WebIndicium technology.

In this case, services provided by the “Interface Engine” include:

- Authentication service

- Xml formatted document delivery service

- Services to deliver pseudo-static content (xsl, css, javascript and images)

- NO service to deliver HTML. (Separate the data and representation).

Pseudo-static content is maintained by the “Interface Engine” and does not depend directly from user’s data – that is why we call it “pseudo-static”. It is important to state that “Interface Engine” provides a set of described services and nothing else.

Now we are ready for the next step.

Separate the data and its representation - document’s concept.

So far, we have not defined, what exactly we mean by services.

Any service is defined by a set of valid requests, valid responses and a service function, which was executed to generate a valid response. To define a service WebIndicium uses a document’s concept.

WebIndicium’s documents are different from familiar paper documents. Actual documents are instructions (or scripts) on how to process parameters (if any) passed within the request, how to change the internal state, and what to return as a result. For systems based on SQL databases documents are simply SQL scripts. These scripts must be stored in the same database and executed uniformly by the “Interface Engine”. A result of their execution is returned as a service response.

Acting with “Interface Engine” document will represent functionality similar (but not equal) to remote function calls in RPC, CORBA DCOM or Java RMI systems. Difference is simple but significant – WebIndicium’s document is neither an executable nor a script. It is just a part of the system’s metadata.

It is important to mention, that document must return the data in some format that is not associated with any representation. XML is a good and very practical choice in most cases.

One or more documents with related functions can be defined as a service. Some core services, such as User Authentication and Session Control, can be a part of the “Interface Engine”.

Representation.

To use the data returned by the service, we must transform it using appropriate rules. In the case of XML, the most obvious solution is the XSLT transformation, defined by a style sheet. In the case of web applications the style sheet must produce a HTML code, which contains some client style scripts, references to binary objects as images, references to other style sheets, and, possibly, something else.

We can store all related objects in the database and treat them as data.

Now the last step to complete the backend of the system is just trivial.

Simply add documents that will return the requested object of your choice.

In other words, already existing “Interface Engine” can be used as a mechanism to supply the style sheets, scripts, images and much more. Of course, the scripts and images are not representation independent and to process then “Interface Engine” must be smart enough. Document’s MIME type declaration will help to resolve this problem.

There is one important special case related to XSLT style sheets.

According to definition, XSLT style sheet is a valid, well-formatted XML document, and can be processed as XML document. It can be validated, parsed, or transformed by another XSLT style sheet. Power and flexibility added by this simple-to-use possibility is limited only by your imagination.

Assemble everything together - Service Oriented Architecture.

The backend described above can be used as a framework for almost any database application. The obvious advantage is simplification of implementation and maintenance for the client-side applications. In one word - encapsulation of the business rules on the server side will let you use tiny clients. Changes in business rules can be maid on the server without harming the client communications. “Data Structure Adapter” is the only place where the changes will appear. Clients will not only become tiny they will become highly structured and modular. Each functional module will use a related service published by “Interface Engine” to communicate with the server. Implementations can vary from direct XML processing to utilizing traditional database components.

We can consider the Web Service as another database application, which exposes system’s functionality to the web using well-defined Web Service interface. By implementing a simple web application, we can publish the system on the web.

This application must implement only a few web actions:

- Return a xml formatted requested document

- Return formatting style sheets (css, xslt)

- Return support files as JavaScript libraries and images.

Additionally, application can implement some other functionality according to custom requests.

Impressive extensibility can be achieved adding server side service consumption capability along with the server side data syndication. Imagine, that web server application is able to process web service calls referenced by document applying the rules (e.g. style sheets) provided by the document.

In simplest cases, results of this call can be returned as a part of the document, used to filter, validate, or modify the results requested by the user.

Implementation- Object Oriented Design and Programming (OOD, OOP)

Any service-oriented system, including WebIndicium, implies that most of service requests will be executed by a number of different systems (database, application server, client, etc.) working together. They can run in a polymorphic environment that includes different hardware platforms, operating systems, and locations.

The implementation of distributed OO systems is far out of the scope of this article.

We will discuss the implementation details of a real world system in following articles.

WebUtilis 4/10/2006