Java开发网 - A few tips on deciding between EJB and COM

Java开发网

您没有登录

» Java开发网 » Java EE 综合讨论区

打印话题 寄给朋友 订阅主题

作者

A few tips on deciding between EJB and COM

palatum

CJSDN高级会员

发贴: 451
积分: 80

于 2002-11-18 12:52

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?

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.

Embracing Java

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:

http://www.flashline.com
http://www.componentsource.com

Summary

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.

Feature EJB COM+
Component Language
Java only All (Java: unclear future)
Platforms All Windows 2000
Middleware Vendors 30+ Microsoft
Legacy Integration RMI/JNI, CORBA, Connectors (future) COM TI, MSMQ, OLE DB
Protocol Any (future: IIOP) DCOM
Stateless components Yes Yes
Stateful components Yes No
Persistent components Yes No
Method-granularity transactions Yes No
Middle-tier load balancing Most vendors Coming soon
Middle-tier data caching Some vendors No
Queued components No Yes
Single-vendor solution No Yes
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.

话题树型展开

人气	标题	作者	字数	发贴时间
4426	A few tips on deciding between EJB and COM	palatum	7976	2002-11-18 12:52

已读帖子

新的帖子

被删除的帖子