An idea: Apache Object Adaptor

[dthompson characterlink net (Darrin Thompson)]

Sincerest apaologies if you receive this twice. I think I posted to an 
old list address the first time.

I had an idea this weekend that I thought I would run by this list. I
hope that this prompts at least a little discussion.

Problem:

Most of the difficulties I have had with ORBit usually have to do with
scalability on the server side. As soon as I think over an implementation
of some big server side app, I run into the fact that I can't have
multiple threads.

Any serious CORBA or Bonobo server side app is going to have to be
implmented as yet another server side daemon.

Solution:

Add another transport, HTTP-IOP, and a new series of object adaptors,
beginning with Apache Object Adaptor.

Suppose I wanted to write a groupware server for evolution. I want it
scalable to a very large number of users, etc.

On the client side, Evolution works normally, assuming that ORBit has
HTTP-IOP.

On ther server side I build my app using some of Apache's apis (CGI,
modules, mix n' match) and the Apache Object Adaptor.

For instance, a request comes in from Evolution over HTTP-IOP. Apache
recieves it and eventually the object adaptor gets a crack that reading
it. After decoding which object should receive the request, the object
adaptor invokes an apropriate method using an number of methods.

The object might be implemented as a CGI script. The object adaptor could
send the method and parameters using the "normal" cgi methods. The
response would be returned in headers and the body of the HTTP response.
XML? SOAP! :-)

The object might be implmented in a native apache module. Each module
would instantiate it's own object adaptor and decline to handle requests
it does not understand.

How would the CGI adaptor map methods and interfaces to individual CGI's?
Those details would be handled by setting policies in the object adaptor.
Of course the ORB could have a number of object adaptors with different
policies.

Some objects would need to maintain state between calls. The object
adaptor could present an api for storing state in a general way.
Depending on policies, some adaptors might store state in shared memory,
others in a more persistent way, such as in a file or in an RDMS. (How
would a CGI access this API? Beats me. I'm kind of dreaming here.) :-)

I think this idea challenges some of ORBit's design decisions. The main
question I ask is, is the POA enough? For all it's wonders, the POA makes
it difficult for a non theaded ORB to handle a lot of incoming traffic.
An object adaptor based on routing requests within a well established app
server, Apache, seems to be a sensible solution.

Advantages:

The potential scalability of this approach is limited only by Apache 1.3.

Application writers don't have to implement yet another server daemon.
Apache is already very stable and fast.

This seems to be a "good fit" for an application writer seeking to
develop with Bonobo. (i.e. Scalable Groupware for Evolution)

An app writer could hack out code as a bunch of Perl cgi's (or your
favorite scripting langauge) quickly and then start optimizing individual
parts of the app. Perhaps a mod_perl enabled Apache would make it
possible to develop some big apps and never leave CGI/Perl.

Disadvantages:

The application is likely to be dependent on a particular object adaptor,
and the advantages of using the portable object adaptor are lost.

Maintaining state across Apache processes introduces some complexity.

Summary:

I think an HTTP transport and an object adaptor that adapts CORBA
requests to Apache's API is a sensible foundation for developing larger
CORBA and Bonobo Apps.

Thanks all for your time and any comments.

Darrin