An idea: Apache Object Adaptor

[dthompson characterlink net (Darrin Thompson)]

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