[omniORB] CORBA benefits over EJB model
Ben Miller
Ben.Miller@Mercia.Com
Thu, 7 Jun 2001 10:54:49 +0100
Great input, thanks Zed.
However, I'd just like to comment on a point regarding the use of
CORBA and EJB together. As you mentioned, this would make our system
an installation nightmare. And also a maintenance nightmare, of
course - if something goes wrong at a customer site, there are SO many
possible points of failure! ;) We're new to the middle-tier
quagmire, so I'd rather go EJB or CORBA to ease the complexity.
(After all, we could code a lot of the CORBA objects in Java where we
don't care so much about the performance.)
The real sticking point my team has are the time-to-market factor,
which is percieved as far greater for CORBA based system. It does
seem to me that we'd probably end up coding more of our own services
if we went with CORBA. Perhaps I'm wrong?
Which reminds me....
I've also got the problem of how to manage database connection pooling
and transactions. This would all be pretty much handled by an EJB
serer vendor, but what if a need database connections in my CORBA
object bolted on the side? I'm just not sure whether you can create a
connection pool that provides connections to multiple-language
servers...
Best regards,
___________________
Ben Miller.
Technical Architect
-----Original Message-----
From: Zed Shaw [mailto:zedshaw@killnine.net]
Sent: 8 June 2001 00:43
To: Ben Miller
Cc: omniorb-list@uk.research.att.com
Subject: Re: [omniORB] CORBA benefits over EJB model
Ben,
Here's what I see as the primary advantages of CORBA over EJB:
1) CORBA works with more than just Java. EJB can use IIOP, but while
I can
get an EJB client to talk to a CORBA server, I can't get a CORBA
client to
talk to an EJB server. At least, I've never done it (and dammit I
tried real
hard).
2) EJB containers are typically much slower than custom CORBA
servers, and
you still end up using all the distributed programming tricks you
learned
from CORBA when you write EJBs. The big myth of EJB programming is
that you
don't have to worry about scalability issues since the container does
it for
you. The truth is that you still do because most containers blow.
3) EJB isn't quite as flexible as CORBA (see my EJB advantages later
for the
downside to this). With CORBA you can code just about any type of
servant
object you want, with EJB you are limited to whatever the container
supports,
and only a few models with EJB itself (although, these are pretty
flexible in
their own right).
4) EJB containers are still fairly new, and you could easily get
locked into
something that evaporates a few years later. Many of your CORBA ORBs
that
are available have been around for a long time and have a better track
record.
5) Finally, there are more services available with CORBA 3.0, and
they are
well defined. This is a debatable one though, since most vendors
can't seem
to get these right.
Now, EJB I've found, has the following advantages:
1) CORBA is too damn complicated (that's why it's flexible) compared
to EJB.
You can whip up an EJB system in no time. Throw in all the other
nice stuff
like Servlets, JSP, JMS and any other Java TLA you can find and you've
got
some nice gear for your distribute apps.
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.
3) EJB can talk to CORBA (although, only reliably on the EJB client
side)
but not the other way around. This means that you can code all your
clients
in EJB, and then the servers that must be fast can be in CORBA. This
is an
installation nightmare, but works well enough.
4) Java is about 10 times easier to code than C++ for most people.
Like I
said, you don't have to know much to write a Java program (which why
most
people who like being called "smart" like using C++ and C and FORTRAN
:-).
There's more, but these are the only ones I can think of right now.
Now, my question to you is: Why the "EJB vs. CORBA" attitude? These
technologies were designed to compliment eachother. Let your monkeys
use the
nice Java to work up the system and get the design right and familiar.
Then,
figure out what MUST run fast and what MUST be accessed from any
language and
any computer, and then re-code those parts in CORBA and a faster
language
(like C++). This lets you get a design/implementation out fast that
works
and that everyone can understand, but still gives you the chance to
work that
distributed computing black magic to make it robust and scalable.
This is
why EJB can talk to CORBA.
Most likely, these EJB fans are just looking to increase their job
market
potential down the road. Especially if they are saying CORBA is old
(funny,
EJB uses RMI-IIOP for communication) and they want to learn the new
EJB
stuff. They've been scared by the dot-com meltdown and want a resume
stuffer
that looks hot so that they can still get jobs after the unspoken
industry
age cut-off of 40 years old.
Just my analysis. Keep on working on them, but don't be pig-headed.
You can
probably get a better system if you use both technologies.
Zed A. Shaw
On Wednesday 06 June 2001 17:02, you wrote:
> I know it is a generic CORBA question rather than specifically
> omniORB, but I know you lot have experience of using CORBA....
>
> Can anyone think of any practical advantages to starting a new
product
> from scratch using CORBA rather than EJBs. The reason is that we
are
> about to embark on a 3-tier application and I have a gut feeling
that
> CORBA will be more performant in the long run. I need to convince
the
> rest of the team that CORBA is the way to go, but I'm coming up
> against "CORBA is old technology now" arguments.
>
> We have no need to link to legacy systems, so there's no _physical_
> reason that we couldn't write everything using Java rather than C++.
> My benchmark tests have shown that mathematical calulation
performance
> is better using C++ than Java, but need more ammunition! Please
> help...
Mercia Software Ltd.
Mercia House
Ashted Lock
Aston Science Park
Birmingham B7 4AZ, UK
Registered Number: 1868855 (Cardiff)
Tel: 44 (0)121 359 5096
Fax: 44 (0)121 359 0375
Web Site: http://www.mercia.com