Page 405
the most pivotal because the listeners and cartridges broker their messages through WRB. A cartridge, to use a simple definition, is an extension of the Web Application Server that is typically developed by third-party vendors or as part of an in-house development effort.
WRB incorporates a multithreaded and multiprocess architecture, resulting in increases in machine productivity as more requests can be processed almost simultaneously. The WRB also supports asynchronous independent processing, so client and server resources aren't forced unnecessarily to wait for result sets or other messages to be returned.
Here's how WRB works: You're on the Web and want to access a site that uses Oracle Web Server. At this site is a form that allows you to request data. You fill in the information and click the Submit button. Your browser sends the request to Web Listener, which then sends the request to the Dispatcher. The Dispatcher determines the proper cartridge to handle the request and then summons WRB to invoke a service within the cartridge.
WRB actually allocates an execution instancealso known as WRBXof the cartridge. That is, WRB sends requests to the appropriate server extension for specialized processing in separate processes. Web Request Broker, as its name implies, brokers client requests by routing them to the appropriate database server, Web server, and application programming interface libraries. When returning the information you requested, the process is repeated in reverse.
NOTE |
Interobject message communications follow the Common Object Request Broker Architecture (CORBA). In a nutshell, systems that follow the CORBA model have objects that can carry out the role of client, agent, or server, each of which help pass messages from an end user's machine to some local or remote server. |
Object orientation requires messaging between objects, and WRB is no exception. An end user message results every time users click inside a Web browser. A Web browser can process some of these messages, including your requests for locally stored documents and browser preferences; WRB handles the other messages. The browser then checks to see whether it can process the message. Because it can't, it sends the message on to WRB. WRB brokers the messagedetermines which object should process itand sends the message to the appropriate object.
NOTE |
Oracle is incorporating a possible open-platform future for WRB where messaging mechanisms won't be exclusive to Oracle products. Oracle Web Application Server 3.0 will support the Internet Server systems of Microsoft and Netscape. Given that Oracle is on more cozy relations with Netscape than with Microsoft, you might see stronger support of the Netscape implementation. |
True object orientation for any system requires that objects be reusable and scalable. WRB has a software development kit that lets developers create customized plug-ins. Java developers can
Page 406
also create applets and applications that Oracle Web Application Server can interpret. For instance, if you created a Java applet that then was downloaded to a client browser, it can pass database requests to WRB. WRB then executes PL/SQL commands on the database server. C developers will find Oracle Web Server's support for server-side includes (SSIs) familiar. Oracle database developers can incorporate a PL/SQL agent for requesting data from an Oracle database engine.
Now examine WRB messaging from an architectural point of view. WRB dispatches requests to server extensions running in separate processes. The Internet messaging protocol is provided by the Hypertext Transport Protocol (HTTP), with its encryption and security mechanisms. Oracle's implementation of HTTP provides a low-level, asynchronous channel at the network level between the client and the server. This connection is short-term as a result, and there can be several connections as HTTP is multithreaded.
During this connection, the client is requesting a service or file object from the HTTP server. The server then returns the requested object if it finds it; otherwise, it sends the message on to WRB or returns an error message. On receiving this object, the client checks its MIME type attribute value for further processing. Based on this value, the client may process this object for use by the user, or invoke a helper application orin the case of a Web browsera network loadable object or plug-in to prepare the incoming object for your use.
From this description, you should have a pretty good idea of the life cycle of a typical message traveling through HTTP. The life cycle of such a message is also loosely called a transaction. Oracle Web Application Server uses Web Listener as the HTTP message handler.
You've just digested quite a bit of information; now it's time to delve a little deeper. After Web Listener sends a message to WRB, WRB's dispatcher determines the type of object the client requested. In detail, this dispatcher looks into the WRB configuration file, which helps the dispatcher determine the relationship between virtual directories and WRB services. If the dispatcher finds no relationship to suit the client's request, it returns the request back to Web Listener, which continues the message life cycle.
Quite naturally, with WRB's architecture you can distribute processing loads between service object instances dynamically. This helps minimize network contention and optimize Oracle Web Application Server performance. As administrator of Oracle Web Server, you have to keep an eye out for potential resource drains and performance degradation when using multiple service instances (or processes, for UNIX techies). You can specify minimum and maximum numbers of instances of each service WRB provides.
In a nutshell, each service object has an interface that provides essential methods (functions) to deliver a "product" to the client. In object-oriented terms, this acceptance of service responsibility and the resulting delivery of the service is called a binding contract. Further, as some client/server experts have noted, "the location of the object should be transparent to the client and object implementation."
Page 407
In this situation, WRB is loosely defined along the ORB (Object Request Broker) model. As with CORBA, the main idea behind ORB is that an object, acting as an agent on the behalf of some client object, handles the requesting of remote services. The WRB, then, provides clients the ability to invoke object methods on service objects transparently across a network or on your machine. This means that you don't need to concern yourself with the physical location or operating system platform of the objects providing the services you need. This lends itself to data hiding or encapsulation.
The transport-independent WRB protocol handles all interprocess communications (IPC). Oracle Web Application Server supports standard IPC mechanisms. IPC is the heart and soul of client/server architecture for UNIX platforms. However, IPC isn't the easiest client/server tool suite to use, especially when it comes to developing multitiered, multiprocess applications. My hunch is that Oracle provided this support because of its heavy background in UNIX-based platforms.
Oracle Web Application Server 3.0 supports other mechanisms in addition to IPC, such as OMX, Oracle's CORBA-compliant Object Request Broker. The idea here is that WRB Services may be implemented together as industry-standard distributed objects, thus enabling distribution and scalability across multiple nodes.
WRB has an Execution Engine object (WRBX), with a shared library, to provide a low-level development interface to execute WRB services. Each WRB service responds to demands from WRBX. The shared library is dynamically loaded at runtime. Oracle motivation behind this open API approach is to encourage customers and solution providers to integrate their own extensions. The Execution Engine object provides better integration at a much more encapsulated level than the relatively low-level, cumbersome approaches of CGI or various HTTP server APIs.
You can use the WRB API to register three essential callback functions with the WRBX Execution Engine object:
These methods taken together follow the typical class structure in which you can initialize objects, send and receive messages when the object is initialized, and destroy objects when you're finished using them. This structure lends itself quite easily to the object-oriented approach to system development.