[omniORB] CORBA benefits over EJB model

[Richard Gruet]

This is a multi-part message in MIME format.
--------------0018E55DB523AB35ABBF048A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Eliot,

I agree with you. I had a similar experience using Python (and OmniORB) for
implementing Corba servers in several projects, and it proved to be both reliable
and easy to code (at least far easier than C++). Corba is definetely not related to
any particular language as the different existing langage mappings suggest.
Now I'm involved in a project in an all-in-Java company than plans to use EJBs,
although the decision is not made yet. And this thread is interesting to me since
I'm wondering about the pros and cons of EJBs.

To me,  Corba is more a set of pieces that you have to assembly whereas EJB is an
integrated solution. It is a known pattern: the former is harder to learn and use
but provides more flexibility if you need customization or in case of error; OTHOD
the latter lets you quickly build servers with transaction aware DB accesses
(although configuration can be tricky) but, precisely because it handles a lot of
things for you, it will make customisation and error search more difficult.

Richard

"W. Eliot Kimber" wrote:

> Zed Shaw wrote:
>
> > 2)  (I'm going to get in trouble for this one :-).  C++ requires "Guru"
> > status just to code simple CORBA servers.  EJB requires "coding moron" status
> > even for advanced stuff.
>
> The use of CORBA does not require C++. We have written a sophisticated
> CORBA-distributed app entirely in Python. The only C code we've written
> for this project is patches to our 3rd-party dependencies (and small
> ones at that). I am anything but a CORBA guru and I can go from abstract
> object design to running servants and clients in a matter of an hour or
> two (e.g., tasks where I am writing classes that expose existing
> functionality in our underlying domain objects, so that most of the work
> is defining the IDL and writing the servants, not implementing business
> logic). We have no C++ gurus on our team.
>
> One of the problems I've run into in talking to people about using CORBA
> is the misconception that CORBA == C++, which it most certainly does
> not.
>
> We've found that, especially using the Python CORBA framework stuff we
> developed (and have posted on the OmniORB site), that developing CORBA
> apps in Python is about as easy as it could be.
>
> While Python is not necessarily appropriate for all distributed
> applications, we have found it has allowed us to develop the first
> iteration of a working distributed system very quickly. Now we can
> iteratively re-implement components in C++ or Java as we need to to get
> the performance and security characteristics we need. But we have found
> that for relatively small scales (1-200 concurrent users) that our
> Python-based system is entirely acceptable (and we haven't yet squeezed
> out all the performance we can out of our Python code nor do we
> currently have the testing resources to determine the upper limit of our
> current scalability). Our system now has client components implemented
> in Python, VB (using Python as the COM-to-CORBA bridge), and Java using
> several different ORBs. DataChannel is primarily a Java shop, so we
> haven't had a requirement to do any direct C++ development of clients or
> servers.
>
> Cheers,
>
> Eliot
> --
> . . . . . . . . . . . . . . . . . . . . . . . .
>
> W. Eliot Kimber | Lead Brain
>
> 1016 La Posada Dr. | Suite 240 | Austin TX  78752
>     T 512.656.4139 |  F 512.419.1860 | eliot@isogen.com
>
> w w w . d a t a c h a n n e l . c o m

--------------0018E55DB523AB35ABBF048A
Content-Type: text/x-vcard; charset=us-ascii;
 name="rgruet.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Richard Gruet
Content-Disposition: attachment;
 filename="rgruet.vcf"

begin:vcard 
n:Gruet;Richard
tel;work:925 253 6512
x-mozilla-html:TRUE
org:<a href="http://www.intraware.com/index.html"><img src="http://www.intraware.com/images/tempgifs/logotype.gif" border="0" width="165" height="30" </a>;IT Architecture
adr:;;;;;;
version:2.1
email;internet:rgruet@intraware.com
title:Sr Application Architect
fn:Richard Gruet
end:vcard

--------------0018E55DB523AB35ABBF048A--