Interoperation: modes and benefits

One of the application used in our company uses CORBA. The CORBA server side runs on AIX. Currently we are planning to upgrade our AIX version, and run into the issue that the new version of AIX does not support the version of CORBA implementation we use, so we need to decide the fate of that application. Interoperate then becomes part of this thinking process. In this meditation, I am looking at interoperate from a broader view, which includes one-way "inter"operate, and I am interested in discussing different ways of interoperation I see, and I am very interested in other's views.

One way interoperate that is defined between specific languages. A good example is perl calling inline c. Another example is c calling Java through JINI (although Java can call c, but it calls through very different method under the JINI roof). This type of interoperate exists for various narrow purposes. JINI exists to provide a way for legacy c programs to interoperate with new Java modules, and one reason for inline c to be embeded in Perl is to gain performance without losing Perl's rich functionality and quick development support.
One way operation that is commonly available to multiple host languages. One example is DLL. Once a piece of program is compiled into DLL, it can be accessed from Perl through modules like Win32::API, or through Java via the other half of JINI. Another example is stored procedures in database, for example those PL/SQL programs in ORACLE. One major difference between this type of interoperation and the above first one is the commonality it provides.

One of the major benefits of this type of interoperation is that, in a way, it increases the reusability of your code and potentially increases its life span. When your application move to a new host language, very likely, those functionality provided through things like DLL and PL/SQL can still be reused.
The real two way interoperation like what is provided through CORBA or SOAP. This type of interoperation are usually more complex than the first two types. One source of the compelxity comes from the architecture, however on the other hand, the complexity introduced can be reduced through common modules that wrap the common components or functionalities of the architecture (so that the complex architecture becomes a set of modules that are not so complex).

It is quite interesting to see how CORBA was replaced by SOAP (I am ignoring the details like whether SOAP is the counterpart of CORBA, or IIOP), and didn't get spreaded too far for too long. Although there are some technical reasons behind CORBA's fading glory, CORBA is mainly killed by the major players in the industry, and CORBA is not the only vistim of this type. Big players often manipulate the trend or "fashion".

2005-09-25 Retitled by Arunbear, as per Monastery guidelines
Original title: 'Interoperate'

Comment on Interoperation: modes and benefits

Replies are listed 'Best First'.
Re: Interoperation: modes and benefits by rvosa (Curate) on Sep 25, 2005 at 12:04 UTC
I am curious why it is (in your opinion) that the major players want to replace CORBA with SOAP, when the latter seems less scaleable?	[reply]
Re^2: Interoperation: modes and benefits by tilly (Archbishop) on Sep 26, 2005 at 00:16 UTC
The cynical side of me says that it is a plot to sell hardware to people who otherwise wouldn't buy it. The more honest and even more cynical side of me says that vendors are under more pressure to deliver buzzword compliant products than they are good ones, because PHBs are better at recognizing buzzwords than quality. Therefore SOAP is better than CORBA because it is a newer buzzword, and also allows them to use the XML buzzword along with all of the attendant marketing-speak.	[reply]
Re^2: Interoperation: modes and benefits by adrianh (Chancellor) on Sep 26, 2005 at 11:29 UTC
I am curious why it is (in your opinion) that the major players want to replace CORBA with SOAP, when the latter seems less scaleable? One reason is that SOAP is scalable enough for many people. With organisations introducing web infrastructure for other reasons supporting two mechanisms (or, if they've never had CORBA in the first place, introducing a new one) can be a waste.	[reply]