CORBA / IIOP is somehow negatively associated. This is caused probably by too many ambitious and mostly inefficient "enterprise" projects several years ago. CORBA was no only used as a protocol, but was extended to specific domains (domain facilities) and components (CORBA Component Model). Because of the mistakes in the past, many developers associate CORBA with inefficiency. The effect: IIOP almost completely disappeared from the enterprise space (it was even "forgotten" in the EJB 3.0 spec) and re-appeared in ...embedded projects. CORBA is really popular in the embedded area because of its efficiency (:-)) and interoperability.
In my last three projects, we relied on CORBA, as a co-accident:
- We had to optimize SOAP and got rid of it :-). We used .net-iiop instead (a great opensource framework). We could increase the performance significantly.
- We used IIOP as a lightweight and portable (appserver-independent) callback mechanism. In this case we replaced JMS with CORBA.
- XA-transactions mostly rely on OTS (object transaction service), and so CORBA...
- EJB 2 used RMI-IIOP as default communication-mechanism. It worked really well - they were no problems, at least not in the communication layer :-)
IIOP can be really efficient and easy to develop and to use. The IDL definition is somehow tedious, but it could be easily replaced with annotated interfaces (this is actually a great idea for an open source project :-)). Then we could introduce a new acronym: POCO - it would stand for Plain Old Corba Object :-)
IIOP would be (actually is) a great extension for the "Consumer JRE" and so for desktop applications.