I am doing evaluation for a new system and thinking of CORBA and EJB technologies. Some of the main differences i found are: 1. EJB container provides integrated services such as Transactions,Security, Persistence..etc, where as in CORBA one needs to code for them. 2. CORBA is platform independent and language independent, while EJB is platform independent. 3. CORBA is a more realiable and established technology compared to EJB. 4. CORBA is more expensive and time consuming to build vs. EJB. 5. CORBA supports full multi-threading, where as EJB does serialization on calls to EntityBeans. If anyone has any other inputs, please share them with me. Thanks. -Hemanth
Some thoughts for you to consider, in response to your specific points. 1. Not necessarily true regarding what CORBA requires you to code. True, the intent of the EJB spec, and therefore an implementation of the spec (an EJB container), is to provide infrastructure on behalf of the bean developer so that the bean developer doesn't have to "reinvent the wheel" so to speak regarding infrastructural (multithreading, persistence, transactions, etc.) software. There has been a movement within the OMG to embrace the ideas presented by the EJB specification. The intent of that movement was to provide infrastructure components in the CORBA world similar to what is provided in the EJB world. I haven't checked on the progress of that OMG effort in at least 12 months though. 2. EJB can be thought of as being language independent as well, when you consider that the EJB spec was written to provide access to EJB deployed JavaBeans through EITHER RMI or CORBA, with RMI being of course the default mechanism. 3. CORBA may be slightly more mature than EJB in that CORBA has been around longer. Probably a bit of a stretch to state that EJB is less reliable than CORBA though. 4. May be tough to prove this, especially in light of the OMG's movement to embrace the ideas of the EJB specification. Check into where the OMG is on their EJB like component model, and how the ORB vendors are choosing to implement it, if at all. 5. Seems like an apples (CORBA - MT) to oranges (EJB - persistence) comparison on this point. The EJB spec calls for full MT support as well, as I recall. There is one other point to me that is paramount here. The efforts of the OMG revolve around the reduction of proprietary interfaces, which the EJB spec cannot itself address. The OMG has a process in place for adopting and implementing "standard" technology, which goes beyond the simple plumbing and such provided by an ORB vendor. This process also embraces standards within vertical domains (e.g. Telco, Finance, etc.) as well. The idea here being that if you as a consumer of software components, purchase a software component that lives up to an OMG standard, your cost of ownership is reduced, since you should be able to dismiss that product in favor of another product which implements to the same IDL interface. This point does not appear to be addressed at all by the EJB community, as I have seen it thus far. Not to discredit the efforts by the EJB community, as I certainly believe in their efforts, but I personally would like to see efforts taken so that we all can purchase software off the shelf with this notion of reduced cost of ownership. I don't like being held at bay by the likes of the Microsoft's of the world. I went off on a bit of a rant there. Hope this helps nonetheless.