CORBAweb - A CORBA Gateway for the web

This paper describes a CORBA back end for a web server. CORBA is used to wrap legacy information systems and build a secure, reliable gateway between them and the web server.

Architecture diagram goes here

CORBAweb is a plug-in replacement for the popular CGI protocol. The browser can invoke it using HTML forms exactly as it would for a CGI application.

The HTTP server is configured to pass requests for certain resources to the CORBA client which runs as a module within the server. For example, the following URL will cause the client to look up and bind to the service called "teller" within the "customers" context of the name server: http://www.someBank.com/orb/customers/teller

The client then invokes the gateway's invoke() operation, passing it the url-encoded data received from the browser. The interaction between the CORBA client and gateway closely approximates that described in the CORBA Dynamic Invocation and Dynamic Skeleton specifications. This is because the client cannot know a priori what services it will be invoking and the gateways consist of the same generic (inherited) code to simplify the task of gateway construction.

Once the gateway has decoded the input, it invokes the object wrapper which implements the service (e.g. drives the database to access the customer's account). The decoded data may well contain a tag or "cookie" to identify the client who originated the request. Finally the gateway renders the output of the object wrapper as HTML and returns it to the CORBA client which passes it back to the browser.

Note that the object wrapper actually delivers the service, while the gateway deals with data presentation issues: it decodes the input and renders the output as HTML. Alternatively, we can use server-side includes to embed ORB invocations into an HTML document. We have found this separation of service and presentation logic a useful programming abstraction.

This architecture has several advantages over the CGI approach.The performance is better because it is not necessary to spawn a separate process for each invocation.The gateways can be either stateful or stateless - CGI forces the gateway to be stateless since a new process is started for each invocation.

To overcome the disadvantages of CGI many commercial web servers rely on dynamic loading to load a gateway module which then shares a process with the main web server. This is harder to debug than our approach: a bug in the gateway can cause the main web server to crash. It also does not scale as well as our approach: a new module must be loaded into the web sever for each new gateway. In contrast we have complete separation between the gateway and web server. Installing a new gateway is simply a matter of starting it from the command line; it will register itself in the name server and thus become visible to the CORBA client and hence the web server.


Nigel Edwards (nje@hplb.hpl.hp.com) Hewlett-Packard Laboratories, Bristol