Is CORBA still alive? What about ACE?

[c***@sharklasers.com]

It's been many years ago that I was using CORBA. 10 years ago I was
working on a large distribute system and at that time CORBA was quite
a hype.

Doing different things for quite a while now a new distributed system
shall be developed. Not having heard of any (really) good middleware
alternative I though of giving CORBA another try.

But there is not much news about CORBA in the magazins and there
aren't new books either. So somehow I have the feeling this technology
is vanishing. Well at least some implementations recently were updated
(omniORB) but others (mico) - well...

The systems we build have a rather long lifetime. So the technology we
gonna use must (1) be stable, (2) multi-platform and (3) still exist
tomorrow. So is CORBA still an option?

And what about ACE? There too isn't much news about ACE in the web.
Actually the only hits are wikipedia and Doug Schmidts homepage...

[Thomas Richter]

Post by c***@sharklasers.com
It's been many years ago that I was using CORBA. 10 years ago I was
working on a large distribute system and at that time CORBA was quite
a hype.
The systems we build have a rather long lifetime. So the technology we
gonna use must (1) be stable, (2) multi-platform and (3) still exist
tomorrow. So is CORBA still an option?

Not really. Even though others might disagree, but CORBA is essentially
dead and not much is going on in this area. Depending on what you are
doing, other communication protocols might be more an option. Most of
them don't try to implement a remote-function call procedure, but rather
implement some kind of data exchange that can be used to trigger,
amongst other things, remote function procedures.

SOAP can be used to communicate between machines and to trigger remote
function calls, though it is pretty complex and slower to parse. Though
it is in the market, and more visible than CORBA.

REST is a very basic simple protocol idea (not a protocol itself) that
is, again, not really an RPC mechanism, but can be used to implement
one, and then is considerably more lightweight than CORBA.

Sun-RPC is ancient and not really used anymore for new projects, but
still essential on *ix machines, including Linux and others. Still, I
wouldn't use it.

M$ .NET is not cross-platform, but implements RPC.

Java also includes a remote function call mechanism (Java-RMI) that is
both simpler to use and more lightweight than CORBA. But it is
restricted to the Java world, but then cross-platform in a sense.

As for (3), who can tell?

Post by c***@sharklasers.com
And what about ACE? There too isn't much news about ACE in the web.
Actually the only hits are wikipedia and Doug Schmidts homepage...

Dead and buried, if you ask me, and not really wide-spread enough. Even
less important than CORBA nowadays. Even though it included a lot of
good ideas and fixed all the flaws of CORBA, it never became popular
enough to reach a substantial market gain. This is, in my understanding,
because it was launched after the hype around CORBA was already
declining, and so nobody really cared.

I'm personally working with REST + JSON nowadays, never got a big fan of
SOAP due to its heavy-weight architecture, and while I worked a bit with
CORBA, its complexity and its absurd C++ language binding essentially
drove me off. Whether REST fits your needs I cannot tell, of course. It
is *not* an RPC mechanism, but something that allows you to implement
something *like* an RPC mechanism, so you cannot really compare. But for
my needs it does all I want to do, and all I did in CORBA before, just
simpler.

So long,
Thomas

[Andrew]

Post by Thomas Richter

Post by c***@sharklasers.com
So is CORBA still an option?

Not really. Even though others might disagree, but CORBA is essentially
dead and not much is going on in this area.

I disagree. I think CORBA is still an option. However, CORBA is dead
in that it is not evolving and it does have several problems,
particularly with C++. Several ORBs are available as open source, take
your pick. My preference would be TAO which is based on ACE. I am not
sure what happened to Orbix now that Iona is no more. Perhaps some
lurking Ionians may care to comment.

Post by Thomas Richter
Depending on what you are
doing, other communication protocols might be more an option.

Well this is the challenge isn't it. IMHO there isn't an official open
protocol that does the same job. The ones Thomas mentioned either do
quite a different job or are single platform/language.

Post by Thomas Richter
SOAP can be used to communicate between machines

No thank you.

Post by Thomas Richter
REST is a very basic simple protocol idea (not a protocol itself) that
is, again, not really an RPC mechanism, but can be used to implement
one, and then is considerably more lightweight than CORBA.

Tempting, but as you say, very basic and simple.

Post by Thomas Richter
Sun-RPC is ancient and not really used anymore

No thank you.

Post by Thomas Richter
M$ .NET is not cross-platform, but implements RPC.

'nuff said.

Post by Thomas Richter
Java also includes a remote function call mechanism (Java-RMI) that is
both simpler to use and more lightweight than CORBA.

Single language.

There is ICE, from ZeroC. One of the main guys behind ICE is Mitchi
Henning who was very active in the CORBA world. He applied what he
learnt from CORBA to make something much better (IMO) with a much
better binding for C++. He is famous for his article "The rise and
fall of CORBA". You might want to take a read at http://www.zeroc.com/riseAndFallOfCorba.html

Post by Thomas Richter

Post by c***@sharklasers.com
And what about ACE? There too isn't much news about ACE in the web.
Actually the only hits are wikipedia and Doug Schmidts homepage...

Dead and buried, if you ask me, and not really wide-spread enough.

By ACE I think you mean TAO which is the ORB built on ACE (TAO stands
for The ACE ORB). This is alive and well in a number of places that I
know of. It is still under active development and a new version was
released only recently.

Post by Thomas Richter
I worked a bit with
CORBA, its complexity and its absurd C++ language binding essentially
drove me off.

It did this to lots of people. This is one of the reasons why ICE was
developed.

Regards,

Andrew Marlow
http://www.andrewpetermarlow.co.uk

[Martin B.]

Post by Andrew

Post by Thomas Richter

Post by c***@sharklasers.com
So is CORBA still an option?

Not really. Even though others might disagree, but CORBA is essentially
dead and not much is going on in this area.

I disagree. I think CORBA is still an option. However, CORBA is dead
in that it is not evolving and it does have several problems,
particularly with C++. (...)
(...)

Post by Thomas Richter
I worked a bit with
CORBA, its complexity and its absurd C++ language binding essentially
drove me off.

It did this to lots of people. This is one of the reasons why ICE was
developed.

As for CORBA: I use it because it is still the best option. (see below)

As for ICE: It's great. (Actually excellent.) Except that last time I
checked (1 or 2 years ago) with them, their commercial licensing terms
drove me off.

As for CORBA and C++: The irony with CORBA and C++ is that while the
language binding is crappy (but not so horrible as one would be made to
believe, IMHO), C++ is *the* reason to use CORBA.

Why do I use C++ nowadays? Because of performance and/or because it
needs to be portable to an embedded device. What options do I have with
regard to a *performant*, decently *stable* and halfway *portable* C++
RPC mechanism: CORBA. Period. (And I'm happy to be *proven* otherwise :-)

Oh, and I hope the effort by the TAO people get a decent language
binding with C++11 for CORBA will succeed.

cheers,
Martin

[int21h]

Post by Andrew

Post by Thomas Richter

Post by c***@sharklasers.com
So is CORBA still an option?

Not really. Even though others might disagree, but CORBA is essentially
dead and not much is going on in this area.

I disagree. I think CORBA is still an option. However, CORBA is dead
in that it is not evolving and it does have several problems,
particularly with C++. Several ORBs are available as open source, take
your pick. My preference would be TAO which is based on ACE. I am not
sure what happened to Orbix now that Iona is no more. Perhaps some
lurking Ionians may care to comment.

Post by Thomas Richter
Depending on what you are
doing, other communication protocols might be more an option.

Well this is the challenge isn't it. IMHO there isn't an official open
protocol that does the same job. The ones Thomas mentioned either do
quite a different job or are single platform/language.

Post by Thomas Richter
SOAP can be used to communicate between machines

No thank you.

Post by Thomas Richter
REST is a very basic simple protocol idea (not a protocol itself) that
is, again, not really an RPC mechanism, but can be used to implement
one, and then is considerably more lightweight than CORBA.

Tempting,  but as you say, very basic and simple.

Post by Thomas Richter
Sun-RPC is ancient and not really used anymore

No thank you.

Post by Thomas Richter
M$ .NET is not cross-platform, but implements RPC.

'nuff said.

Post by Thomas Richter
Java also includes a remote function call mechanism (Java-RMI) that is
both simpler to use and more lightweight than CORBA.

Single language.
There is ICE, from ZeroC. One of the main guys behind ICE is Mitchi
Henning who was very active in the CORBA world. He applied what he
learnt from CORBA to make something much better (IMO) with a much
better binding for C++. He is famous for his article "The rise and
fall of CORBA". You might want to take a read athttp://www.zeroc.com/riseAndFallOfCorba.html

Post by Thomas Richter

Post by c***@sharklasers.com
And what about ACE? There too isn't much news about ACE in the web.
Actually the only hits are wikipedia and Doug Schmidts homepage...

Dead and buried, if you ask me, and not really wide-spread enough.

By ACE I think you mean TAO which is the ORB built on ACE (TAO stands
for The ACE ORB). This is alive and well in a number of places that I
know of. It is still under active development and a new version was
released only recently.

Post by Thomas Richter
I worked a bit with
CORBA, its complexity and its absurd C++ language binding essentially
drove me off.

It did this to lots of people. This is one of the reasons why ICE was
developed.
Regards,
Andrew Marlowhttp://www.andrewpetermarlow.co.uk

Thanks a lot for the valuable input. It is always good to hear 2nd
opinions. At least now I know
that I am on the right track (and did not miss some new hype in
middleware business).

BTW I did mean ACE as I am looking for a multiplatform solution. Which
basically means some
kind of OS wrapper which ACE is. That's the reason why TAO is so
broadly available - due to ACE ...

[Thomas Richter]

Post by Andrew

Post by Thomas Richter

Post by c***@sharklasers.com
So is CORBA still an option?

Not really. Even though others might disagree, but CORBA is essentially
dead and not much is going on in this area.

I disagree. I think CORBA is still an option. However, CORBA is dead
in that it is not evolving and it does have several problems,
particularly with C++. Several ORBs are available as open source, take
your pick.

I took my pick, which is omniorb. It is not bad, that's not what I'm
saying. It works correctly, and to the specs, so I'm not complaining on
this particular product. But the whole CORBA mindset/design is dying out.

Post by Andrew

Post by Thomas Richter
Depending on what you are
doing, other communication protocols might be more an option.

Well this is the challenge isn't it. IMHO there isn't an official open
protocol that does the same job. The ones Thomas mentioned either do
quite a different job or are single platform/language.

Correct. But it is usually easy to implement something along the lines
with such protocols that does solve the problem you have. To implement
tight binding between network-based systems, several options are
available. A remote-function call mechanism as the one offered by CORBA
is just one of the options. The problem with CORBA is that, while at
first glance it looks elegant and seems to hide the problems, the devil
is in all the details, and I ended up with the feeling that all of this
could have been done much easier, simpler and shorter if I had done it
myself *without* CORBA. The system is stable and running, so I did what
I did. But I wouldn't do it again this way.

CORBA did (and does) have a couple of issues ICE then tried to (or did)
address, CORBA does have some overhead (in my case, omniorb is probably
larger than my application), some language binding issues (C++ and java
in my case). It's the usual "you gain something, but you loose something".

Post by Andrew

Post by Thomas Richter
SOAP can be used to communicate between machines

No thank you.

Well, now that I'm giving so detailed reasons, it would be nice if you
would provide some insight as well. I do have my reasons today for not
picking SOAP, mostly because it is very heavy-weight. (And everyone
telling you XML is human-readable is just lying, IMHO). So for me it is
not really simpler. It has one advantage, namely that it suffices to
open only port 80. This is harder for CORBA, especially if you use it
behind a border-router as we do.

Post by Andrew

Post by Thomas Richter
REST is a very basic simple protocol idea (not a protocol itself) that
is, again, not really an RPC mechanism, but can be used to implement
one, and then is considerably more lightweight than CORBA.

Tempting, but as you say, very basic and simple.

Sure. It is basically a design choice, not so much a protocol. You need
to combine it with other sources. In my case, I'm using JSON over a
rest-type interface to implement a loose binding between two systems,
and it is by several magnitudes simpler than CORBA and does its job. Of
course, it is a *different* binding than that implemented by CORBA and
not a drop-in replacement, but I'm currently very happy with this
choice. IOW, I would pick a design around REST again. I would not pick
CORBA again.

Post by Andrew

Post by Thomas Richter
Sun-RPC is ancient and not really used anymore

No thank you.

Again, please elaborate. I do have my reasons, of course, but I'd like
to hear other opinions.

Post by Andrew

Post by Thomas Richter
M$ .NET is not cross-platform, but implements RPC.

'nuff said.

If your application world is M$, then where's the problem? In my case,
it isn't, so I didn't care to look, but as a general choice it seems to
do a lot of things right CORBA didn't.

Post by Andrew

Post by Thomas Richter
Java also includes a remote function call mechanism (Java-RMI) that is
both simpler to use and more lightweight than CORBA.

Single language.

Again, it would be useful to know in which language the original author
intends to work. If this is a java based setup, or a setup based on the
Java VM, and there are many today, this might also be a very good
choice, and one that works a lot better than CORBA. In the sense that
the learning curve is less steep and it is better integrated into the
overall language.

Post by Andrew
There is ICE, from ZeroC. One of the main guys behind ICE is Mitchi
Henning who was very active in the CORBA world.

Yes, I know. Don't tell me. ICE did a lot of things right CORBA didn't.

Post by Andrew
He applied what he
learnt from CORBA to make something much better (IMO) with a much
better binding for C++. He is famous for his article "The rise and
fall of CORBA". You might want to take a read at http://www.zeroc.com/riseAndFallOfCorba.html

Despite all that, it's not very popular because it came to life at a
time CORBA was dying already. Thus, too little, too late. I would need a
non-GPL open source implementation. ICE doesn't have that. Is there
anything going on with ICE? Is it ever applied? Any major use cases?

Again, a good (probably even very good) attempt, but too late for the show.

Post by Andrew

Post by Thomas Richter
I worked a bit with
CORBA, its complexity and its absurd C++ language binding essentially
drove me off.

It did this to lots of people. This is one of the reasons why ICE was
developed.

Again, I still stand for what I'm saying. CORBA was a hype, the hype is
over and now it's essentially dead. Similar problems, namely system
coupling, are solved in a different way today. No longer by remote
function calls.

Greetings,
Thomas

[Martin B.]

Post by Thomas Richter

Post by Andrew

Post by Thomas Richter

Post by c***@sharklasers.com
So is CORBA still an option?

Not really. Even though others might disagree, but CORBA is essentially
dead and not much is going on in this area.

I disagree. I think CORBA is still an option. However, CORBA is dead
in that it is not evolving and it does have several problems,
particularly with C++. Several ORBs are available as open source, take
your pick.

I took my pick, which is omniorb. It is not bad, that's not what I'm
saying. It works correctly, and to the specs, so I'm not complaining on
this particular product. But the whole CORBA mindset/design is dying out.

What is the "CORBA mindset/design"? (No, really.)

Post by Thomas Richter

Post by Andrew
(...)
He applied what he
learnt from CORBA to make something much better (IMO) with a much
better binding for C++. He is famous for his article "The rise and
fall of CORBA". You might want to take a read at
http://www.zeroc.com/riseAndFallOfCorba.html

Despite all that, it's not very popular because it came to life at a
time CORBA was dying already. Thus, too little, too late. I would need a
non-GPL open source implementation. ICE doesn't have that. Is there
anything going on with ICE? Is it ever applied? Any major use cases?

It does seem the product is rather healthy. It's a niche, sure, but why
call something dead, just because it's a niche?

Post by Thomas Richter
Again, a good (probably even very good) attempt, but too late for the show.

Too late for what show? (Seriously.)

Post by Thomas Richter
...
Again, I still stand for what I'm saying. CORBA was a hype, the hype is
over and now it's essentially dead. Similar problems, namely system
coupling, are solved in a different way today. No longer by remote
function calls.

See my other reply to Andrew for what I think CORBA is still an option
today.

The hype is dead as every hype is wont to be. That doesn't mean that
CORBA is buried, or does it?


just my 0.02
- Martin

[Thomas Richter]

Post by Martin B.

Post by Thomas Richter
I took my pick, which is omniorb. It is not bad, that's not what I'm
saying. It works correctly, and to the specs, so I'm not complaining on
this particular product. But the whole CORBA mindset/design is dying out.

What is the "CORBA mindset/design"? (No, really.)

I know, you probably don't expect an answer, but it is, in a nutshell,
"system binding by remote function calls".

Post by Martin B.

Post by Thomas Richter
Despite all that, it's not very popular because it came to life at a
time CORBA was dying already. Thus, too little, too late. I would need a
non-GPL open source implementation. ICE doesn't have that. Is there
anything going on with ICE? Is it ever applied? Any major use cases?

It does seem the product is rather healthy. It's a niche, sure, but why
call something dead, just because it's a niche?

What is it applied for? Really. If you design a distributed system today
(and not build on an existing architecture) would you pick ICE or CORBA?
I see no *new* systems designed this way, but maybe I don't see enough,
so let me know. To *my* knowledge, you work in a different way today and
use different architectures. By that I do not mean "better", I really
only mean "different". I consider a system "dead" if there is no active
development is going on in its market.

Post by Martin B.

Post by Thomas Richter
Again, a good (probably even very good) attempt, but too late for the show.

Too late for what show? (Seriously.)

Too late to ride on the CORBA hype, too late to gain a substantial
market at a time CORBA was still applied in many designs. Too late to
have an impact in the CORBA standardization, which would definitely had
improved it, and probably would have helped it to survive.

Post by Martin B.

Post by Thomas Richter
Again, I still stand for what I'm saying. CORBA was a hype, the hype is
over and now it's essentially dead. Similar problems, namely system
coupling, are solved in a different way today. No longer by remote
function calls.

See my other reply to Andrew for what I think CORBA is still an option
today.

I don't see this. For legacy designs, of course. I don't deny that this
defines a (very small, though) market. For new designs - I fail to see
your point. There are many choices, and CORBA is *not* a good one
anymore. Hard to use, too complex, and with implications on the network
infastructure (border routers, network filtering...)

Post by Martin B.
The hype is dead as every hype is wont to be. That doesn't mean that
CORBA is buried, or does it?

Question is, what is "buried" for you? If nothing new is done with
CORBA, I'd say it is pretty much dead.

So long,
Thomas

[Volker Birk]

Post by Thomas Richter
What is it applied for? Really. If you design a distributed system today
(and not build on an existing architecture) would you pick ICE or CORBA?

Yes, we do that.

We interconnect systems with Python and IEC 61131-3, with Java, .NET and
Webservices around. What else could be an option which is so good and so
widespread and available?

Yours,
VB.

[Thomas Richter]

Post by Volker Birk

Post by Thomas Richter
What is it applied for? Really. If you design a distributed system today
(and not build on an existing architecture) would you pick ICE or CORBA?

Yes, we do that.
We interconnect systems with Python and IEC 61131-3, with Java, .NET and
Webservices around. What else could be an option which is so good and so
widespread and available?

May I ask what your application domain is? For webservices - in the
traditional sense - there are many more popular choices. So maybe you
have special demands not addressed by such solutions (SOAP, REST maybe?).

So long,
Thomas

[Volker Birk]

Post by Thomas Richter

Post by Volker Birk

Post by Thomas Richter
What is it applied for? Really. If you design a distributed system today
(and not build on an existing architecture) would you pick ICE or CORBA?

Yes, we do that.
We interconnect systems with Python and IEC 61131-3, with Java, .NET and
Webservices around. What else could be an option which is so good and so
widespread and available?

May I ask what your application domain is?

We did it in telematics, now we're using CORBA in automation business,
mainly machine building.

Post by Thomas Richter
For webservices - in the
traditional sense - there are many more popular choices. So maybe you
have special demands not addressed by such solutions (SOAP, REST maybe?).

SOAP is slow and bloaty. I think it's a crazy idea to use XML for
implementing RPC. The only way to explain SOA is that in big enterprises
the people who do the Cisco business are usually not in the same
department as the people who're developing the applications. So the
Cisco and the firewalling guys are closing the net, while the
application guys are tunneling through HTTP and SMTP, because this will
remain open ;-)

Yours,
VB.

[Thomas Richter]

Post by Volker Birk

Post by Thomas Richter

Post by Volker Birk

Post by Thomas Richter
What is it applied for? Really. If you design a distributed system today
(and not build on an existing architecture) would you pick ICE or CORBA?

Yes, we do that.
We interconnect systems with Python and IEC 61131-3, with Java, .NET and
Webservices around. What else could be an option which is so good and so
widespread and available?

May I ask what your application domain is?

We did it in telematics, now we're using CORBA in automation business,
mainly machine building.

I see, thanks. So you have a need for near-real-time response, do I see
this correctly?

Post by Volker Birk

Post by Thomas Richter
For webservices - in the
traditional sense - there are many more popular choices. So maybe you
have special demands not addressed by such solutions (SOAP, REST maybe?).

SOAP is slow and bloaty. I think it's a crazy idea to use XML for
implementing RPC. The only way to explain SOA is that in big enterprises
the people who do the Cisco business are usually not in the same
department as the people who're developing the applications.

I certainly don't disagree here, I'm not much of a fan of XML and SOAP
either. It's not the right choice for such applications.

Post by Volker Birk
So the
Cisco and the firewalling guys are closing the net, while the
application guys are tunneling through HTTP and SMTP, because this will
remain open ;-)

Sure, a strange world, but this leaves other options. I'm not suggesting
to use SOAP in your domain (which is, as said, pretty insane). I'm
neither suggesting to drop CORBA, you should know better what you need
to do than I could.

But I wonder - is CORBA an ideal fit with all its complexity, i.e. how
much software and computing power is in such machines? I would go for
something simpler then. So, my question would probably be: Why do you
need *function calls* in first place to talk to your hardware?

So long,
Thomas

[Volker Birk]

Post by Thomas Richter

Post by Volker Birk
We did it in telematics, now we're using CORBA in automation business,
mainly machine building.

I see, thanks. So you have a need for near-real-time response, do I see
this correctly?

As a matter of fact, we even have the need for RT itself. For this
purpose, we don't use CORBA but our own RPC, RT-RPC, which we're also
gatewaying to and from CORBA.

Post by Thomas Richter
But I wonder - is CORBA an ideal fit with all its complexity, i.e. how
much software and computing power is in such machines? I would go for
something simpler then. So, my question would probably be: Why do you
need *function calls* in first place to talk to your hardware?

Well, as I said, we're using RT-RPC inside the PLCs, and we're
gatewaying that to and from CORBA. But we chose the option to have RPC,
because this is very handy for the application programmers. It's really
nice to have an IDL file and to generate as well the CORBA part as well
as the Structured Text part out of it, making life easy for both types
of programmers.

When we describe an interface between two PLCs in IDL, then we're
generating RT-RPC without a CORBA "in-between". CORBA's IDL is a good
thing either.

Yours,
VB.

[Wil Evers]

Post by Thomas Richter

Post by Volker Birk

Post by Thomas Richter
What is it applied for? Really. If you design a distributed system today
(and not build on an existing architecture) would you pick ICE or CORBA?

Yes, we do that.
We interconnect systems with Python and IEC 61131-3, with Java, .NET and
Webservices around. What else could be an option which is so good and so
widespread and available?

May I ask what your application domain is? For webservices - in the
traditional sense - there are many more popular choices. So maybe you
have special demands not addressed by such solutions (SOAP, REST maybe?).

This is going nowhere; web services and RPC-based designs serve completely
different purposes.

Recently, I was intimately involved in a remote method call-based system
involving processes running native code, Java VM's, .Net CLR instances, and
Python scripts, running on multiple hosts spread across a LAN, with the
usual mix of operating systems (Windows, Linux, Solaris, AIX, HP/UX) and
databases, all administered by a single organization.

The typical server process in this system routinely processes tens of
thousands of calls per second, even on older hardware or when implemented
in Java. This allowed us to pick a fine-grained distributed object model,
and to compose new, higher-level services, largely by reusing and combining
existing network components.

Finally, to keep the SOA people on the outside happy, we built a mapping
engine that used the interface definitions in our own interface repository
to generate WSDL.

Now tell me you can do that when web services are used to expose the
individual core components to the LAN.

- Wil

[Thomas Richter]

Post by Wil Evers

Post by Thomas Richter

Post by Volker Birk

Post by Thomas Richter
What is it applied for? Really. If you design a distributed system today
(and not build on an existing architecture) would you pick ICE or CORBA?

Yes, we do that.
We interconnect systems with Python and IEC 61131-3, with Java, .NET and
Webservices around. What else could be an option which is so good and so
widespread and available?

May I ask what your application domain is? For webservices - in the
traditional sense - there are many more popular choices. So maybe you
have special demands not addressed by such solutions (SOAP, REST maybe?).

This is going nowhere; web services and RPC-based designs serve completely
different purposes.

I would say this pretty much depends on from which perspective you look.
Yes, they are certainly *not* drop-in replacements. I don't want to
claim that.

Post by Wil Evers
Recently, I was intimately involved in a remote method call-based system
involving processes running native code, Java VM's, .Net CLR instances, and
Python scripts, running on multiple hosts spread across a LAN, with the
usual mix of operating systems (Windows, Linux, Solaris, AIX, HP/UX) and
databases, all administered by a single organization.
The typical server process in this system routinely processes tens of
thousands of calls per second, even on older hardware or when implemented
in Java. This allowed us to pick a fine-grained distributed object model,
and to compose new, higher-level services, largely by reusing and combining
existing network components.
Finally, to keep the SOA people on the outside happy, we built a mapping
engine that used the interface definitions in our own interface repository
to generate WSDL.
Now tell me you can do that when web services are used to expose the
individual core components to the LAN.

How can I tell that? I don't know your problem precisely enough. Look, I
haven't designed your system, and if it was designed such that "remote
function calls" are the way how information goes from A to B, then so
might it be. If you have older hardware, then SOAP isn't a choice for
you in first place if lots of calls have to be made.

But *do* have calls to be made? Or, to put it differently, was it
necessary to design the system in exactly that way? (Of course, speaking
hypothetically. Now the system is as it is, and I don't want to imply
that it's worth changing.) Objects can also be something completely
different than "CORBA objects". Maybe "resources"?

Greetings,
Thomas

[Wil Evers]

Post by Thomas Richter
Look, I
haven't designed your system, and if it was designed such that "remote
function calls" are the way how information goes from A to B, then so
might it be. If you have older hardware, then SOAP isn't a choice for
you in first place if lots of calls have to be made.
But *do* have calls to be made? Or, to put it differently, was it
necessary to design the system in exactly that way? (Of course, speaking
hypothetically. Now the system is as it is, and I don't want to imply
that it's worth changing.) Objects can also be something completely
different than "CORBA objects". Maybe "resources"?

Well, I guess I'm just not smart enough to understand what these web
services are all about. I can see how they make sense if the only thing
under my control is the client, the server is only reachable over HTTP, the
remote side doesn't change state too often, or the people on the other side
can't or won't change their interface, which is probably optimized for
round trip times of over 30 ms anyway.

But what if we *do* have control over how the client and the server are
deployed? What if they're close to each other, say connected to the same
LAN, or even running on the same host, but in another process because one
has business logic written in Java, and the other in C#? What if we want
to aggregate these components into bigger whole, while still providing
acceptable response times?

I'm suggesting that, for that kind of situation, a networking model based on
remote procedure calls and/or distributed objects is the conceptually
cleanest solution. It should therefore also be the easiest to use, and I
believe it has been shown that it can be, as long as we avoid the
unnecessary complexities in CORBA.

Regards,

- Wil

[int21h]

"Similar problems, namely system coupling, are solved in a different way today. No longer by remote function calls"
" For new designs [...] There are many choices, and CORBA is *not* a good one anymore"

Back in the time we used CORBA it was brand new and for us its usage
really paid off. Doing different thing (deeply
embedded stuff) I though I just missed another revolution. But this
seems not to be the case. All the technologies
out there (be it SOAP, .NET, RMI) occure to me even more a niche than
CORBA, right? At least taken the total usage
counter.

So - apart from ICE which seems to be a better CORBA (or CORBA
designed the "right" way") - which
technologies would you suggest for a distributed OO system that
involves different platforms (HW/OS) and languages.

Very much appreciate your comments.

[Martin B.]

Post by Thomas Richter

Post by Martin B.

Post by Thomas Richter
I took my pick, which is omniorb. It is not bad, that's not what I'm
saying. It works correctly, and to the specs, so I'm not complaining on
this particular product. But the whole CORBA mindset/design is dying out.

What is the "CORBA mindset/design"? (No, really.)

I know, you probably don't expect an answer, but it is, in a nutshell,
"system binding by remote function calls".

I really hoped for one, seriously. Thanks for replying.

To crack your nutshell: I'm not entirely sure what you mean by "system
binding" but surely SOAP, REST, and what else there is are simply a
means for "remote function calls".

There are certainly different, message based, approaches
(www.open-mpi.org/) -- I also found
http://steve.vinoski.net/blog/2008/07/01/convenience-over-correctness/ |
http://steve.vinoski.net/pdf/IEEE-Convenience_Over_Correctness.pdf a
very interesting read -- but viewed from this angle, SOAP, XML-RPC,
Java-RMI, CORBA, ICE, DCOM and dotNET-remoting are all the "same" thing.

Note: I still have a (C++ & dotNET) project in the pipeline where there
the question CORBA-or-not is not resolved. Therefore I am genuinely
interested in discussing this further.

cheers,
Martin

[Thomas Richter]

Post by Martin B.

Post by Thomas Richter

Post by Martin B.
What is the "CORBA mindset/design"? (No, really.)

I know, you probably don't expect an answer, but it is, in a nutshell,
"system binding by remote function calls".

I really hoped for one, seriously. Thanks for replying.
To crack your nutshell: I'm not entirely sure what you mean by "system
binding" but surely SOAP, REST, and what else there is are simply a
means for "remote function calls".

Thanks, yes, I see. What probably my concern is is that you seem to see
all from a "remote function call" perspective. Sure, there are probably
applications where you want to "call into" another machine. But
basically, this type of "calling" is just another word for "information
interchange" between two separate hardware units, and probably "remote
function call" is not even necessary. Thus, I'm not claiming that "SOAP"
or "REST" are "replacements" for CORBA or remote function call
mechanisms. Of course they are not. REST is *all* but a Remote function
call protocol. (-: But, to make my point, it is one (design principle)
how to make machines talk to each other, and thus *may* be a mechanism
to exchange information between them, with the same higher goal you
could reach with CORBA.

Using the mentioned protocols *just* to implement remote-function
calling is, of course, insane. Then use remote function calls right
away. But the problem *why you need* remote function calls, this problem
can be solved probably in a more elegant way in first place.

I think this is the point I'm trying to make. Otherwise, I don't really
disagree. CORBA is of course a different type of coupling than REST is,
than SOAP is.

Post by Martin B.
There are certainly different, message based, approaches
(www.open-mpi.org/) -- I also found
http://steve.vinoski.net/blog/2008/07/01/convenience-over-correctness/ |
http://steve.vinoski.net/pdf/IEEE-Convenience_Over_Correctness.pdf a
very interesting read -- but viewed from this angle, SOAP, XML-RPC,
Java-RMI, CORBA, ICE, DCOM and dotNET-remoting are all the "same" thing.

From a high perspective, yes. Thanks for the links, I'll probably go
into them.

Post by Martin B.
Note: I still have a (C++ & dotNET) project in the pipeline where there
the question CORBA-or-not is not resolved. Therefore I am genuinely
interested in discussing this further.

Shrug. It really depends on the problem you want to solve. My first
CORBA project was a remote computation server which talked to its
clients/front-ends with CORBA. The clients would trigger the
computation, which would then be done on the server, and which would be
visible to other clients. Using the abstraction of function calls was
kind of neat, and it also somehow seemed plausible, but now I'm running
a quite similar project, and we realized it now with REST, and I found
this neither harder to do, just one level less complex, and less
dependent from third-party software. The design is of course all
different, but we started from scratch, so we had a couple of choices
*how* to design it, and thus it was made in such a way that it fit into
another "information interchange paradigm" if you want to say so. Of
course redesigning the old system (not a replacement, just something
different) is insane now, so that will stick with CORBA as it is. Unless
I should have plenty of time in the next years - unlikely!

So long,
Thomas

[Martin B.]

Post by Thomas Richter

Post by Martin B.

Post by Thomas Richter

Post by Martin B.
What is the "CORBA mindset/design"? (No, really.)

I know, you probably don't expect an answer, but it is, in a nutshell,
"system binding by remote function calls".

I really hoped for one, seriously. Thanks for replying.
To crack your nutshell: I'm not entirely sure what you mean by "system
binding" but surely SOAP, REST, and what else there is are simply a
means for "remote function calls".

Thanks, yes, I see. What probably my concern is is that you seem to see
all from a "remote function call" perspective. Sure, there are probably
applications where you want to "call into" another machine. But
basically, this type of "calling" is just another word for "information
interchange" between two separate hardware units, and probably "remote
function call" is not even necessary. Thus, I'm not claiming that "SOAP"
or "REST" are "replacements" for CORBA or remote function call
mechanisms. Of course they are not. REST is *all* but a Remote function
call protocol. (-: (...)

As for me, while it's used for different things, I really cannot see the
conceptual difference between a REST invocation

GET : http://server/service/resource?action=getQuote

and a CORBA call

IDL : module service { interface resource { string getQuote(); } }
usage : myresource->getQuote();

Obviously, as you say, the devil is in the details, and the REST
coupling is certainly looser and easier to use from an arbitrary client
platform, but the CORBA version will certainly perform better and can be
statically checked more easily when implementing the client.

I guess my point here is really that when you are down at the
programming level on the client side, *all* these protocols (and maybe
even the "real" message based ones) will be implemented via a local
layer that provides local(-looking) function calls (or object methods)
to the application level programmer, likely handling errors via some
sort of exception mechanism.

( This "local layer" can be an ad-hoc one if I wrap my HTTP calls for a
RESTful interface in a set of functions, or it can be a given one like
the CORBA C++ binding. (I'm not saying either is necessarily better.) )

So, once some sort of application domain "library" or "API" has been
established, the application level programmers will only care that their
"calls to that remote resource" "just work". The calls look similar
regardless of the technology used because how they look is likely
dictated by the client platform and the application domain and not by
the underlying transport.

Post by Thomas Richter
Using the mentioned protocols *just* to implement remote-function
calling is, of course, insane. Then use remote function calls right
away. But the problem *why you need* remote function calls, this problem
can be solved probably in a more elegant way in first place.
I think this is the point I'm trying to make. Otherwise, I don't really
disagree. CORBA is of course a different type of coupling than REST is,
than SOAP is.
(...)

Post by Martin B.
Note: I still have a (C++ & dotNET) project in the pipeline where there
the question CORBA-or-not is not resolved. Therefore I am genuinely
interested in discussing this further.

Shrug. It really depends on the problem you want to solve. My first
CORBA project was a remote computation server which talked to its
clients/front-ends with CORBA. The clients would trigger the
computation, which would then be done on the server, and which would be
visible to other clients. Using the abstraction of function calls was
kind of neat, and it also somehow seemed plausible, but now I'm running
a quite similar project, and we realized it now with REST, and I found
this neither harder to do, just one level less complex, and less
dependent from third-party software. (...)

Good example.

But I see the following questions that need to be asked before one can
decide on the communication method:

Performance:
* How many "requests" per second do we need to process?
* How much data is transferred with each request/response?
* How much can be gained from transferring the data in a binary form?
* How much lag can we accept?

Robustness and administration:
* Are messages allowed to be lost?
* Do we need to "tunnel" our communication?
* Do we need to encrypt our data?
* Do we need more than port 80? ;-)

Programming:
* What languages?
* What platforms?
* How many different clients by different vendors?
* Is the protocol open? (Do I need to pay for a license to write a client?)


Looking at these axes, when I have:
... && many-requests && low-lag && native C++ && LAN-only
then I think CORBA is still one of the better solutions today.

Then, maybe I should check if I can get some decent licensing deal with
ICE for this next project :-)


cheers,
Martin

[Agents Marlow]

Post by Thomas Richter
I took my pick, which is omniorb. It is not bad, that's not what I'm
saying. It works correctly, and to the specs, so I'm not complaining on
this particular product.

Yes, OmniOrb's not bad either.

Post by Thomas Richter
But the whole CORBA mindset/design is dying out.

Agreed, but I think this is pity. Apart from ICE there is nothing that
is cross platform and cross language and OO to replace it.

Post by Thomas Richter
The problem with CORBA is that, while at
first glance it looks elegant and seems to hide the problems, the devil
is in all the details, and I ended up with the feeling that all of this
could have been done much easier, simpler and shorter if I had done it
myself *without* CORBA.

IMO this is why ICE was invented.

Post by Thomas Richter

Post by Andrew

Post by Thomas Richter
SOAP can be used to communicate between machines

No thank you.

Well, now that I'm giving so detailed reasons, it would be nice if you
would provide some insight as well.

I say what everyone else says and what IMO is bleedin' obvious - using
XML for over the wire comms is mad and bad. Its ok for config files
maybe and other things that require lots of metadata (e.g articles
held by publishers with lots of cross-indexing). But over the wire is
so inefficient for no obvious gain. My preference in this area is
actually ASN.1 but I realise that puts me in a very small minority.

I do have my reasons today for not

Post by Thomas Richter
picking SOAP, mostly because it is very heavy-weight. (And everyone
telling you XML is human-readable is just lying, IMHO). So for me it is
not really simpler. It has one advantage, namely that it suffices to
open only port 80. This is harder for CORBA, especially if you use it
behind a border-router as we do.

As for an advantage being you can use port 80 I think this is lazyness
and having to grapple with obstructions caused by security departments
(e.g they wont open up the ports you need so you wind up using port
80).

CORBA and security just dont mix. The best you can do is get a third
party add-on. There are a few around, e.g iLock from 2AB,
http://www.2ab.com/products.htm. Firewalls and CORBA is probably the
biggest challenge here. That's why, IMO that if you are going to use
CORBA it must be completely behind the corporate firewall, not for
outside comms.

Post by Thomas Richter

Post by Andrew

Post by Thomas Richter
Sun-RPC is ancient and not really used anymore

No thank you.

Again, please elaborate. I do have my reasons, of course, but I'd like
to hear other opinions.

It was geared for comms between SUN machines so with machines of
different endian-ness there are some ineffiencies. The interface is C-
like, i.e. no OO so you are working at a very low level of
abstraction. It's also a big of a bother to set up the build system so
that rpcgen is integral to the build. But that could be me being lazy
- after all if you use CORBA you need to do something similar for the
IDL compilation.

Post by Thomas Richter

Post by Andrew

Post by Thomas Richter
M$ .NET is not cross-platform, but implements RPC.

'nuff said.

If your application world is M$, then where's the problem?

One problem is that if you pick a M$-technology then you lock yourself
into the M$ world. If you were not locked into that world to start
with this is simply a mistake. If you were in that world to start with
then adopting more and more lock-in mechanisms will ensure that you
can never leave.

Post by Thomas Richter
In my case,
it isn't, so I didn't care to look, but as a general choice it seems to
do a lot of things right CORBA didn't.

Well that isn't difficult though, is it? CORBA is the ultimate design
by committee nightmare.

Post by Thomas Richter

Post by Andrew

Post by Thomas Richter
Java also includes a remote function call mechanism (Java-RMI) that is
both simpler to use and more lightweight than CORBA.

Single language.

Again, it would be useful to know in which language the original author
intends to work. If this is a java based setup, or a setup based on the
Java VM, and there are many today, this might also be a very good
choice, and one that works a lot better than CORBA.

Yes.

Post by Thomas Richter

Post by Andrew
There is ICE, from ZeroC.

[snip]

Post by Thomas Richter
Despite all that, it's not very popular because it came to life at a
time CORBA was dying already. Thus, too little, too late.

Well, maybe it was a bit late but better late than never. I do know of
it being used in one proprietary product development that formerly
used CORBA.

Post by Thomas Richter
Is there
anything going on with ICE? Is it ever applied? Any major use cases?

See http://www.zeroc.com/customers.html

Post by Thomas Richter

Post by Andrew

Post by Thomas Richter
I worked a bit with
CORBA, its complexity and its absurd C++ language binding essentially
drove me off.

It did this to lots of people. This is one of the reasons why ICE was
developed.

Again, I still stand for what I'm saying. CORBA was a hype, the hype is
over and now it's essentially dead.

Everything in computing is hype and fashion. So yes, CORBA was hype
and the hype is over. But that doesn't mean it's dead.

Post by Thomas Richter
Similar problems, namely system
coupling, are solved in a different way today. No longer by remote
function calls.

There does seem to be a revolt against that, I agree. I presume you
include OO remote calls in that as opposed to just XDR RPC. But even
during the latter part of CORBA's hey-day people were saying that
CORBA should be used to wrap network service calls rather than to
create objects were some functions calls are transparantly remoted.

Regards,

Andrew Marlow

[Malcolm Spence]

Post by c***@sharklasers.com
It's been many years ago that I was using CORBA. 10 years ago I was
working on a large distribute system and at that time CORBA was quite
a hype.
Doing different things for quite a while now a new distributed system
shall be developed. Not having heard of any (really) good middleware
alternative I though of giving CORBA another try.
But there is not much news about CORBA in the magazins and there
aren't new books either. So somehow I have the feeling this technology
is vanishing. Well at least some implementations recently were updated
(omniORB) but others (mico) - well...
The systems we build have a rather long lifetime. So the technology we
gonna use must (1) be stable, (2) multi-platform and (3) still exist
tomorrow. So is CORBA still an option?
And what about ACE? There too isn't much news about ACE in the web.
Actually the only hits are wikipedia and Doug Schmidts homepage...

We are still supporting ACE and TAO. They are still part of the
various US DOD open architecture approved open source products. We
still see new projects from a variety of industries pick TAO. Mostly
they want Real time and large scale behaviors. (i.e. non Java).

There is new development taking place with CORBA Component Model (CCM)
on top of TAO. Vanderbilt is being funded to expand its capabilities.

We also support JacORB so Java is not in any way excluded. JacORB is a
part of the JBoss distribution and is still maintained by us and
others.

The other OMG RT middleware option is DDS. We support OpenDDS which
uses ACE as its abstraction layer. We also share aspects of IDL with
TAO. OpenDDS support C++ and Java and can interoperate with .NET.
OpenDDS is taking off as more people realize the benefits of loosely
coupling systems with RT pub sub.

regards Malcolm Spence
Director of Business Development
OCI St. Louis MO
1-314-590-0206

www.theaceorb.com
www.opendds.org
www.ociweb.com
regards Malcolm

[Johnny Willemsen]

Hi,

I was out last week, so read the complete thread and want to give one reply

It is true that CORBA is not a hype anymore, but it is not dead. it is
used in a lot of existing projects, but there are daily new projects
starting that are using CORBA. They all have something special, very
large, very small, high performance, high data rate, portability,
multiple programming languages, etc.

There are some concerns regarding CORBA, the C++ binding is a large one.
The OMG issued a RFP for a new IDL to C++0x binding last year, we are
working on a proposal, see the forums on http://www.orbzone.org for the
discussions about this. We are going to present our initial submission
at the upcoming OMG meeting in September (see
http://www.omg.org/news/meetings/tc/fl-11/info.htm). This will make it
much easier to use CORBA (or any IDL based middleware) in C++, no
_var/_ptr, use of STL containers, etc. If you check our OSPortal on
http://osportal.remedy.nl you will find several examples that are
already working completely.

Another concern is whether something still happens. I can confirm that
there is still activity around CORBA. Last year we standardized the
integration of compression into CORBA, this year we have extended the
IDL grammar.

If we look at ACE, that is also still heavily used. It is very stable in
terms of its API and very portable. Its features are very rich and each
project uses just a part of it. As mentioned, TAO as CORBA ORB is build
on top of ACE making it also very portable.

During the ACE/TAO courses I deliver I see that most projects are just
complex because they have a lot of special needs. Most of the challenges
that come up during the course are because people just underestimate the
challenges of a remote realtime invocation and what all can go wrong.
With TAO we are able to resolve those challenges by just setting some
QoS settings, not by changing the application code or switching to some
kind of other IPC mechanism.

Especially in the area of large projects, we see a renewed interest in
CCM (CORBA Component Model). Those projects do need something more than
a request/reply kind of middleware, they need a component model and a
deployment model that makes it possible to reuse parts. The advantage of
CCM is that it is a formal standard and supports various programming
languages and platforms. CCM is not something you learn in just a few
days, but if you have a large project, it can give a lot of benefits on
the long term. The availability of DDS4CCM to integrate DDS and AMI4CCM
for asynchronous calls makes CCM much more powerful. In the fear future
we as Remedy IT want to converge CCM to a Common Component Model, use
IDL to define your types, interfaces, and components and than it is a
deployment decision how those components community with each other, it
can be CORBA, but also SOAP, REST, ICE, AMQP, etc. As mentioned, they
all do the same, give some kind of remote invocation concept.

An interesting presentation about CCM/DDS4CCM from Northrop Grumman can
be found online at http://www.orbzone.org/node/182

So CORBA it not dead, it is there and is being improved and extended. It
is an option to check for your project, but it takes some time to learn
the current IDL to C++ language mapping, we will resolve that with the
new language mapping we are working on.

Regards,

Johnny

The links:
http://www.orbzone.org
http://osportal.remedy.nl
http://www.omg.org/news/meetings/tc/fl-11/info.htm

Post by c***@sharklasers.com
It's been many years ago that I was using CORBA. 10 years ago I was
working on a large distribute system and at that time CORBA was quite
a hype.
Doing different things for quite a while now a new distributed system
shall be developed. Not having heard of any (really) good middleware
alternative I though of giving CORBA another try.
But there is not much news about CORBA in the magazins and there
aren't new books either. So somehow I have the feeling this technology
is vanishing. Well at least some implementations recently were updated
(omniORB) but others (mico) - well...
The systems we build have a rather long lifetime. So the technology we
gonna use must (1) be stable, (2) multi-platform and (3) still exist
tomorrow. So is CORBA still an option?
And what about ACE? There too isn't much news about ACE in the web.
Actually the only hits are wikipedia and Doug Schmidts homepage...

[Thomas Girard]

Hello,

Post by Johnny Willemsen
this year we have extended the
IDL grammar.

What are the extensions you're referring to?

Regards,

Thomas

[Johnny Willemsen]

Hi,

Post by Thomas Girard

Post by Johnny Willemsen
this year we have extended the
IDL grammar.

What are the extensions you're referring to?

The IDL3+ (which is part IDL2 and IDL3) extensions as part of DDS4CCM,
see http://www.omg.org/spec/dds4ccm for the 1.0 version of that spec.
The beta 2 doesn't contain those extensions anymore, because they are
moved to the beta CORBA 3.2 spec (see http://www.omg.org/spec/CORBA).

Regards,

Johnny Willemsen
Remedy IT

[Rob]

CORBA's momentum was systematically squashed by the Web Services crowd
who made claims that it was dead. (I usually interpret claims of a
technology being dead as a sales pitch for some other technology.) Ten
years later, after amassing a large complex stack W* specifications
and implementations that still don't address all of the CORBA's
capabilities, the industry is moving towards other fledgling solutions
such as Google Protocol Buffers, Thrift, ICE and a whole litany of
other approaches to serialization: https://github.com/eishay/jvm-serializers/wiki/.
(ICE appears to be the most mature and capable of the lot.)
(Other benchmarks can be found here:
http://www.atl.external.lmco.com/projects/QoS/compare/dist_oo_compare_ipc.html
)

Some of these solutions are still subsets of the CORBA CDR. For
instance, Protocol Buffers don't include a standard way to specify
type information such as with the CORBA Any type or some of the
richness of ValueTypes. The W* approaches have to handle binary type
data (images, audio, video, large arrays) in special ways such as
base64 encoding or with attachments to the XML.

JacORB, MICO, TAO, OmniORB and associated vertical services such as
Naming, Notification, Event, Interface Repository are still being
actively maintained and are quite mature and reliable. As for
security, many of the implementations support SSH, password and
certificate based authentication/authorization as well. There are nice
bindings for Ruby, Tcl (Combat) and other scripting languages now as
well.

One argument that I've heard against CORBA is that it is only RPC,
which isn't quite correct. You can do messaging style communication
via the Notification and Event service and the Any type. If a simple
oneway was added to the receive method of the event services, they'd
be even more efficient and less "RPC".

I'd love to see incremental improvements in CORBA such as: a cleaner
Java bindings or a move towards a JAXB approach where the developer
can define his own local bindings; a standardized approach to
versioning such as with ICE's facets (SOAP still has trouble with
versioning as well, requiring best-practice approaches to deal with
it), more proliferation and refinement of the CORBA-reflection
feature. Its disappointing to see such a capable stack of technology
dumped, especially in exchange for other alternatives that haven't
quite measured up if you do a complete comparison of capabilities.
(The guys at ZeroC have done a great job with their ICE stack,
although I wish it was CDR compatible or standardized with multiple
implementations.)

I've also noticed that many developers slam CORBA who have never used
it! Its too bad that our industry is so driven by marketing, dogma and
folklore.

So the decision on a technology probably depends what your project
requires. If you need a rich high-performance horizontal and vertical
stack of services, CORBA is still a great cross-language solution as
far as I'm concerned.

Post by c***@sharklasers.com
It's been many years ago that I was using CORBA. 10 years ago I was
working on a large distribute system and at that time CORBA was quite
a hype.
Doing different things for quite a while now a new distributed system
shall be developed. Not having heard of any (really) good middleware
alternative I though of giving CORBA another try.
But there is not much news about CORBA in the magazins and there
aren't new books either. So somehow I have the feeling this technology
is vanishing. Well at least some implementations recently were updated
(omniORB) but others (mico) - well...
The systems we build have a rather long lifetime. So the technology we
gonna use must (1) be stable, (2) multi-platform and (3) still exist
tomorrow. So is CORBA still an option?
And what about ACE? There too isn't much news about ACE in the web.
Actually the only hits are wikipedia and Doug Schmidts homepage...

[Martin B.]

(...) Ten
years later, (...)
and implementations that still don't address all of the CORBA's
capabilities, the industry is moving towards other fledgling solutions
such as Google Protocol Buffers, Thrift, ICE and a whole litany of
other approaches to serialization: (...)

+1 - It's really annoying :-)

http://www.atl.external.lmco.com/projects/QoS/compare/dist_oo_compare_ipc.html

Excellent link. Bookmarked!

(...)

[Rob]

CORBA's momentum was systematically squashed by the Web Services crowd
who made claims that it was dead. (I usually interpret claims of a
technology being dead as a sales pitch for some other technology.) Ten
years later, after amassing a large complex stack W* specifications
and implementations that still don't address all of the CORBA's
capabilities, the industry is moving towards other fledgling solutions
such as Google Protocol Buffers, Thrift, ICE and a whole litany of
other approaches to serialization: https://github.com/eishay/jvm-serializers/wiki/.
(ICE appears to be the most mature and capable of the lot.)
(Other benchmarks can be found here:
http://www.atl.external.lmco.com/projects/QoS/compare/dist_oo_compare_ipc.html
)

Some of these solutions are still subsets of the CORBA CDR. For
instance, Protocol Buffers don't include a standard way to specify
type information such as with the CORBA Any type or some of the
richness of ValueTypes. The W* approaches have to handle binary type
data (images, audio, video, large arrays) in special ways such as
base64 encoding or with attachments to the XML.

JacORB, MICO, TAO, OmniORB and associated vertical services such as
Naming, Notification, Event, Interface Repository are still being
actively maintained and are quite mature and reliable. As for
security, many of the implementations support SSH, password and
certificate based authentication/authorization as well. There are nice
bindings for Ruby, Tcl (Combat) and other scripting languages now as
well.

One argument that I've heard against CORBA is that it is only RPC,
which isn't quite correct. You can do messaging style communication
via the Notification and Event service and the Any type. If a simple
oneway was added to the receive method of the event services, they'd
be even more efficient and less "RPC".

I'd love to see incremental improvements in CORBA such as: a cleaner
Java bindings or a move towards a JAXB approach where the developer
can define his own local bindings; a standardized approach to
versioning such as with ICE's facets (SOAP still has trouble with
versioning as well, requiring best-practice approaches to deal with
it), more proliferation and refinement of the CORBA-reflection
feature. Its disappointing to see such a capable stack of technology
dumped, especially in exchange for other alternatives that haven't
quite measured up if you do a complete comparison of capabilities.
(The guys at ZeroC have done a great job with their ICE stack,
although I wish it was CDR compatible or standardized with multiple
implementations.)

I've also noticed that many developers slam CORBA who have never used
it! Its too bad that our industry is so driven by marketing, dogma and
folklore.

So the decision on a technology probably depends what your project
requires. If you need a rich high-performance horizontal and vertical
stack of services, CORBA is still a great cross-language solution as
far as I'm concerned.

Post by c***@sharklasers.com
It's been many years ago that I was using CORBA. 10 years ago I was
working on a large distribute system and at that time CORBA was quite
a hype.
Doing different things for quite a while now a new distributed system
shall be developed. Not having heard of any (really) good middleware
alternative I though of giving CORBA another try.
But there is not much news about CORBA in the magazins and there
aren't new books either. So somehow I have the feeling this technology
is vanishing. Well at least some implementations recently were updated
(omniORB) but others (mico) - well...
The systems we build have a rather long lifetime. So the technology we
gonna use must (1) be stable, (2) multi-platform and (3) still exist
tomorrow. So is CORBA still an option?
And what about ACE? There too isn't much news about ACE in the web.
Actually the only hits are wikipedia and Doug Schmidts homepage...

[Rob]

CORBA's momentum seemed to be systematically squashed by the Web
Services crowd who made claims that it was dead. (I usually interpret
claims
of a technology being dead as a sales pitch for some other
technology.) Ten years later, after amassing a large complex stack W*
specifications and implementations that still don't address all of the
CORBA's capabilities, the industry is moving towards other
fledgling solutions such as Google Protocol Buffers, Thrift, ICE and a
whole litany of other approaches to serialization:
https://github.com/eishay/jvm-serializers/wiki/. (ICE appears to be
the most mature and capable of the lot.)
(Other benchmarks can be found here:
http://www.atl.external.lmco.com/projects/QoS/compare/dist_oo_compare_ipc.html
)

Some of these solutions are still subsets of the CORBA CDR. For
instance, Protocol Buffers don't include a standard way to specify
type information such as with the CORBA Any type or some of the
richness of ValueTypes. The W* approaches have to handle binary type
data (images, audio, video, large arrays) in special ways such as
base64 encoding or with attachments to the XML.

JacORB, MICO, TAO, OmniORB and associated vertical services such as
Naming, Notification, Event, Interface Repository are still
being actively maintained and are quite mature and reliable. As for
security, many of the implementations support SSH, password and
certificate based authentication/authorization as well. There are nice
bindings for Ruby, Tcl (Combat) and other scripting languages
now as well.

One argument that I've heard against CORBA is that it is only RPC,
which isn't quite correct. You can do messaging style
communication via the Notification and Event service and the Any type.
If a simple oneway was added to the receive method of the
event services, they'd be even more efficient and less "RPC".

I'd love to see incremental improvements in CORBA such as: a cleaner
Java bindings or a move towards a JAXB approach where the
developer can define his own local bindings; a standardized approach
to versioning such as with ICE's facets (SOAP still has
trouble with versioning as well, requiring best-practice approaches to
deal with it), more proliferation and refinement of the
CORBA-reflection feature. Its disappointing to see such a capable
stack of technology dumped, especially in exchange for other
alternatives that haven't quite measured up if you do a complete
comparison of capabilities. (The guys at ZeroC have done a great
job with their ICE stack, although I wish it was CDR compatible or
standardized with multiple implementations.)

I've also noticed that many developers slam CORBA who have never used
it! Its too bad that our industry is so driven by marketing,
dogma and folklore.

So the decision on a technology probably depends what your project
requires. If you need a rich high-performance horizontal and
vertical stack of services, CORBA is still a great cross-language
solution as far as I'm concerned.

Post by c***@sharklasers.com
It's been many years ago that I was using CORBA. 10 years ago I was
working on a large distribute system and at that time CORBA was quite
a hype.
Doing different things for quite a while now a new distributed system
shall be developed. Not having heard of any (really) good middleware
alternative I though of giving CORBA another try.
But there is not much news about CORBA in the magazins and there
aren't new books either. So somehow I have the feeling this technology
is vanishing. Well at least some implementations recently were updated
(omniORB) but others (mico) - well...
The systems we build have a rather long lifetime. So the technology we
gonna use must (1) be stable, (2) multi-platform and (3) still exist
tomorrow. So is CORBA still an option?
And what about ACE? There too isn't much news about ACE in the web.
Actually the only hits are wikipedia and Doug Schmidts homepage...

[Rob]

Post by c***@sharklasers.com
It's been many years ago that I was using CORBA. 10 years ago I was
working on a large distribute system and at that time CORBA was quite
a hype.
Doing different things for quite a while now a new distributed system
shall be developed. Not having heard of any (really) good middleware
alternative I though of giving CORBA another try.
But there is not much news about CORBA in the magazins and there
aren't new books either. So somehow I have the feeling this technology
is vanishing. Well at least some implementations recently were updated
(omniORB) but others (mico) - well...
The systems we build have a rather long lifetime. So the technology we
gonna use must (1) be stable, (2) multi-platform and (3) still exist
tomorrow. So is CORBA still an option?
And what about ACE? There too isn't much news about ACE in the web.
Actually the only hits are wikipedia and Doug Schmidts homepage...

CORBA's momentum seemed to be systematically squashed by the Web
Services advocates who made claims that it was dead. (I usually
interpret claims
of a technology being dead as a sales pitch for some other
technology.) Ten years later, after amassing a large complex stack W*
specifications and implementations that still don't address all of the
CORBA's capabilities, the industry is moving towards other
fledgling solutions such as Google Protocol Buffers, Thrift, ICE and a
whole litany of other approaches to serialization:
https://github.com/eishay/jvm-serializers/wiki/. (ICE appears to be
the most mature and capable of the lot.)
(Other benchmarks can be found here:
http://www.atl.external.lmco.com/projects/QoS/compare/dist_oo_compare_ipc.html
)

Some of these solutions are still subsets of the CORBA CDR. For
instance, Protocol Buffers don't include a standard way to specify
type information such as with the CORBA Any type or some of the
richness of ValueTypes. The W* approaches have to handle binary type
data (images, audio, video, large arrays) in special ways such as
base64 encoding or with attachments to the XML.

JacORB, MICO, TAO, OmniORB and associated vertical services such as
Naming, Notification, Event, Interface Repository are still
being actively maintained and are quite mature and reliable. As for
security, many of the implementations support SSH, password and
certificate based authentication/authorization as well. There are nice
bindings for Ruby, Tcl (Combat) and other scripting languages
now as well.

One argument that I've heard against CORBA is that it is only RPC,
which isn't quite correct. You can do messaging style
communication via the Notification and Event service and the Any type.
If a simple oneway was added to the receive method of the
event services, they'd be even more efficient and less "RPC".

I'd love to see incremental improvements in CORBA such as: a cleaner
Java bindings or a move towards a JAXB approach where the
developer can define his own local bindings; a standardized approach
to versioning such as with ICE's facets (SOAP still has
trouble with versioning as well, requiring best-practice approaches to
deal with it), more proliferation and refinement of the
CORBA-reflection feature. Its disappointing to see such a capable
stack of technology dumped, especially in exchange for other
alternatives that haven't quite measured up if you do a complete
comparison of capabilities. (The guys at ZeroC have done a great
job with their ICE stack, although I wish it was CDR compatible or
standardized with multiple implementations.)

I've also noticed that many developers slam CORBA who have never used
it! Its too bad that our industry is so driven by marketing,
dogma and folklore.

So the decision on a technology probably depends what your project
requires. If you need a rich high-performance horizontal and
vertical stack of services, CORBA is still a great cross-language
solution as far as I'm concerned.

[Rob]

I apologize for the multiple postings. For some reason my posts were
not showing up in Google Groups and thought they got lost in
the Ether so I reposted them only to have them all show up two days
later in Google Groups!

(I'm in search for a decent NTTP service since Time Warner RoadRunner
ceased providing NNTP services awhile back unfortunately.)