Re: How to migrate JavaScript+LiveWire application to Oracle Webserver ?

From: Rohrbacher, Boris <rohbo_at_sbox.tu-graz.ac.at>
Date: Sun, 21 Jun 1998 14:41:03 +0200
Message-ID: <358CFF5F.F9326152@sbox.tu-graz.ac.at>

Hi david tin

> We have an application using Netscape Enterprise server 3.x with SSL,
> Server-Side JavaScript and using LiveWire to connect to Oracle database.
>
> All access to Oracle db is via store procedure. We have facing serious
> problem when there are too many concurrent user (over 20), the server
> process die without a clue. We are thinking moving the application to
> Oracle WebServer. Could any one tell me that how Oracle Webserver
> supports the Javascript and will there be any significant changes to the
>
> application ? any help or information send to us will be very much
> apprieciated.

I'm working with OWAS x.x since two years. In our application we use a combination
of Javascript ( on the client browser ) and pl/sql on the database side. Pages are completely build
with PL/SQL.

OWAS supports a the moment three main cartridges : PL/SQL , JAVA, Perl, ( LiveHtml )
They are named cartridges because before any http - request is catched by Oracles Web Agent,
which checks out who should handle the request, handles it over to the appropriate cartridge to process the request. Unfortunally there is nothing like a Javascript - cartridges. But ask Oracle. Maybe there are plans ... .

As you sayed all access to Oracle is via stored procedure, means that you have a big part already done AND that you have already sufficient PL/SQL knowledge and practice.

I guess that Impact on your application depends in this situation mainly on how clear you differentiated between

) local Javascript code ( means Javascript that are to be executed on the client )
) page generating code ( means document.write( '<TD>' ... )
) how really object - oriented your code is.
) how complex your transactions are ( spawning more than one http-request or are always done with one)
) how you handle indentification ( if you use it at all )

To tell you in short what PL/SQL - cartridges consists of maybe give you an idea what would be waiting for your :

A http-request which should be handled by the PL/SQL cartridge specifies :

http(s)://the_server.domain:port/virtual_path/package_name.procedure_name?parameter1=value1& ...
where
the first part should be clear.
virtual_path is a mapping to a user/schema in the database. It is defined in OW Server configuration file

                     and is called a DAD ( database access descriptor).
                     OWS makes a Oracle connection as the user that
corresponds to the given  virtual_path.
 package_name.procedure_name     Is the program in the package that is
called.
                      As you can image of the above this has to exist ( or

be accessiable via a synonym ) in the schema OWS connects to.

? ... should be clear.

The PL/SQL - cartridge ( assuming it's already correctly set up ) getting this request handled over by Oracle Web Agent now connects to ORACLE and generates an anonymous PL/SQL block which looks principially like this

begin

    owa.init ;                                                     --

initiales some important package variables ...

package_name.procedure_name( parameter1 => value1 , ..... ) ; end ;

and executes it. Note that the PL/SQL cartridges automatically resolves any parameter for a package for you. So this is completelly transparent.

The called procedure then generates OUTPUT, which can be of ANY mime type. Programers have full control over what is send back to the browser.

The supplied packages for the PL/SQL cartridge consists mainly of a.) some procedure dealing with handling the incoming call. Normally you don't have to deal with them
b.) some procedures enabling you to write back to the web. These a completelly transparent to the user. Means you'd never have to think about who this

is done. You only call procedure an give them the HTML - Code you want to be transferred.

For instance : Building the the HTML header "can" look like this htp.p ( '<HTML><HEADER><TITLE irgendwas></HEADER>');

This is out of my point of view functionally equivalent to document.write( .. );

c.) Packages that covers almost any HTML - tag so that you don't have to hardcode each an every Tag but use procedures or function instead.

You CAN , but don't have to, code htp.p('<HTML'>); as htp.HTMLOpen ; The later being a procedure supplied by the PL/SQL cartridge.

  d.) a Security Package : for dealing with realms and user identification.
  e.) a Package that allows you to handle big texts, enabling you to do regular expression replacement.
  f. ) a package for optimistic locking, that is generating a checksum or a snapshot of all fields in a record as hidden fields in a form for later comparison

against the database upon callback of the user.

Transactions :
If you make no use of the special transaction feature of OWS 3.0 a transactions scope is a single request : Transaction starts when the PL/SQL cartridges

starts executing your procedure and ends with it.

To use the special transactions feature ( XA - modell ) you have to register the names of the procedures that starts and ends the transaction in the OW Server configuration.

Finally :

a.) Consider difference between your transaction modell and those you can achieve with OWS.

b.) If you have done all your page generating code with document.write you could easily replace it with htp.p

BUT I don't know how you handle an http- request.

Hope it is of any use. HTH.
Regards
Robo

Received on Sun Jun 21 1998 - 07:41:03 CDT