Friday, July 6, 2001 03:28 AM
I guess that the answer to this question is, as Einstein put it, all relative :o)
CORBA is an architecture and under pretty much constant review. That fact alone would suggest that there have been, and will continue to be, areas for improvement. This is only natural.
But to go futher, if we compare CORBA with, say, EJB, we find that CORBA development might entail more architectural programming on the part of the developer than EJB development. Thus, in the EJB world things like persistence, for example, are managed by the application server, while use of CORBA generally entails the developers either hooking up to a custom persistence strategy, or 'rolling their own'. So CORBA development might be said to be 'harder' than EJB development.
Of course, things like persistence, transactionality, etc., are what the CORBAservices are meant to address. Thus there are standards defined by the OMG for transactionality, events, notifications, etc. It is probably a waste of effort to go looking for problems with CORBA and the CORBA services for its own sake. However, if we do so for the sake of argument, it might be said that the principal disadvantage is that they only represent a standard. As such it is up to individual vendors and ORB providers to implement them. This might give rise to a couple of effects.
- In the first place, CORBA services and most OMG standards result from OMG RFCs. In the early days of CORBA, when vendors were engaged in heavy competition to be compliant, and also to provide a better product than their competitors, it was typical for a vendor to produce a feature (let's say transactionality - though this may not be historically accurate) and then "apply" to the OMG to have this feature made part of the standard. This would leave their competitors playing catch up whilst advancing the standard. As vendors were producing products offering certain functionality BEFORE a standard was devised for that functionality, they had to either change their product or remain tied into the proprietary solution, depending on business factors. So did their clients.
- This leads to the next observation - CORBA defines a standard for interoperability, but in the early days vendor 'tweaks' on the standard might have caused incompatibilities between CORBA objects coded to different CORBA implementations.
- Moreover, if CORBA implementations are mainly commercial (and the big ones are) then what they implement depends on the market. So it's probably impossible to buy off the shelf a fully integrated solution offering all of the CORBA services and the ORB. (Indeed, it is arguable that no-one would ever want this anyway, so the point may be spurious...)
- Finally (for now) as the standard is being advanced on numerous fronts, according to the desires of numerous competitors, it is, as I have said above, in a state of flux. (Although what isn't?)
Really when looking at advantages/disadvantages of CORBA solutions it is necessary to have a set of requirements and constraints for a given project, and some knowledge of alternative solutions. If you are attempting distributed development between Java and C++, for example, CORBA might be considerably easier than RMI and JNI combined. If your delivery platform does not support application servers, you might be restricted to using CORBA. Equally, if there is no CORBA implementation for your delivery platform, obviously the arguments as to its advantages/disadvantages become moot. If all of your development is for a mainstream platform, and is all Java, an EJB application server might be a better solution. If your requirements are simpler, or your budget lower, RMI might be preferable to CORBA for distributed programming.
So essentially I have talked around your question without really nailing down an answer, simply because I don't think you can nail one down.
Despite this, I hope it helps...