A few tips on deciding between EJB and COM
An article by Ed Roman, CEO of The Middleware Company
Recently, there's been much said about Enterprise JavaBeans (EJB) and Microsoft's COM+ technologies. Some assert that EJB is new, and is therefore not ready for prime-time. Others question the historical scalability of Windows, and are uneasy about using Windows 2000 in their mission-critical deployments. So what's a development lead to do when deciding between these two environments?
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
In this article, I will raise some questions that you should be asking yourself to help you decide on the technology that's right for your business. This article will not answer all of your questions, but it will get you asking the right ones.
ISV or IT Shop?
An important question to ask yourself is: are you in the business of selling software to other companies, or do you host the software yourself?
For most companies that are selling software to other businesses, EJB is usually the pick of the litter. Why? Because EJB supports a heterogeneous deployment environment. Unless you can guarantee that every one of your customers will accept a Windows solution, you are restricting your salespeople from major accounts that may have UNIX or mainframe-based solutions. This is rarely acceptable at most ISVs. If you don't know what your customers are using, then talk to your salesforce and your consultants, and have them find out for you. Don't be shy -- the more data you have, the better.
If you're hosting software, then you control the deployment environment. That enables you to pick COM+ as well as EJB, and the playing ground is equal.
Existing developer skill-sets
What do your developers know today? Are they Java zealots, or C++ wizards? Do they have experience with MTS/COM+, EJB, or neither? This should certainly influence your purchase decision. After all, recruiting, hiring, training, and retaining employees is going to be your #1 problem, regardless of your industry. You can gain an immense amount of leverage by choosing a technology that is compatible with your developers' skill-sets.
Your choice of programming languages is absolutely critical to your choice of middleware. Why? Because EJB components must be written in Java, which requires a whole-hearted dedication to the Java programming language. If you are unwilling to commit to the Java programming language, then COM+ is a more attractive solution.
The opposite argument applies as well. If you are willing to bet on Java, then EJB is usually the best choice. If you recall, a recent court decision has undermined Microsoft's control of the Java platform. Because of this, Microsoft is developing new programming languages, such as COOL. While they may officially support Java, there are strong indications that they will have Java and Visual J++ on maintenance mode. If you want faith that your vendor will continue to strongly support the Java programming language, then EJB (and CORBA) are the least risky choices.
Features in the underlying middleware
Most comparisons of EJB and COM+ focus on a feature-for-feature comparison of the two platforms. These are all important differences, and you should weight each of these features as they apply to your business problem when making your architectural decision.
You should note, however, that real, successful E-Commerce systems are being developed today to both EJB and COM+. Despite the lack of support for certain features in each platform, today's development teams have learned to cope with some of the limitations of their chosen platform, such as lack of persistent components in COM+, or lack of queued components in EJB. It is very rare that an architectural decision will be made soley on the basis of features, as the two architectures are very, very similar. Rather, the overwhelming business forces at play are much greater factors.
Cost of systems
One great feature of Microsoft technology is they always seem to undercut the competition when it comes to price. Windows 2000 is no exception. There is a remarkably low cost per transaction in Windows 2000, and this stems from the volume pricing Microsoft employs. Furthermore, the COM+ subsystem ships with Windows 2000, whereas EJB-based application servers are sold separately from the underlying platform. When you couple low-cost Intel hardware with a Microsoft-based middleware solution, the cost per transaction is remarkably low.
The reader should note, however, that the cost of the underlying middleware, operating system, and hardware is always dwarfed by the total cost of ownership of a project. When you consider the cost of hiring, training, and retaining developers, the cost of developing and maintaining the solution, the potential lost business due to wrong architectural decisions, and the inertia of your decision over the years to come, the cost of the software and hardware are minimal.
Purchasing components vs. writing from scratch
One value of EJB and COM+ is they enable ISVs to ship applications as components. In the future, this will enable E-Commerce applications to be assembled in a piecemeal fashion from components specialized to their vertical market. This paradigm is much more appealing than writing applications from scratch, and is also superior to purchasing a proprietary, out-of-the-box commerce site that is not customizable. If new components are needed, the customer can craft their own, custom components as well.
Today, there aren't a whole lot of off-the-shelf server side components available. If, however, you do find a vendor with components in your vertical industry, then that becomes a compelling reason to choose their underlying supported middleware. A few web sites you may want to check for components include:
In summary, the decision between EJB and COM+ is a tough one, and this article is only meant to whet your appetite for the issues at hand. Chart 1 summarizes the differences between the two platforms.
|Java only||All (Java: unclear future)|
|Legacy Integration||RMI/JNI, CORBA, Connectors (future)||COM TI, MSMQ, OLE DB|
|Protocol||Any (future: IIOP)||DCOM|
|Middle-tier load balancing||Most vendors||Coming soon|
|Middle-tier data caching||Some vendors||No|
|Low cost per transaction||No||Yes|
|Middleware comes with OS||No||Yes|
|Per-machine processors||256+||16 (32 via OEMs)|
|Cluster-wide processors||Theoretically unlimited||Theoretically unlimited|
|Development tools||Choice of many||Microsoft Dev Studio|
If you want more information about how these technologies compare, check out a transcript from a debate I recently held with Roger Sessions (a COM+ evangelist) located at http://www.middleware-company.com/debate.html. For fellow technologists, if you want more information about how this middleware compares at a technical level, see my comparison whitepaper at TheServerSide.com resources section .
But in the end, remember this: both EJB and COM+ will be successful. This is not a zero-sum game, and there is no clear-cut winner at this point. Both will have their markets, and both are backed by strong, proven industry leaders. For those of you who wish to reduce your projects' risk levels when deciding between EJB and COM+, my advice is to make a judgment call, and then prototype a first-pass solution to test the viability of your chosen platform. Only then will you know if your chosen middleware meets your specific business needs.