In the existing CGI process, when a user request comes in, a new process starts to handle the request. If a user makes a new request, the operating system forks the process corresponding to the program. When a process is forked, a copy of the process is created and made into a child process of the original process. Forking can affect system performance. The burden on the system that forking creates caused existing CGI users to seek new applications, resulting in appearance of Servlet, PHP, ASP, and JSP.

These programs are not written in C but in Java or Script language. While these programs may be easy for programming, discarding existing C programs and developing a new program is also a burden.

CGI developers must consider whether to discard their existing CGIs and introduce new programs, or to continue operating existing programs and increase the number of servers to reduce CGI burden. WebtoB introduces new APIs to resolve the developers' problems.

As an API for C programs, WBAPI reduces CGI program burden and minimizes CGI program modifications. Through these APIs, many users who use existing CGI programs can increase system performance.

As previously mentioned, when a new request comes in, the new program is forked and the request is handled and returned to the web server. The forking process becomes a burden when a system has to process many jobs.

The following figure shows how the CGI mechanism works in the Apache web server.

[Figure 9.1] CGI Operation in Apache

In the figure, the structure creates a CGI forking load whenever the web server has a new request.

WBAPI helps resolve the forking problem. In WebtoB, a process is not forked whenever a user sends a request. Instead, WebtoB forks these programs in advance (when web server boots up) and puts these programs into memory. It doesn't exit the process after the user request is processed but waits in the memory for future requests. By not exiting the process and not forking, WebtoB decreases the burden on the system.

WebtoB not only reduces burden but also manages programs designed by WBAPI. Thus, if the program terminates abnormally due to user or design error, a new program is started immediately. WebtoB can also adjust the number of programs. If the number of requests for a specific program is high, the program is executed more frequently in advance to reduce load.

The mechanism of WebtoB's WBAPI call is as follows.

[Figure 9.2] WBAPI in WebtoB

WBAPI is different from general functions that start with main(). A program written with WBAPI is generated as an independent process and works as a WebtoB internal process. Thus, the function does not start with main() but with Service Name. Service Name must be the starting name of the function and must be registered in the WebtoB environment file. Refer to "9.3. Environment Configuration" for more information.

In order to use WBAPI in WebtoB, WebtoB environment configuration and some programming are required. I.e., In the WebtoB environment configuration file, register the program's development by using WBAPI and how the program will be used.

The following is an example of the WebtoB environment file. The bolded sections are the basic configuration needed to use WBAPI.

*DOMAIN
webtob1

*NODE
webmain
    WebtoBDir = "/usr/local/webtob", 
    SHMKEY = 99000,
    Docroot = "/usr/local/webtob/docs",
    AppDir = "/usr/local/webtob/ap",
    Hostname = "webmain.tmax.co.kr",
    Port = "8080",
    JsvPort = 9099

*SVRGROUP
cgig    NodeName = webmain, SvrType = CGI
jsvg    NodeName = webmain, SvrType = JSV
ssig    NodeName = webmain, SvrType = SSI
wbapg  NodeName = webmain, SvrType = WEBSTD

*SERVER
cgi     SvgName = cgig, MinProc = 10, MaxProc = 10 
ssi     SvgName = ssig, MinProc = 2, MaxProc =2
jsv1    SvgName = jsvg, MinProc = 10, MAXProc = 10
webaps SvgName = wbapg, MinProc = 5, MAXProc = 5

*SERVICE
write_board  SvrName = webaps

*URI
uri1  Uri ="/svct/", SvrType = WEBSTD, SvrName = webaps

The SVRGROUP and SERVER sections must have the same basic configuration. In most environments, the configuration is the same except for the host machine name. In order to use an actual service, each service must be configured.

In order to start WebtoB, compilation through wscfl is usually required. After compiling with wscfl, a service table must be created in order to use WBAPI. Create a table by using the wsgst command in the bin/ directory. If wsgst is executed, WebtoB creates a service table that has the _svctab.c extension in the specified path.

wsgst

The following are description of how to use a service table by using the wsgst command.

This completes the preparations necessary to use WBAPI. Compile the program implemented with WBAPI to generate an executable file and register it as shown in the previous example.

Programs developed by WBAPI use special libraries, service tables provided by WebtoB, and a C language library. During compilation, the libraries and service tables must be linked.

The following is an example of a makefile for compilation in UNIX/LINX.

#Makefile.common
TARGET= webaps
APOBJS= ap.o

#hp 32bit
CFLAGS = -Ae +DA1.1 +DD32 -O -I$(WEBTOBDIR)
#hp 64bit
#CFLAGS = -Ae +DA2.0W +DD64 +DS2.0 -O -I$(WEBTOBDIR)
#sun 32bit
#CFLAGS = -O -I$(WEBTOBDIR)
#sun 64bit
#CFLAGS = -xarch=v9 -O -I$(WEBTOBDIR)
#Linux
#CFLAGS = -O -I$(WEBTOBDIR)
#ibm 32bit
#CFLAGS = -q32 -O -I$(WEBTOBDIR) -brtl
#ibm 64bit
#CFLAGS = -q64 -O -I$(WEBTOBDIR) -brtl

WEBTOB_INCDIR = $(WEBTOBDIR)/usrinc
WEBTOB_BINDIR = $(WEBTOBDIR)/bin
WEBTOB_LIBDIR = $(WEBTOBDIR)/lib
OBJS    = $(APOBJS) $(SVCTOBJ)
SVCTOBJ = $(TARGET)_svctab.o

.SUFFIXES : .v
.c.o: 
        $(CC) $(CFLAGS) -c $<

wbaps: $(APOBJS) svct
        $(CC) $(CFLAGS) -L$(WEBTOB_LIBDIR) -o $(TARGET) $(OBJS) $(LIBS) $(USERLIBS)

svct:
        cp $(WEBTOBDIR)/svct/$(TARGET)_svctab.c .
        $(CC) $(CFLAGS) -I$(WEBTOB_INCDIR) –c $(TARGET)_svctab.c

The following is example of a makefile for Windows.

#Makefile for Windows
TARGET = webaps.exe

LIBS    = /link $(WEBTOBDIR)\lib\aps.lib ws2_32.lib 
CFLAGS  = /D _DEBUG /I $(WEBTOBDIR) /Gd /MD /nologo 

APOBJ   = $(TARGET:.exe=.obj)
SVCTSRC = $(TARGET:.exe=_svctab.c)
SVCTOBJ = $(TARGET:.exe=_svctab.obj)
OBJS    = $(APOBJ) $(SVCTOBJ)

$(TARGET): svct $(OBJS)
        cl $(CFLAGS) -o $@ $(OBJS) $(LIBS)
        copy $@ $(WEBTOBDIR)\ap

svct:
        copy $(WEBTOBDIR)\svct\$(SVCTSRC)

clean:
        -del $(OBJS) $(TARGET)

After preparations for WBAPI have been completed, WebtoB and the programs developed by WBAPI start up and load into memory as process type.

CGI conversion is a function of WBAPI. WBAPI can be used to convert existing CGIs, to develop new applications, and may prove useful for developers accustomed to C programming. WebtoB will continue to support and improve WBAPI to eliminate scalability or compatibility problems.

In addition, It is possible to use service functions provided by an existing TP-Monitor through WBAPI.

WBAPI consists of INIT/DONE, ALLOC, GET, PUT/SET, SEND, COOKIE, SESSION, and ETC. This section gives a simple description of each API and its functions.

WBAPI will provide multi-thread functions in the future. For this, a specific data structure must be declared in each function. If a WBAPI program is written first, the service name is registered. At the time the program is registered, the structure WBSVCINFO is declared. WBSVCINFO must be declared in the head of each WBAPI function. All WBAPI functions in a program must have a structure with the service name declared as the first argument.

This section describes how WBAPI is used to convert existing CGI programs.

#include "qDecoder.h"

int strcheck(char *str) {
       if (str == NULL)
              return 0;
       if (strlen(str) == 0)
              return 0;
       return 1;
}

int main(void) {
       char *name, *title, *doc;
       char *email, *homepage;

       /* Get input values */
       name = qValue("writer");
       title = qValue("title");
       doc = qValue("doc");
       email = qValue("email");
       homepage = qValue("homepage");

       /* Check if input values are valid */
       if (!strcheck(name))
              qError("Enter a name.");
       if (!strcheck(title))
              qError("Enter a title.");
       if (!strcheck(doc))
              qError("Enter a body.");
       if (strcheck(email))
              if (!qCheckEmail(email))
                        qError("Enter a valid E-Mail address.");
       if (strcheck(homepage))
              if (!qCheckURL(homepage))
                        qError("Enter a valid Homepage URL.");

       /* Output result – Input check */
       qContentType("text/html");
       printf("<HTML>\n\n");
       printf("<HEAD><TITLE>Bestbook bulletin board – Post check</TITLE></HEAD>\n\n");
       printf("<BODY>\n");
       printf("<H2> Bestbook bulletin board - Post check </H2>\n");
       printf("<HR WIDTH=600 ALIGN=left>\n<BR>");

       if (strcheck(email))
             printf("<A HREF=\"mailto:%s\">%s</A>", email, name);
       else printf("%s", name);

       if (strcheck(homepage))
             printf("<SMALL>(<A HREF=\"%s\">%s</A>)</SMALL>", homepage, homepage);

             printf("You posted as follows.<BR><BR>\n");
             printf("<TABLE WIDTH=600 BORDER=1>\n");
             printf("<TR><TD><B>Title</B> : %s</TD></TR>\n", title);
             printf("<TR><TD>%s</TD></TR>\n", doc);
             printf("</TABLE>\n\n<BR>Posted in the board succssfuly.\n");
             printf("</BODY>\n\n</HTML>");
             qFree();
}