Trial Balloon: A new DataStore Architecture?

Jonathan Blandford jrb@redhat.com
31 Oct 2000 15:27:59 -0500


<delurk>

Hi Derek,

While I'm hardly a CORBA expert, I'd like to reply to some of these
comments.

Derek Atkins <warlord@MIT.EDU> writes:

> Rob Browning <rlb@cs.utexas.edu> writes:
> 
> > On the data communication side, there's also CORBA to consider.
> 
> I personally dislike CORBA.  My reasoning is two-fold:
> 
> 	1) Synchronous RPC is BAD (in many cases).
> 
> 	2) CORBA tries to push protocol design onto programmers.. But
>            good programmers are not necessarily good protocol
>            designers (and vice-versa).
> 
> A real-world example of this: M$ Outlook requires 84 RPC calls to open
> a mail folder.  If your mail server is a few hundred miles away, it
> can take, literally, several SECONDS in order to open it.  Why?  The
> program has to pause and wait for each RPC to finish before it can
> make the next request, and the transmission delay time can be
> relatively large in a widely-distributed network.

84 RPC calls?  That's pretty heavy, regardless of the protocol or
mechanism.  But that aside, CORBA has the oneway directive that lets you
send asynchronous requests.

> A real protcol would let you send multiple requests consecutively and
> let the responses come asynchronously.  Unfortunately CORBA does not
> let you do this.

Yes it can.  You can send multiple oneway requests, and let the remote
object send oneway replies back.

> Another potential problem is the security of CORBA.. Namely, there is
> none.:) I would personally insist on data encryption and strong
> (kerberos-level or greater) user authentication.

I'd argue that writing my own protocol is less secure, as there's more
complexity in the code, more room for error, it's one more dependency on
the system etc. etc.  At least with ORBit, there are a number of other
people using it.  Additionally, ORBit 2.0 has support for SSL built in.
Authentication is a separate kettle of fish, and needs addressing
independent of the protocol used.

> Frankly, I don't think that designing a real protocol would be
> difficult.  I also don't think it needs to happen right away.  I think
> we can architect and implement the data model using local storage
> before designing the network protocol.  At least a set of access
> requirements should come first.

Thanks,
-Jonathan

</delurk>