How good is CORBA?
Sai Krishna M
i have been developing web based applications using python+cheetah.
The numbers are increasing. The applications have many common parts of
code. Though these applications are separate from each other they are
run in the same server.
I heard about CORBA... but also heard that it has some flaws...like
the programming being very complicated.
Also heard that CORBA is no more used these days...
Can someone suggest me a better option or is corba fine?
Thanks,
Sai
--
I love Freedom
Nigel Rantor
This is an extremely loaded question and you're liable to get many
differing opinions.
What follows is just my opinion, I don't want to get into any religious
wars.
CORBA is a large, complex system that allows you to do object-RPC
efficiently and in many different languages.
Web services are now converging on the same solutions as the OMG did
with CORBA because they are solving the same problems.
If you need to access someone else's services then web services with
XML-RPC/SOAP/REST is probably a great idea.
If you have any kind of need for performance, or if all of your
interfaces are internal then I would choose CORBA.
I am currently building a system with a mixture of CORBA/SOAP interfaces
because of these trade-offs.
If you don't like CORBA, but want to do efficient object-RPC and don't
mind paying for it then perhaps look at Ice from www.zeroc.com, they're
a bunch of good guys who were big CORBA people and decided to go make an
object-RPC mechanism without the cruft that CORBA gathered.
Despite the fact that some very bad decisions were made about what to
include in CORBA you don't *have* to use any of the braindead features.
If you have any more specific questions then let me know, this is just
my quick 0.02c
Regards,
n
Chris Mellon
FYI: Ice is available under the GPL, so if by "pay" you mean "pay
money" that's not your only option. You can also get a commercial
license, similiar to Qt.
I like Ice a lot, it's got hardly any of the ramp up time and learning
curve that CORBA does, and it's extremely efficent. If GPL or cash are
acceptable licensing options to you, then I encourage you to use it
before you head to CORBA.
> Despite the fact that some very bad decisions were made about what to
> include in CORBA you don't *have* to use any of the braindead features.
>
> If you have any more specific questions then let me know, this is just
> my quick 0.02c
>
> Regards,
>
> n
>
Michael S
it had two main principles/purposes. One being
language neutrality and the other one to make
client/server type of programming easier (replacing
Remote Procedure Call??).
If you are using Python only, language neutrality
doesn't really help. You said you're writing web-based
applications, and you didn't specify whether you had
client/server interaction, so I don't know whether you
need it or not.
For code reuse (if that's the issue) you could use
subclassing and/or putting stuff into modules.
Hope I made some sense.
Michael
--- Sai Krishna M <saikr...@gmail.com> wrote:
> Hi everybody,
>
> i have been developing web based applications using
> python+cheetah.
>
> The numbers are increasing. The applications have
> many common parts of
> code. Though these applications are separate from
> each other they are
> run in the same server.
>
> I heard about CORBA... but also heard that it has
> some flaws...like
> the programming being very complicated.
> Also heard that CORBA is no more used these days...
>
> Can someone suggest me a better option or is corba
> fine?
>
> Thanks,
> Sai
> --
> I love Freedom
Sai Krishna M
> If you are using Python only, language neutrality
> doesn't really help. You said you're writing web-based
> applications, and you didn't specify whether you had
> client/server interaction, so I don't know whether you
> need it or not.
there are certainly client/server interactions..
--
I love Freedom
Gary Duzan
>
>i have been developing web based applications using python+cheetah.
>
>The numbers are increasing. The applications have many common parts of
>code. Though these applications are separate from each other they are
>run in the same server.
>
>I heard about CORBA... but also heard that it has some flaws...like
>the programming being very complicated.
>Also heard that CORBA is no more used these days...
CORBA is good for what it is good for. It does take some time
to get up to speed on it, but eventually most of it makes sense.
Some of the language mappings, especially C++, can be hard to use
safely, but the Python mapping is much easier to use.
If you need good performance, multiple language support, multiple
OS/hardware platform support, and preferably control both ends of
the communication, CORBA may be for you. Check out omniORB for C++
and Python (http://omniorb.sourceforge.net/), and JacORB for Java
(http://www.jacorb.org/).
Good luck.
Gary Duzan
Motorola CHS
cyberco
really shines when it comes to making distributed services work
together. Each application can be exposed as a Jini service whereby
other services only know the Java interface the service proxy
implements. How you implement the service itself (python?) or the
communication between the proxy and the service back-end (XML-RPC? RMI?
FTP? E-mail?) is completely up to you. Jini may look difficult at the
beginning, but distributed systems are inherently difficult. Jini just
makes them clear and forces you to deal with them in the easiest way
possible. In my opinion Jini is one of the best kept secrets of
distributed computing. Read up on the vision behind Jini to get an idea
of mother of all SOA technologies.
2B
Irmen de Jong
>
> I heard about CORBA... but also heard that it has some flaws...like
> the programming being very complicated.
> Also heard that CORBA is no more used these days...
CORBA's wire protocol (GIOP/IIOP) is heavily used in (java) EJB servers.
> Can someone suggest me a better option or is corba fine?
Well, if you are in a 100% python environment, I would suggest
to use Pyro instead (http://pyro.sf.net)
Or some other pure-Python RPC mechanism.
--Irmen
Sander Steffann
>> I heard about CORBA... but also heard that it has some flaws...like
>> the programming being very complicated.
>> Also heard that CORBA is no more used these days...
>
> CORBA's wire protocol (GIOP/IIOP) is heavily used in (java) EJB servers.
>
>> Can someone suggest me a better option or is corba fine?
>
> Well, if you are in a 100% python environment, I would suggest
> to use Pyro instead (http://pyro.sf.net)
> Or some other pure-Python RPC mechanism.
If, on the other hand, you want/have to combine different programming
languages and different environments, then CORBA will be a big help. For
example: Making objects implemented in Python on a Linux machine work with
objects implemented in C++ on a Windows machine (or even with objects
implemented in COBOL on a mainframe) will be no problem at all.
In our company we use CORBA a lot, even though we mostly use Python these
days. It gives us a lot of flexibility, while on the other hand it 'forces'
us to strictly define the interfaces of our objects before implementing
them. But that is a good thing :)
- Sander
Piet van Oostrum
>CM> FYI: Ice is available under the GPL, so if by "pay" you mean "pay
>CM> money" that's not your only option. You can also get a commercial
>CM> license, similiar to Qt.
>CM> I like Ice a lot, it's got hardly any of the ramp up time and learning
>CM> curve that CORBA does, and it's extremely efficent. If GPL or cash are
>CM> acceptable licensing options to you, then I encourage you to use it
>CM> before you head to CORBA.
OmniORB's author did some benchmarking and it appeared that omniORB was
faster than Ice.
--
Piet van Oostrum <pi...@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4]
Private email: pi...@vanoostrum.org
Chris Mellon
> >>>>> "Chris Mellon" <ark...@gmail.com> (CM) wrote:
>
> >CM> FYI: Ice is available under the GPL, so if by "pay" you mean "pay
> >CM> money" that's not your only option. You can also get a commercial
> >CM> license, similiar to Qt.
>
> >CM> I like Ice a lot, it's got hardly any of the ramp up time and learning
> >CM> curve that CORBA does, and it's extremely efficent. If GPL or cash are
> >CM> acceptable licensing options to you, then I encourage you to use it
> >CM> before you head to CORBA.
>
> OmniORB's author did some benchmarking and it appeared that omniORB was
> faster than Ice.
Nowhere did I say that Ice was faster than any given CORBA
implementation. People who want to do benchmark shootouts are on their
own. Ice is quick to learn, easy to use, and fast on the wire. That's
a good step up over CORBA to me.
> --
> Piet van Oostrum <pi...@cs.uu.nl>
> URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4]
> Private email: pi...@vanoostrum.org
Ravi Teja
> there are certainly client/server interactions.
But are they cross-language interactions?
This is how I would choose to distribute code.
Same machine, all in Python - organize in modules in Python path.
Different machines, all in Python - Pyro
Different machines, different languages, stateless calls, simple use -
XMLRPC/ReST
Different machines, different languages, stateless calls, more complex
requirements - SOAP
Different machines, different languages, statelful, typed - CORBA
(omniORB is the best bet at Python end)
ICE
A lot of the CORBA folks have been mad with ICE because it is subtly
discrediting CORBA while not being a standard. It is cleaner, comes
with good documentation, supports more languages than any single ORB
(however you are stuck with only those languages that ZeroC implements
support for). For simple apps, I would stick with omniORBPy. It is not
any more complicated than ICE. While ICE is simpler on the whole, you
will likely use only a fraction of the CORBA/ICE feature set. So the
difference won't necessarily show.
I like my tools to be simple. Lately, I have been happily using JSON
over HTTP.