DB4Web

DB4Web - “Database for Web” - was a commercial web application server sold by Siemens AG from 1997 until the early 2000s. It began as a gateway that let any browser read and update a relational database, and grew into a general integration server with adapters for SAP, LDAP directories, CORBA objects and Siemens’ own BS2000 mainframes. What makes it a language rather than just a product is the way applications were written: as method files, ordinary HTML pages interleaved with lines beginning with a dot - .SQL, .FETCH, .WHILE, .IF, .SET - which the DB4Web server parsed, compiled into an object tree and interpreted to produce the page.

It belongs to the same generation as Cold Fusion’s CFML, early PHP, Miva Script and Active Server Pages: tools built in the mid-1990s to answer the question of how to get a database onto a web page. DB4Web’s answer was unusually German-industrial. It was designed by a plant-engineering division rather than a web company, sold per machine with a price list of drivers, taught in three-day certification courses in Erlangen, and aimed squarely at organisations whose data lived in several incompatible systems at once.

A note on the year

The encyclopedia’s master list has no year for DB4Web. The German Wikipedia article says it was “developed in 1996”, without a source. That is plausible - a product shown in March 1997 was presumably being written the year before - but nothing in the archived primary material confirms it.

What the primary sources do show is this:

• The revision history printed in the Version 3.4 manual begins with “02/1997: Version 1.0”.
• The earliest press item on the product’s own news page is dated March 1997, and describes the Siemens Anlagentechnik group as having “now” brought the toolkit to market.
• The CeBIT trade-fair newspaper covered it on 17 March 1997, and Computerwoche on 25 April 1997.
• The standard page footer on the earliest archived site, captured in June 1998, still reads “Copyright © 1997 Siemens AG”.

This page therefore uses 1997, the year of first public release, and treats 1996 as an unverified development date.

History and Origins

A gateway from the plant-engineering group

DB4Web came out of Anlagentechnik (ANL), the Siemens group that built industrial plants, and specifically out of its Erlangen-based business field for IT services for industrial plants. The CeBIT newspaper item of March 1997 notes that this business field had been newly formed in the 1995/96 financial year. The group needed to publish its own data - course catalogues, spare-parts lists, descriptions of its service packages - to Siemens staff around the world, and a browser was the one client it could assume everyone had.

The March 1997 press release makes the pitch in terms that were typical of the period. Until then, it says, each database vendor supplied a web gateway that worked only with its own database. DB4Web would connect the database servers of different manufacturers - it names Oracle, Ingres, Access and BS2000 - to the customer’s existing web server, “and even combine them in a single query”. The stated benefits were about cost: no database client installed on each PC, no extra network routing, no expensive vendor development tools.

The same release claims that administration costs in industry and trade could be cut “by up to 20%”; the CeBIT newspaper, the same month, has the department offering to cut database operating costs “by 80 percent”. Neither figure comes with any measurement behind it, and they are recorded here only as examples of how the product was sold.

Rapid growth in 1997 and 1998

The pace of the first eighteen months can be followed on the product’s own news page, archived in June 1998:

Version 2.0 is the release that turned the method-file notation into something closer to a programming language. Its announcement lists a more open command syntax (indentation, case-insensitive keywords), “complete support for any dereferencing of variables”, stored procedures, more than 35 system variables, conversion functions for dates, money and quoting, and more than 50 worked examples shipped with the product. The manual still documents a _syntaxVersion variable that can be set to 1 to enforce the stricter pre-2.0 rules.

Version 2.5 pushed in two directions. For the language it added file functions modelled on C (fopen(), fgets(), fputs(), fclose()), string-based floating-point arithmetic, timing and logging functions, and a .UFETCH variant of .FETCH. For the platform it separated the core - network layer, preprocessor, parser, interpreter - from the drivers, which became shared objects on Unix and DLLs on Windows NT, discovered and loaded at server start. That change is what made the Extensible Driver API (EDAPI) possible: third parties could write a driver for their own data source and drop it into a directory.

Reorganisations and the 3.x line

The product kept its name and its Erlangen address while the Siemens organisation around it was renamed. The 1997 material is signed by Anlagentechnik; by 1999 the manual and website belong to ATD (Anlagenbau und Technische Dienstleistungen, “Industrial Projects and Technical Services”), unit IT Plant Solutions; from 2001 the pages carry the branding of I&S, Industrial Solutions and Services.

Version 3 arrived in late 1999, its manual cover advertising CORBA4Web, a module with its own small script syntax for calling CORBA objects from method files and, in the other direction, for letting CORBA applications invoke DB4Web. Version 3.4 followed in late 2000. Its manual is the most complete surviving description of the system and is the main source for the language details below.

Architecture

DB4Web was not an in-process web-server module. It was a set of cooperating processes, and the manual explains every one of them against a recurring diagram it calls the “BigPicture”:

Client and server communicated over TCP/IP using Sun ONC RPC - the manual points out that this is the same mechanism NFS uses. Because the two halves were separate, the web server and the DB4Web servers could sit on different machines, on different operating systems, and on different sides of a firewall; the manual has an appendix on DMZ configurations.

A “virtual database” was simply a named pool of server processes able to reach the same data sources. The client chose among them using what the manual calls a prediction count: a per-process counter, raised when a request was handed to that process and lowered again when it returned, with the lowest count taken as the process likely to answer soonest. Processes that failed a periodic loopback check were marked with a very poor count and no longer used. This was the basis of the product’s scalability and failover claims, which are architectural descriptions rather than published benchmarks.

Any CGI-capable web server would do. The manual gives configuration notes for Apache, the CERN httpd, Netscape’s servers, Microsoft IIS and NetManage.

Platforms

According to the vendor’s September 2000 price list, DB4Web was available for Windows NT, Windows 2000, SunOS, Linux, HP-UX, SINIX and IRIX, with other systems on request; the 2001 product sheet gives the same list with Reliant UNIX in place of SINIX (the same Siemens Unix under its later name). The manual says that ODBC data sources required the DB4Web server to run on Windows NT; the base package accordingly bundled the ODBC adapter on Windows and the MySQL adapter on Linux.

The Method-File Language

HTML with dots

A method file is a text file that is sent to the browser unchanged except where the server finds something to act on. There are two such things: a line whose first non-blank characters are a dot-command, and a variable reference written as a colon followed by a name.

The manual’s first complete example, slightly abridged here, counts the rows in Oracle’s sample emp table:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

.SET index="Access select Daten aus Scott Datenbestand"
<h1>:index</h1>
.SQL "oracle" "Scott" "" ""
select
  count(*) as THECOUNT
from
  emp
.ENDSTATEMENT
.FETCH
.ENDSQL
Die DB enthaelt :THECOUNT Eintraege

Several rules are visible here:

• Commands start with a dot and occupy a line of their own. From Version 2.0 they may be indented and may be written entirely in upper case or entirely in lower case, but not mixed.
• Variables are read with a colon: :index, :THECOUNT. A literal colon in output text has to be written \:.
• Comments are lines beginning with #.
• Everything else is output.

Because the colon is the variable sigil, the notation has no clash with HTML angle brackets, and a method file opens in an HTML editor as a mostly normal page. The 3.4 manual also allows DB4Web blocks to be wrapped in <script language="DB4Web"> tags, an option it says exists purely so that tools such as Microsoft FrontPage would not display the commands as body text.

Data access

The central command is .SQL, which takes four connect data values - driver, database name, user and password - followed by a statement terminated with .ENDSTATEMENT, then output to be produced, then .ENDSQL:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

<table>
.sql "oracle" "" "scott" "tiger"
  select * from emp
  where
    ENAME like ':name'
  .endstatement
  .while :_fetchstatus == 0
    .fetch
    <tr>
      <td align=right>:ENAME
      <td align=right>:SAL
  .endwhile
.endsql
</table>

The statement is not parsed by DB4Web at all. Variables are substituted and the text is handed to the driver, so whatever SQL dialect the target database accepts is what the developer writes. Each .FETCH retrieves one row and creates or updates one variable per column, named as the data source names it; the system variable _fetchstatus stays at 0 until the rows run out. Setting _downcase forces the generated names to lower case, which the shipped Oracle examples do because Oracle returns column names in capitals.

.SQL blocks can be nested as long as the inner block’s connect data differ from the outer one’s. One of the shipped examples copies the Oracle emp table into Ingres row by row, with an Ingres insert inside the Oracle fetch loop and a .COMMIT for each database at the end. This is the feature the marketing meant by combining sources “in a single query”.

As non-relational adapters accumulated, the word SQL became misleading - the “statement” sent to the LDAP driver is an LDAP operation such as add, modify or delete, and the M9750 driver drives a mainframe terminal session. The 3.4 manual therefore accepts .DATA and .ENDDATA as synonyms.

Error handling is by a single handler block. A database error transfers control to the most recently encountered .ONERROR … .ENDONERROR block, where _status and _statusText describe the failure; unless the handler ends with .EXIT, interpretation resumes after the .ENDSQL of the statement that failed. .COMMIT, .ROLLBACK, .AUTOCOMMIT and .DISCONNECT take the same connect data as .SQL.

Variables, types and expressions

Variables come into existence in four ways: from the URL query string or a submitted form, from a .FETCH, from a .SET assignment, or by dereferencing. All of them are global to the method and vanish when the page has been produced; state is carried between pages the way it was everywhere in 1997, as CGI parameters. Names beginning with an underscore are reserved by convention for system variables.

There are two types. The manual states it flatly: the server “understands string and integer variables”, with integers ranging from -2,147,483,648 to 2,147,483,647. .SET infers the type from the right-hand side. The conversion rules are simple and strict:

• A purely integer expression may use + - * / mod and the bitwise operators & | ^.
• If any operand is a string, every operand is converted to a string and only + (concatenation) is allowed. .SET var3 = :var2 * 5 with a string in var2 is an error.
• "" + :n turns an integer into a string; strtoint() goes the other way.
• In a condition, 0 and the empty string are false and anything else is true. Comparing a string with an integer compares them as strings.

There is no floating-point type. Version 2.5 added fsum(), fdiff(), fmult(), fdiv() and fcmp(), which do decimal arithmetic on numbers held as strings - the release notes give currency amounts as the reason.

The most distinctive feature is dereferencing. A double colon reads the variable whose name is stored in another variable, and a colon on the left of an assignment creates a variable with a computed name:

1
2
3
4
5

.set label_name = "l_title"
.set label_data = "This is the Title of the Web Page"
.set :label_name = :label_data
:l_title<br>
::label_name

Both output lines print the title. The manual’s worked example is multilingual labelling: select every label for the visitor’s language from a table, and inside the fetch loop run .SET :label=:label_data so that each row becomes a variable. The page can then refer to :l_title without a single .IF on language.

A second convenience is the implicit conversion prefix. Writing :_date_hiredate, :_money_sal or :_quote_name outputs the variable reformatted as a date, a money amount or a safely quoted string, according to the format variables _dateFormat, _moneyFormat and _quoteFormat. Other prefixes are _cgi_ (URL encoding), _encrypt_ and _decrypt_, _trans_, and _readfile_, which outputs the contents of the file the variable names.

Control flow and functions

The control structures are the expected ones, each with its own closing keyword:

1
2
3
4
5
6

.set max=12
.set i=1
.do
  We are in the loop, pass :i<br>
  .set i=:i+1
.enddowhile :i<:max

.IF / .THEN / .ELSE / .ENDIF requires .THEN on its own line in the 3.4 syntax; the manual notes that the keyword becomes optional from Version 3.5. .WHILE / .ENDWHILE tests before the body and .DO / .ENDDOWHILE after it. Loops are guarded by a _timeout variable, 20 seconds by default, after which interpretation of the method stops unless _timeoutContinue is set.

By Version 3.4 developers could define their own functions in the scripting language itself:

1
2
3
4
5
6
7
8

.function fett(text)
  .local fett_text
  .set fett_text = "<b>"+:text+"</b>"
  .return :fett_text
.endfunction
#
.set meldung = "Bitte warten"
.set fett_meldung = fett(:meldung)

Parameters are local automatically, other locals are declared with .LOCAL, and globals remain visible. A function that needs to modify its argument is passed the variable’s name and uses dereferencing. Functions called for their side effects are invoked with .CALL. The built-in library is small - about three dozen functions covering strings (strpos, strsub, strreplace, strword, upper, lower, ltrim), arithmetic (pow, sqrt, log, fak for factorial, random), files, date(), mtime() for millisecond timing, crypt(), and a set of stack functions.

Three commands are handled before parsing, by a preprocessor: .INCLUDE, which pulls in another file and may nest to a depth of 30; .RUN, which executes an external program and splices its output into the method source; and .UNIQUE … .ENDUNIQUE, an include guard that stops a file of function definitions from being read twice. At run time .EXEC hands a block of shell commands to a Bourne shell on Unix or the command interpreter on NT and returns the output in _execReturn. The manual is candid about that one: “the security risks are obvious”.

Compilation

By Version 3.4 a method was no longer interpreted directly from text. The manual describes a pipeline of preprocessor, just-in-time compiler and interpreter. The compiler tokenises the expanded source and builds an internal object tree, reporting a syntax error with the last 50 tokens for context; the tree is stored in a Dynamic Method Cache and reused until the modification time of the method file or any file it includes changes, with the least recently used entries evicted when the cache fills. A command-line tool, d4w_cc, could compile methods ahead of time. Database connections were likewise kept open and reused per combination of database, user and password, which the manual calls “another secret of DB4Web’s performance”. No measurements accompany any of this.

Is it “PHP-like”?

German Wikipedia describes DB4Web’s scripting language as having “a syntax modelled on PHP”. The documentation does not bear that out. The Version 3.4 manual never mentions PHP, and the notation - dot-commands at the start of a line, colon-prefixed variables, .ENDIF and .ENDWHILE terminators - resembles neither PHP nor any other language closely enough to name a model with confidence. The leading colon happens to be how embedded SQL writes host variables, and dot-commands at the start of a line are familiar from older text formatters, but the documentation claims no such ancestry. For that reason this page lists no influences in either direction. It is also worth knowing that the code sample in the Wikipedia article gives the connect data with the database name first, whereas the manual’s order is driver, database, user, password.

Data Sources

The list of adapters is the best summary of who DB4Web was for. The 2001 product sheet names eighteen:

• Relational databases: Oracle, Informix, Ingres, IBM DB2, Adabas D, MySQL, and anything reachable through ODBC (Access and Microsoft SQL Server, on Windows)
• Siemens BS2000 mainframes: SESAM/SQL, UDS/SQL, and the 9750 terminal interface, which let a method drive an existing mainframe application as if it were a single terminal
• Other enterprise systems: SAP R/2 and R/3, Adabas C, ObjectBase, CORBA (through CORBA4Web)
• Network services: LDAP/X.500 directories, IMAP mail servers, and “WWW” - other web pages treated as a data source
• Store: a driver for a local file depository, used for reading, writing and uploading files

Each was a separately priced item. In the September 2000 price list the base package - client, server, documentation, the Store adapter, plus ODBC on NT or MySQL on Linux - cost 7,500 DM (3,835 EUR); the May 2001 presentation adds that the licence was per machine, regardless of the number of CPUs, server processes, clients or applications. Individual adapters ran from 1,500 DM for MySQL or LDAP to 4,500 DM for CORBA4Web, the driver-development API cost 12,000 DM, annual maintenance was 20% of list, and the three-day “DB4Web Certified Engineer” course in Erlangen was 3,840 DM per participant.

For applications that outgrew HTML forms, DB4Web also shipped Java class libraries (D4WMethod, D4WException) so that an applet could call a method file and receive its result set as data rather than as a page.

Security

DB4Web is one of the few products of its kind whose name survives in vulnerability databases. On 17 September 2002 Stefan Bagdohn of Guardeonic Solutions posted an advisory to Bugtraq showing that the db4web_c client would return arbitrary files from the server if an absolute path was placed after the virtual-database name in the URL - /etc/hosts on Unix, boot.ini on Windows. A related report showed that, on a server configured for verbose debug messages, a crafted URL made DB4Web attempt a TCP connection to any host and port, with the resulting error page revealing whether the port was open. The two are recorded as CVE-2002-1483 and CVE-2002-1484.

The advisory’s timeline is a model of how such things should go. The vendor was notified on 29 August, acknowledged by telephone the next day, and had a patch and customer notification out on 16 September. The fix, shipped as replacement client binaries for Versions 3.4 and 3.6 on Windows, Linux, HP-UX, SINIX and SunOS, rejected absolute paths, drive letters and ../ sequences in the request. The advisory thanks “the DB4Web team for good cooperation and fast response”.

Decline

German Wikipedia’s account of the end - that PHP, at first used only for small home-page projects, grew steadily more robust and pushed DB4Web into the background, and that development was halted in 2003 - is unsourced but fits what can be observed. The archived product site shows no version after 3.6. The domain went on serving the product pages for several more years, and captures from 2004 and 2006 show them framed by a Siemens industry site that was itself still generated through db4web_c URLs. By 2011 db4web.de answered with a redirect to a Siemens page whose path was simply db4web_obsolete.

The commercial logic is not hard to reconstruct. DB4Web’s selling points in 1997 - one tool for many databases, no client installation, a simple notation for HTML authors - were by 2003 available at no cost from PHP and from Java application servers with JDBC drivers for the same databases. A per-machine licence with separately priced adapters and a proprietary scripting language was a hard proposition against that, particularly outside the Siemens customer base where the BS2000 and SAP adapters were the differentiator.

Current Relevance

DB4Web is a dead product. It was never open source, it is no longer sold or supported, no interpreter is available to download, and there is no Docker image or emulation route to running a method file today. What survives is documentation: the 1998 and 2000-2003 product websites in the Internet Archive, including the Version 2.5 release notes, a price list, a slide deck, the hotfix read-me and the complete Version 3.4 system description. Any DB4Web applications still in existence would be inside organisations that have not published the fact.

Why It Matters

DB4Web is a well-documented specimen of a design that many teams arrived at independently in the mid-1990s: take an HTML page, mark some lines as instructions, substitute variables into the rest. Seen beside its contemporaries it shows which parts of that design were inevitable - fetch loops over a result set, form fields arriving as variables, includes for headers and footers - and which were local choices, such as the colon sigil, the strict two-type system, and the decision to keep the interpreter in a separate pool of processes reached by RPC instead of inside the web server.

It is also a reminder of how much of the early web’s plumbing was built by companies that were not web companies. A plant-engineering group in Erlangen needed to put spare-parts lists and mainframe screens in front of colleagues worldwide, built a tool, productised it with a price list and a certification course, and maintained it responsibly for at least five years - the last documented fix is the September 2002 security patch. The language it left behind influenced nothing that followed, but its manual explains, more carefully than most, exactly what problem a 1997 web developer was trying to solve.

Sources

This page is based chiefly on archived primary material: the db4web.de site as captured by the Internet Archive in 1998 (news items, press excerpts, reference list and Version 2.5 release notes), in 2000-2003 (home pages, product sheet, training page, hotfix read-me), the DB4Web Systembeschreibung Version 3.4 (Siemens AG, 2000), the September 2000 price list and a May 2001 presentation. The 2002 vulnerability is documented in Guardeonic Solutions Security Advisory #01-2002 as reposted by LWN.net. Dates for the start of development (1996) and its end (2003) come only from the unsourced German Wikipedia article and are flagged as such above. Customer names and usage figures are the vendor’s own and have not been independently confirmed.