NukeEmUp
asked on
oraperl and stored procedures
Can someone enlighten me on how to call PL/SQL stored procedures from oraperl?
I have, BTW, also asked this question in the perl topic area just in case folks there don't hang around the Oracle topic area.
I have, BTW, also asked this question in the perl topic area just in case folks there don't hang around the Oracle topic area.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Services A new concept is being introduced in release 3.0: Web Application
Server Services, which allow us to create a highly component- based
set of services for cartridge developers. The idea is to create a set of
common functions and services that can be used by any cartridge.
These services are detailed in the following. Authentication
The extensible Authentication Service is responsible for authenticating
users. We have the most advanced authentication model in the
industry, and support the following types of authentication:
-Basic and Digest: Username with encrypted password stored in
the filesystem
-Basic Oracle: Username with encrypted password stored in
Oracle7 (this is the Oracle user/password)
-SSL-3 digital ID with Certificate Revocation List management
-IP address, host, and domain-name filtering
-Fully customizable by each individual cartridge
These authentication methods are available to all cartridges.
Furthermore, client authorization may optionally be handled
separately. For example, the PL/SQL cartridge can be configured to
authenticate users using Oracle7 database account information, but
authorize database access by logging on to the database using a
non-privileged shared account. This makes sense since stored
procedures are always executed with the privileges of their owner.
Identifiable Client
HTTP is still a stateless protocol, and although HTTP 1.1 is just around
the corner, we still lack a universal way of uniquely identifying a
client (more precisely, a client context). Today, developers must solve
this programmatically with session IDs and cookies, but in release 3.0
this functionality is managed automatically by the Web Application
Server and is a prerequisite for other services. The developer need not
care how this is implemented (and it will surely change over time).
Conversational Cartridges
The idea of a conversational cartridge is to allow an application to
allocate resources and bind these to a specific instance of a cartridge on
behalf of a client browser. These resources may be private memory,
external devices, or maybe even foreign database connections. Oracle
Web Application Server guarantees that a client will be returned to the
same instance of a conversational cartridge. Transactions
Until Oracle Web Application Server 3.0, one needed a transaction
processing monitor to support transactions in (web) applications.
Oracle Web Application Server now allows Web application designers
to use the scalable all-or-nothing capabilities without the complexity
of a TP monitor. Web-based order entry applications can be easily
designed so that all the actions required to create an order, including
all the user interactions, are performed within a single all-or-nothing
transaction. When the user decides to follow through and place the
order, the transaction is committed to make all the effects permanent.
Should the user's machine be turned off or the user walks away
without finishing the order, a simple application or database time-out
will abort the transaction and automatically restore all the database
resources to their values as if the order never took place.
This architecture provides unprecedented web scalability and
performance because all the data for an order can be stored in the
reliable database where the enterprise is already run. With all the order
information stored in the database, the Application cartridge is free to
serve interleaved requests of many users without juggling the details of
each user's order. For high performance and reliability the Web
Application Server uses Oracle's transaction manager already in every
version of Oracle's database for the past 15 years. It is this same
transaction manager ensuring consistency for the current
mission-critical applications entrusted to Oracle's server.
The Web Application Server is distinct from TP monitor solutions for
the web because it alone supports transactions with the universal client,
a browser without specific plug-ins or Java interpreters. The Web
Application Server does not need to run a Java applet to manage
transactions from the web browser. It uses standard HTTP. This also
improves performance because no applets need to be downloaded for
transaction management. ICX
Inter-Cartridge Exchange (ICX) is a portable inter- cartridge
communication protocol strongly resembling HTTP. It allows one
cartridge to embed a call to another cartridge, sending the result
directly back to the client, or returning to the initial cartridge for
further processing (or embedding). The cartridge receiving an ICX
request sees no difference from a standard HTTP request, and thus any
cartridge is by default able to respond to a request. This opens the door
for developing a new class of cartridges, which are highly specialized
and not normally invoked directly by a client (our ODBC cartridge is
an example of this as you shall see in a moment). On another front, our
RDBMS kernel group has implemented ICX as a callout mechanism
for stored procedures starting with Oracle7 release 7.3.3. This will
enable stored procedures to embed calls to any cartridge, and allow any
stored procedure to make use of new applications implemented as cartridges.
Content Storage API
The capability of managing large binary objects has been implemented
as a simple API allowing developers to manipulate BLOBS without
having to use Oracle OCI or ODBC. Meta-data for each object may be
stored and queried through the API, and objects may be created, copied,
retrieved, and destroyed. This service is unique to Oracle's Web
Application Server and provides a portable repository with superior
concurrency over any filesystem in addition to the ability to store
virtually unlimited numbers of objects. Our obvious roadmap for this
service to add more sophisticated text- processing functions, such as
indexing and thematic classification in future releases. New Cartridges
Oracle Web Application Server is mostly a Web Request Broker
release. We have nonetheless improved the functionality of several
cartridges and also added new ones. These are detailed in the
following: Perl (new) Perl is the dominant scripting language for CGI
programs on the web today. Similar to how we integrated the Java
VM, the Perl v5 interpreter has been implemented as a cartridge
providing improved performance and scalability over the CGI
approach. The Perl v5 DBI extensions to Oracle7, Sybase, etc. and
Oraperl emulation layer work fine and enable any existing Perl
program to be re-deployed in more efficient settings. ODBC (new)
The ODBC cartridge is intended to be used as a component service
from another cartridge. An incoming request contains a SQL
statement, and the results are returned by default as an HTML table,
but may also be formatted according to a format-string submitted
along with the SQL statement. We believe this cartridge will
primarily be used in conjunction with the LiveHTML cartridge (see next).
LiveHTML The server side include engine has been enhanced in two important
ways: first, a language binding to ICX allows any cartridge to provide
dynamic content to a parsed HTML document, and second, submitted
HTML forms parameters are made available as variables in the
document, enabling parsed HTML files to be the recipient of a
submitted form. We feel that this provides an extremely flexible
environment for entry-level application development: any scripting
language may be used (currently Java, PL/SQL, and Perl are
supported). Contrast this to Netscape and Microsoft who force you to
use their language. The Bottom Line
Our whole product strategy is to deliver an evolutionary transition
from client/server to a CORBA based NCA platform using the web as
a catalyst. Naturally, cartridges developed today will continue to work
tomorrow. Today's simple request/response driven web cartridges will
continue to coexist with tomorrow's more advanced CORBA
cartridges, and the whole point is that the Web Application Server
services (for instance transactions) are available consistently among
different types of cartridges using evolving underlying technology.
The whole point is to provide technology insurance and upwards
compatibility for our customers. +==+References:
3. Soln# 2082025.6 WHITE PAPER - TRANSACTIONSSolution ID : 2082025.6
For Problem : 1034841.6
Affected Platforms : Generic: not platform specific
Affected Products : Oracle Web Application Server
Affected Components : WEBSERVER GenericAffected Oracle Vsn : GenericSummary:
WHITE PAPER - TRANSACTIONS+=+PART 2: GETTING TRANSACTIONAL
This section compares the transactional platform of Oracle Web
Application Server 3.0 with the piecemeal platform offered by
Microsoft. As we shall see, Microsoft's platform was not originally
designed for the Internet, and although it would be unfair to not
acknowledge some of the advances that have been made in the pure
transaction management space of the Microsoft Active-X platform,
this does not translate into an attractive solution for the Web. The rest
of this paper explains why. Overview
The clumsiness of Microsoft's Internet afterthought is apparent. Most
applications need to be developed in a mixture of one of their scripting
languages as well as one of their ActiveX-enabled programming
languages. Microsoft's design is a vendor lock-in, while Oracle offers
industry standards such as X/Open's Tx and XA. These same standards
are supported in products from IBM, Sybase, Informix, BEA, just to name a few.
Microsoft wants to lock you into DCOM, OLE DB, and Active- X.
While Microsoft does support XA, ODBC, and HTTP, beware. They
do not work together. You can have transactions from your browser to
the database under one of two conditions: either you (and all the
Internet users you want to reach) use Microsoft products with
Active-X running everywhere, or you write your own transaction
management code like we offer in the Web Application Server. Allow
us to save you the trouble.
In contrast, Oracle Web Application Server 3.0's architecture was
designed for the Internet and uses open standards for maximum inter-
operability. Application cartridges (the functional equivalent of a
Microsoft Active Server Page) can use X/Open standards to
communicate with any XA- compliant resource manager.
Oracle Web Application Server 3.0's transaction model: simple and
based on open standards Behaving like a TP Monitor
A TP Monitor multiplexes requests from a large number of clients,
enabling very large user population to be supported. The Web has
inherited some aspects of traditional TP Monitor systems also, since
HTTP requests are multiplexed by the HTTP server engine in a similar
manner. TP monitors do have other features also, for instance the
ability to perform load-balancing as an integral part of the client
multiplexing.
How does Oracle Web Application Server 3.0 compare with other web
servers and TP monitors in the traditional TP Monitor space? Well, it
turns out that our Web Application Server is very similar to TP
Monitors like Tuxedo and Encina. In addition to transaction processing
and load balancing, Oracle Web Application Server 3.0 offers superior
scalability and much better integration with the web: any browser is
supported, all administration is done using the Web, and development
is done using any popular "Internet" language, including Perl, Java, and
C/C++. The following table shows the TP Monitoring capabilities of
Oracle Web Application Server 3.0 compared with traditional TP
Monitors as well as web server offerings from Netscape and Microsoft.
Oracle Netscape Microsoft Tuxedo,Encina,
etc.
Transactions Yes No Yes Yes
Load Balancing Yes No No Yes
Browser-based Yes Yes Yes Some
Administration
Limited (Not
Scalability Strong Weak No distributed)
Ease of Yes Yes Yes No
Development
Requires Java in
Any Browser Yes Yes Yes browser
Scalability
Today, Oracle Web Application Server 3.0 is unique in its ability to
scale up and service very large user populations. Its distributed and
multi-process architecture enables it to outperform any other system
in the high-end transaction management space. Because it supports
database- managed transactions the following characteristics apply:
manage context across multiple browser-server requests
(without the use of Java applets)
route subsequent requests to any application server (cartridge)
instance because transactions are strictly managed in the database
and browser, not the application server.
Today, Microsoft IIS + MTS cannot load balance. They only promise
that they will in the future. Easy to Manage and Administer
Oracle Web Application Server is easy to administer because it has one
browser-based interface for managing all parts of the server. The task
of administering the server remains the same regardless of whether the
server happens to be running on such diverse operating systems as
UNIX or MS Windows NT. Cartridge configuration, access control,
system configuration, and transactions are all managed through the
same HTML based interface. Microsoft on the other hand has distinct
systems for managing DCOM objects in MTS, and files and Active
Server Pages in IIS. Administrators are forced to keep both
environments running and in synch. Easy to program
Oracle Web Application Server 3.0 is much easier to use than
traditional TP Monitors like Tuxedo and Encina. There are no complex
TP Monitor APIs, and a wide range of programming languages are
supported (including C, C++, Java, PL/SQL, Perl, and any DLL with
the ability to be called from C). The Web Request Broker API is
designed using a simple callback-model with additional services
available through standard and well known function calls such as those
belonging to X/Open's TX. TRANSACTION PROCESSING
Oracle Web Application Server 3.0 offers the best Transaction support
over all web servers and TP Monitors available today. The following
table compares the transaction processing capabilities found in Oracle
Web Application Server as well as current offerings from our competitors.
Oracle Netscape Microsoft Tuxedo, Encina,
etc.
URL-based Transaction Context Yes No No No
Web Page-based Transaction Yes No No No
Demarcation
X/Open Transaction Support Tx Yes No No Yes & XA
Only with Java
Browser Managed Transactions Yes No No applet
Features include: -Standard API - X/Open Tx
-Standard Database interface - X/Open XA -Scalability support
-Multiple cartridges may participate within the scope of the same
transaction.
-Transparent delivery of transaction content among browsers and
cartridges.
-Browsers (and their users) may concurrently participate in
multiple transactions.
-The concurrent transactions may each be with different
applications or multiple instantiations of the same application.
Usage/Behavior Oracle Web Application Server 3.0 supports X/Open's TX for
transaction demarcation in addition to its own proprietary API.
--------------------------
WRBReturnCode test_exec( WRBCtx, clientcxp )
--------------------------
void *WRBtx; void *clientcxp; {
/* some code goes here to extract data passed in as part of the URL request */
tx_begin(); /* some code goes here to perform a select and update */
tx_commit();
WRBClientWrite(WRBtx,"cont
you\n", 40); return (WRB_DONE); }
Cartridge developers will primarily use the transaction demarcation
interface to bound the scope of the transaction within their application.
In the simplest form a web page would include calls to both begin and
commit the transaction, limiting the transaction scope to the single
page and a single user interaction.
While limiting the transaction to a single user interaction is desirable
for system performance (because this minimizes the duration locks are
held on resource associated with the transaction), it prevents
application developers from tying several user interactions into a
single atomic transaction in the database. Application developers often
need multiple interactions to be performed within a single transaction
in order to maintain system-wide consistency. In many cases the data
structures associated with these long-running transactions are
minimally shared so bottlenecks are of little concern.
In Oracle Web Application Server 3.0, application developers may
have the transaction scope span multiple interactions simply by placing
the transaction demarcation calls in different web pages.
Oracle Web Application Server 3.0 offers two mechanisms for
associating the intermediary pages with transactions demarcated in
other pages: A simple mechanism where all pages that contain the
same URL prefix will be implicitly associated with the same active
transaction, and a explicit mechanism where each page reference in a
HTML response is annotated with the active transaction.
The first requires the least effort by the developer, but has some
limitations: all the pages to be associated with the transaction must
reside in the same cartridge and have the same URL prefix, and by
corollary all the pages with the same URL prefix will always be
associated with the same active transaction. Additionally the
implementation will prevent a browser from begin two concurrent
transactions with the same application.
The second, explicit form is the more powerful form allowing
developers to use the same web pages in transactions from different
applications, allowing browsers to concurrently run with multiple
transactions in the same web pages. Additionally developers may
designate the same web page to be accessed within the scope of some
transactions, but outside the scope of others. The next figure shows an
example where one can use both transactional and non-transactional
references to the same web page. The application developer will
employ the explicit form by calling tx_annotate_url() with the URL to
be annotated with the active transaction.
The Web Application Server also supports transaction context delivery
in inter-cartridge communication, ICX. Calls made from one cartridge
to another will optionally (developer selected) carry the transaction
context with the call. Access to the resource manager made from the
called cartridge will have the same transaction ID as the calling
cartridge. An example of how this may be used follows: imagine a
server side include page which references a server Java class as well as
a stored procedure in an Oracle7 database. By passing the transaction
ID within the ICX call to each cartridge, both can access the database
as part of the same logical transaction.
An inventory query can be both non-transactional and belong to a
transaction depending on the context and configuration. PL/SQL Cartridge
nstance a URL matching /shop/* could be defined as "belonging to" a
given transaction.
The transaction will be started just before the URL configured with a
transaction-begin is called. The transaction will be ended just after the
URL configured with a transaction-end is called. Browser User
The visible impact of transactions will depend largely on the
applications use of transactions. The following scenarios illustrate how
the implementation of transactions in the WRB will effect users:
Stale Transactions
Web browsers were designed to jump from document to document free
of context. Transactions are innately stateful. The combination can
result in some confusing interactions. For example browsers maintain
a stack of pages visited. Users may easily jump to any of these pages
and invoke calls to other pages referenced. Pages on the stack may
contain a transaction reference that has since finished (stale
transactions). Inconsistent behavior is automatically prevented by the
Web Application Server: attempts to reference stale transactions will
be result in error conditions being signaled. WRB Administrator
There is no transaction state maintained in the 3.0 Web Application
Server. All the state can be bundled in cookies and URL annotation.
Any parameters which need to be passed into XA-compliant resource
managers, can be passed in the open string provided by the application.
RDBMS Administrator
RDBMS administrators will see what appears to be externally
managed transactions passed in through an XA interface. Lock
contention resolution and dead lock detection will be performed as
they would be for any TP monitor. Web Application Server 3.0
inherits some aspects of its architecture from modern open TP monitors.
Transaction Cookies
Whenever a transaction is begun, a cookie will be created for return
with the requested HTML page. The cookie will be associated with the
URL prefix of the current page and contain the XID of the created transaction.
URL Annotation
The URL annotation is the same used for other context which needs to
be interpreted by the Web Request Broker dispatcher. A single routine
for all context annotation can be employed, tx_annotate_url().
All URL references in an HTML document need to be processed for
annotation. The burden is placed on the developer to remember to
annotate URLs. URL annotation could be selected over cookie-based
annotation because browsers would be free to start multiple concurrent
transactions with the same application. Also, not all browsers may
support cookies. Long-Running Transactions Across Multiple Requests
The Web Application Server allows application designers to
incorporate multiple web browser/server interactions within the scope
of a single transaction. This is accomplished with a mechanism where
a transaction context is bound to URLs before passing them back to the
browser. Callouts
Web Application Servers may call each other passing the user context
transparently. For example an application may be written by two
different organizations or written in two different programming
languages. They may be executing in two different Web Application
Server cartridges. If an application in one cartridge calls an application
running in another cartridge, the Web Application Server will pass any
transaction information. This ensures that all database updates
performed as part of the same transaction, but from distinct cartridges,
will be all committed or aborted as one. Since transaction context is
maintained in the database, any number of cartridges can participate in
the same transaction. +==+References:
4. Soln# 2082026.6 WHITE PAPER - SECURITY, CONCLUSION
Solution ID : 2082026.6For Problem : 1034841.6
Affected Platforms : Generic: not platform specific
Affected Products : Oracle Web Application Server
Affected Components : WEBSERVER GenericAffected Oracle Vsn : GenericSummary:
WHITE PAPER - SECURITY, CONCLUSION+=+ SECURITY
Oracle Web Application Server offers a unique extensible
authentication system as an integral part of the Web Request Broker.
An authentication broker delivers authentication requests to one or
more authentication server objects, which provide authentication
services for any cartridge on the system. In addition to the standard
"Basic and Digest" authentication, IP and domain filtering known
from standard HTTP servers, a new type of authentication known as
"Basic Oracle Authentication" is provided in Web Application Server
3.0. To the end-user this looks and behaves just like standard Basic
Authentication, but the username and password entered in the browser
is validated against existing Oracle usernames and password. This
eliminates the need for the Web Administrator to maintain two
separate user databases for applications that connect to a database, and
also supports distributed web sites seamlessly.
Oracle Netscape Microsoft Tuxedo, Encina,
etc.
Single Login Yes No Yes No
X.509 Certificate Yes Yes Yes No
Support
Database Integrated Yes No Yes No
Migrating Applications
Can my existing Oracle mission-critical applications be migrated to
the Web Application Server platform? The answer is obviously
somewhat dependent on the specifics of the application in question, but
the following types of applications require very little modification:
-Any applications developed using Oracle Developer/2000 tools
can be migrated with no modifications at all by using the new
WebForms, WebReports, and Webgraphics cartridges scheduled
for release in Q2 1997.
-Any applications developed using Oracle7 stored procedures are
easily web-enabled using the PL/SQL cartridge. The
user-interface will most likely require some reprogramming
either in PL/SQL or Java.
-Any application developed in any 3GL language may be
migrated by converting it into a cartridge. This process is quiet
simple, and the only real effort goes into re-designing the
user-interface to generate HTML tags for standard web browsers.
-Any application written in Perl may be deployed using the Perl
cartridge, eliminating the overhead of constantly launching the
Perl engine through CGI.
-Any application written in Java may be deployed using the Java
cartridge in a similar fashion.
In addition to supporting these new classes of web applications, your
existing client server will continue to work using direct database
connectivity. Contrasting to this, Microsoft is offering a very limited
set of options for application development: only DCOM object DLLs
can be managed by the Microsoft Transaction Manager, and only static
HTML pages and Active-X Server Pages can be managed by
Microsoft IS-Server. Migrating your existing mission critical
applications is not an option unless they happen to be written as DLLs
for Windows NT. Use of Open Standards
Oracle's objective is to create excellent products based upon industry
standards. Oracle Web Application Server 3.0 is no exception: HTML,
HTTP, Java, Server Side Includes, X/Open TX & XA, X.509 & LDAP,
CORBA, and SQL.. Microsoft currently only supports DCOM and XA
in the Microsoft Transaction Manager, and HTTP, HTML, and Visual
Basic in the IS-Server. Broad Platform support
Oracle Web Application Server 3.0 runs on many platforms, including
but not limited to Sun Solaris (SPARC & Intel), HP HPUX, SGI IRIX,
IBM AIX, DEC OSF/1, DG Aviion, SCO UNIX, and Windows NT.
By comparison Microsoft's Transaction Manager and IIS run on only one.
Legacy System integration
Oracle's comprehensive suite of solutions including Web Application
Server, Oracle. Universal Server and gateway integration products
give application servers unprecedented interoperability with legacy systems:
-Direct access to heterogeneous data sources.
-Ability to link any database client library into application server,
and use data sources native APIs.
-XA support for transactions on all popular RDBMS systems
(including Oracle, DB/2, Informix, Microsoft).
-Direct access to stored procedures on all leading RDBMSs.
-Transparent Indirect access to heterogeneous data sources via
-Oracle transparent gateway products.
-Ability to access all RDBMS systems, all leading mainframe
data sources with a consistent API and database synonyms.
-Transactional consistency with two-phase commitment managed
by the reliable DB server.
-Indirect access to legacy applications through Oracle's
procedural gateway.
-Oracle Web Application Server cartridges can call legacy
applications running on mainframe CICS systems via the
procedural gateway.
-Transactional consistency with two-phase commitment managed
by the reliable DB server.
Providing the Best Transaction Scalability in the Industry Oracle Web
Application Server currently offers the best transaction scalability in
the Web industry. This claim is based on two fundamental features:
first, the architecture is designed around a stateless application server,
and second, the use of dynamic database connections that are shared
between multiple cartridges in one atomic database transaction.
The unique scaling ability of Oracle Web Application Server are
illustrated in this diagram. For a number of reasons the original
cartridge instance used by browser B may not be available when it
returns to continue its transaction. However, since the transaction
context is maintained in the database, it is possible to connect to a
different cartridge instance and re-attach to the on-going transaction.
This behavior is essential for scalability because:
1.application server instances do not maintain any transaction state
2.the transaction support preserves user context from request to request
3.the transactions can migrate from application server instance to
instance 4.application instances can run on one or multiple machines
It also allows any application cartridge instance to service any request
without loss of context between browser and database. Note that this
example uses two instances of the same cartridge, but there is nothing
limiting you to this - it is used here for clarification purposes only. In
fact, the same database transaction may be used by different instances
of different cartridges.
The Microsoft IIS and MTS combination suffers from a series of
problems when it comes to scalable transactions:
1.There is no apparently easy way to support transactions across
multiple interactions between a browser and a database.
2.ODBC connections are tied to a transaction, and therefore cannot
be shared for use by more than one active transaction.
3.No way to automatically free component instances, ODBC
connections, and database resources if browsers (or their users)
don't finish what they start. This spells disaster on the Internet.
Furthermore, applications need to manage their own state from
call-to-call from the browser. This means MTS must run a component
instance for each active transaction for every browser. Microsoft's
component instances are dedicated for each and every browser. This
adds complexity for application developers and prevents IIS and MTS
from supporting scalable transactions, or any form of context across
multiple browser-DB interactions.
Note that in the case where developers which to access MTS from an
Active-X control on the client, modifications are required to the
client's registry in order for MTS to work. Did we mention that only
DCOM clients = MS Windows are supported? Manageability
Oracle Web Application Server 3.0 controls where each application
server instance runs, and how many to run at each node. This is
important to prevent high demands for less important applications
from swamping systems which should be giving higher priority to
perhaps lower demanded but more important applications. We put you
in full control of your site's available resources. Microsoft only
promises to do this someday. Conclusion
In this paper we have attempted to describe some of the truly unique
features of Oracle Web Application Server 3.0. A lot of thought and
careful planning has gone into designing the architecture to guarantee
maximum scalability, extensibility, and openness. We have revealed
some of the serious short-comings of Microsoft's MTS and IIS
strategy, which quite honestly shows surprising signs of immaturity
and relegates Microsoft to the realm of non-critical web scripting.
The Web Request Broker is a key component of the Oracle Web
Application Server, and by implementing it using modern CORBA
technology we are enabling a whole new class of transactional
super-servers that do not require customized network stacks and
slimmed down operating systems. They will run on standard hardware
glued together with the Web Request Broker bringing unprecedented
processing power to your web applications. We are busy realizing
Oracle's vision of the Network Computing Architecture, and taking
our customers to a whole new level of distributed mission- critical
computing on the Internet and Intranets. Summary Comparison
Oracle Netscape Microsoft Tuxedo, Encina,
etc.
Transactions Yes No Yes Yes
Load Balancing Yes No Yes
Browser-based Administration Yes Yes Yes Some
Scalability Strong Weak No Limited
Ease of Development Yes Yes Yes No
Requires Java in
Any Browser Yes Yes Yes browser
URL-based Transaction Yes No No No
Context
Web Page-based Transaction Yes No No No
Demarcation
X/Open Transaction Support Yes No No Yes
Tx & XA
Only with Java
Browser Managed Transactions Yes No No applet
Single Login Yes No Yes No
X.509 Certificate Support Yes Yes Yes No
Database Integrated Yes No Yes No
+==+References:5. Soln# 2082020.6 WHITE PAPER - INTRODUCTION
Solution ID : 2082020.6For Problem : 1034841.6
Affected Platforms : Generic: not platform specific
Affected Products : Oracle Web Application Server
Affected Components : WEBSERVER GenericAffected Oracle Vsn : GenericSummary:
WHITE PAPER+=+Solution Description: ===================== March 1997
DEFINING A TRANSACTION MODEL FOR THE WEB
This document provides a technical overview of current web server
products available from Oracle Corporation with emphasis on the
transactional application platform available in Oracle Web
Application Server 3.0. We will start by giving you the big picture and
later emphasize what the key differences are between our product and
alternative choices out there, in particular the Microsoft IIS and MTS
combination. This note focuses on product features that have been
shipping for almost a year as well as new technology that we are
introducing in Oracle Web Application Server 3.0. It is perhaps this
release that is most interesting, since it is at the time of writing still
unique in the industry. Oracle Web Application Server 3.0 offers the
most scalable, manageable and portable transactional web server in the
entire industry. SCOPE
The scope of this document is to provide a technological overview of
the Web Application Server and accompanying application server
cartridges for the Oracle WebServer and Web Application Server 3.0.
Several aspects, such as system management utilities and user
interfaces are not covered in this paper. ORACLE WEBSERVER 2.1
This first section describes release 2.1 because it is useful to
understand how our core technology has evolved into the current
product offerings. HTTP Protocol Servers
Before discussing our platform for Web applications, we will spend a
moment on HTTP servers. Today, they have essentially become free
commodities. Because of this, Oracle has chosen to bundle the
Spyglass HTTP server and distribute it freely as part of our WebServer
product. We believe that a HTTP protocol server is a simple network
protocol server similar to an FTP or TELNET daemon, and that it has
fundamentally different characteristics and requirements for optimal
software design than application servers. Many major web server
companies have acknowledged that the single- process
asynchronous-request architecture employed by Spyglass is superior
for handling very high loads and throughput. But frankly, we do not
believe this is crucial to the application server platform, since a
broader audience is more interested in utilizing different HTTP servers
for specific tasks in a heterogeneous web server environment.
Therefore, our product supports all leading commercial HTTP servers
available today.
Current benchmarks (e.g. WebStone) are used to measure the raw
speed in delivering static HTML documents, but by choosing one
specific web server (and the implicit dependency on its proprietary
API) based on raw static page delivery performance, more important
features of a web-based application platform such as database
transactions are overlooked. Our architecture allows us to abstract the
application from the underlying HTTP protocol server, which in turns
enables us to support multiple flavors of HTTP protocol servers (e.g.
Netscape, Microsoft, etc.).
Therefore, starting with Oracle WebServer 2.1 introduced in late 1996
and continuing with Oracle Web Application Server 3.0, we can offer
the only commercial web application platform that runs on top of
HTTP protocol servers from multiple vendors. This by itself is an
important advantage: ISVs and partners can rest assured that Oracle
will continue to enable the same level of portability for Web
applications that our RDBMS has made us famous for. Application Servers
This is where we start to differentiate ourselves. Today, with the
exception of Oracle WebServer, you have two basic (architectural)
choices for developing an application: you can either use CGI, or you
can implement your application as a linked-in extension to the HTTP
protocol server using a proprietary API. For large systems, CGI is out
of the question because the overhead of spawning new application
processes for each request becomes too high under high load. Linking
everything into the HTTP protocol server is a very bad idea, because it
creates an inherently unstable system: a bug anywhere will crash the
entire server, certainly not our idea of a fault-tolerant system. Note
that this is a known problem with the current architecture of platforms
like Netscape's LiveWire and Microsoft's FrontPage/Denali/Active Pages.
The answer to this dilemma is quite simple: process isolation. Each
application runs in a separate persistent process instance and a
dispatch-mechanism from the HTTP protocol server provides the
basic glue or plumbing for this process model. In May 1996 we
introduced the "plumbing" to make this easy to deal with: the Web
Request Broker. Oracle WebServer 2.1's reliable process isolation model
Oracle was first in the industry to introduce this architecture, and the
Web Request Broker was subsequently awarded "Coolest Product of
the Year" at InterOp96. The fact that our competitors are attempting to
copy our architecture in future releases is seen as a strong endorsement
of its superior design. Web Request Broker
Our first generation WebServer is currently widely deployed in our
customer base on corporate Intranets. At the time of writing Oracle
WebServer 2.1 is our latest production release, and is freely
downloadable from www.oracle.com. When it comes to real enterprise
class web applications (as opposed to simply serving static pages)
release 2.1 outperforms all other web servers in the market today, and
this becomes increasingly apparent under heavy load and high
throughput. An example of a commercial site where Oracle Web
Server was put to test was the on-line registration to a very large
tradeshow in 1996. This site was performing 25,000 web transactions
per hour, which is quite a lot for an application server.
We have published a "HTTP protocol server independent" API to the
Web Application Server which allows ISVs, partners and customers to
build their own application "cartridges". We currently have 70 ISVs
building application cartridges, and this number is expected to grow.
The main benefit for our partners is that we can offer them a unifying
API that is the same across both HTTP protocol server versions and
operating systems. Nobody else does that today. +==+References:
6. Soln# 2082023.6 WHITE PAPER - CARTRIDGESSolution ID : 2082023.6
For Problem : 1034841.6
Affected Platforms : Generic: not platform specific
Affected Products : Oracle Web Application Server
Affected Components : WEBSERVER GenericAffected Oracle Vsn : GenericSummary:
WHITE PAPER - CARTRIDGES+=+Application Cartridges
Oracle WebServer ships with a set of application cartridges that are
unique in the industry. PL/SQL
First, the PL/SQL cartridge enables web applications to be
implemented as stored procedures using a unique mechanism. This
cartridge is very popular because it enables our customers to leverage
existing investments in Oracle7, while providing superior security,
management, and portability over any other language. The PL/SQL
cartridge also offers superior network performance by running the
applications as stored procedures in the database kernel, eliminating
the cost of transmitting raw data between the database and the
application processing the data over the network. Java
Second, JavaSoft's Java VM is implemented as a cartridge enabling
customers to develop completely open, database independent OO
applications. In order to access a database from within a Java
application, developers can choose between JDBC and Oracle
developed auto-generated Java wrapper-classes providing access to
stored database procedures. Note that although other vendors claim to
support Java in their web servers, nobody can offer the same robust and
high-speed implementation as Oracle's cartridge implementation. LiveHTML
Third, a standard server-side include parser is implemented as an
application cartridge. This offloads the HTTP protocol engine (where
our competitors do their parsing) allowing it to concentrate on
maximum throughput. The biggest benefit of this implementation,
which we will detail in the next section, is that it allows us to evolve
server-side include parsing into something much more powerful with
scripting and custom extensibility. ORACLE WEB APPLICATION SERVER 3.0
This section details what we are introducing in Oracle Web
Application Server release 3.0. This release is had final beta testing,
with over 5,000 pre-registered beta-sites world-wide. This is the largest
beta program every initiated by Oracle Corporation. The full production
release is, as of August 1997, available on Solaris. Goals
Our goals with release 3.0 are to provide an improved software
architecture that will allow our customers to build and deploy a whole
new class of web-sites supporting extremely high connection rates,
and also provide a runtime environment that will allow applications to
be truly transactional across multiple HTTP requests, thus providing
the industry's first transaction model for the web. The first
performance and scalability goal is addressed by an improved software
architecture, and the second transactional goal is addressed by adding
new services to the Web Application Server. Both are detailed in the
following. The major enhancements in release 3.0 are found in the internal
"plumbing" of the Web Application Server. In release 2.1 and earlier,
the HTTP protocol server, Web Request Broker, and cartridges were
constrained to reside on the same physical computer. In release 3.0, the
guts of the Web Application Server revolve around a CORBA
compliant ORB. The HTTP protocol server, cartridges, and all system
services are implemented as distributed objects. This allows us to
address bottle-necks effectively and cost-efficiently.
One of the main constraints of a web-site is the incoming network
bandwidth. Since HTTP protocol servers are distributed objects, they
can be installed on multiple low-end computers with high-end
network interfaces. Receiving requests and dispatching them does not
require significant CPU power. Release 3.0 supports configurations
with any number of front-end HTTP protocol servers that share the
same back-end ORB and cartridges. Not only that, but different HTTP
protocol servers may be mixed freely, e.g. a combination of Netscape,
Microsoft, and Spyglass servers can cooperate to provide maximum
compatibility for browsers. Nobody else can do this. We expect this to
become increasingly important as new protocol servers are added, such
as IIOP and other Internet protocols, and also as Microsoft and
Netscape continue to diverge HTTP, HTML, PEP, PICS, etc.
implementations. Unlike the current offerings from all commercial
web server vendors, release 3.0 of Oracle Web Application Server does
not force you to replicate the entire node to increase network
bandwidth. This represents enormous cost savings.
A completely different type of bottle-neck occurs when the web server
host runs out of processing cycles, and system load increases to an
unbearable level. This problem is addressed by investing in more
powerful hardware, or, since cartridges by nature are distributed, by
adding additional nodes on which application cartridges may be
deployed. Again, the distributed architecture of release 3.0 allows us to
address this bottle-neck in a cost-efficient manner. We can build
cartridge-farms, and nodes that are specialized to host a specific
cartridge type. Nobody else can do this today.