Ejb Vs Com Plus

 Comparison of Sun's Enterprise Java Beans and MicroSoft's COM+ (or Microsoft Transaction Server / MTS):
(See Also DnaVsOo, DistributedInternetArchitecture)

There are several wonderful articles comparing EJB and COM+ on RogerSessions's site at http://www.objectwatch.com/past.htm

See EjbVsComPlusArticle.

More are at http://java.sun.com/products/ejb/ejbvscom.html (including Anne Thomas' Distributed Computing article from some time ago).

From the AnneThomas rebuttal of RogerSessions's critique in EjbVsComPlusArticle 21:

"It all comes down to your approach to application development. Roger is a believer in a database-oriented approach to application development. All persistent state should be maintained in a database. The database provides numerous invaluable services such as data integrity, transaction integrity, concurrency control, and access control. Applications manipulate data in the database. Any data that have been extracted from the database are potentially invalid because some other application might have changed them since they were retrieved."

"[...] But one size doesn't fit all. If your database design is relatively simple, and your applications tend to manipulate only one or two tables at a time, then the database-oriented approach is the right one for you. But in my experience, database designs are pretty complicated, and most applications need to manipulate multiple tables at once. These applications might do better using an object-oriented style of programming. Objects are richer than database tables. Objects maintain relationships with other objects. This relationship information is immediately available from an in-memory object graph. To obtain this same level of relationship information from a relational database, you would need to query the database and join a potentially horrendous number of tables. Entity beans allow you to maintain all of this information in memory, and the information is available to any number of clients. Accessing data from memory is much, much faster than accessing data from a database."

"[...] Not all object state necessarily comes directly from the database. Some state [...] might come from some other resource such as a data feed, a file, or a message queue. Sometimes the state comes from the user. EJB supports and maintains any type of state, regardless of its source."

"[...] Both EJB and COM+ support stateless operations, but only EJB provides automatic management of persistent state and longterm user session state. If you are building applications with complex data relationships, I think you'll appreciate the value of entity beans. COM+ doesn't give you these options."

"But if you're like a lot of people, and you prefer to develop applications using a stateless approach, then this argument is moot. Both COM+ and EJB provide equivalent stateless services. So it comes down to one simple decision point. Which is more important to you? Language independence or vendor/platform independence?"

I am very surprised with the topic that is being discussed. If there is a need for EJB or MTS, there is a need for a distributed environment. Why do you want a DOC environment? One of the reasons is to be open. Choosing MTS has nothing to do with this. Please don't let MS do it again! Secondly, MTS is about functions. You are creating a remote DLL with transaction support. If you want to add state MTS doesn't do its little trick. So choosing MTS will also bring you back to structured programming (Don't let Bill do this to us!). And yes, a lot of the remarks given are correct. EJB is very much focused on the Java platform, but what about MTS? And yes the same -problems- as Corba are there, but that's not what it is all about. It's about giving a solution to our customers, MS is not part of that.

-- RaphaelParree

EJB is the Sun equivalent of the MicrosoftTransactionServer. See a comparison favorable to MTS at http://www.microsoft.com/com/wpaper/mts-ejb.asp

Without knowing much about the MicrosoftTransactionServer I would like to question that they are equivalent. Are there any equivalence of entity beans in MTS? Are components portable across server boundaries? Is the communications layer made transparent to the components developer? Are there plans to standardize the server-container interface? [Yes, Yes, Yes and Yes. Read the article.]

Last year at the SIGS Java conference there was a panel debate between bigwigs at Sun and Microsoft about EJB and MTS. The most telling distinction was that EJB was a spec, and MTS was a product. That's no longer true. EJB allows multiple implementations and therefore more choice. MTS only supports COM and only runs on Microsoft platforms. MTS does not have the concept of a persistent entity bean. EJB supports any platform that supports Java. That's all I can remember right now.

So is interoperability the main problem with EJB? We've just started to evaluate EJB vs. MTS for our next project. The practical experience of others would be helpful. Interoperability may not be an issue for us because we'll probably be able to control the software on both sides to that extent. More of a concern is the language issue. Is it true that EJB can only be used with Java, as the Microsoft document says? My preliminary reading seems to indicate that EJB can bridge with CORBA, and hence to most anything.

If we don't mind being locked into one vendor's solution (be it Microsoft or one particular EJB implementation), if we might need to support clients written in more than one language, what's the best technical choice? That "EnterpriseJavaBeans has a long way to go to catch up to the features of COM/MTS and especially ComPlus" comment is rather cryptic. As someone else said, what does EJB need to do to catch up? Just fix implementation incompatibilities?

-- NathanUrban

Nathan, check out the RogerSessions URL above - should tell you a lot more than we can here. -- PeterMerel

I've done a little more reading and thinking, and right now this is the way it seems to me - strictly imho, take that grain of salt before you read further.

EJB isn't more or less complex than COM/DCOM/MTS. It is much less mature than COM/DCOM, but much more consistent than pre-COM+ MTS; it is much more mature than COM+. Like COM+, it can easily accommodate existing COM servers. COM+ seems like a great leap forward for MS, and it's fair to say it seems less complex than EJB, but it requires enterprises to roll out Windows 2000 in order to use it - not a trivial proposition for most of the market. EJB doesn't require that, so it seems like an easier path.

The choice then is far from cut and dried. The one thing you can't do, unfortunately, is stay with the existing MS toolset; when MS obsolete something, they stop supporting it entirely. Given this, I'd have a hard time recommending COM+ for enterprise apps right now. In a year's time, when some of the sharp edges have been knocked off the thing and people understand its performance and scaling qualities, it might be a better solution. By that time, though, I expect EJB to bridge to it/implement over it as well ... the beat goes on ... -- PeterMerel.

I'm not arguing that COM+ obsoletes COM. I said above, "Like COM+, [EJB] can easily accommodate existing COM servers." Source and binary compatibility are not in question. The pain is in deployment.

How much pain? For a large organization to consider rolling out Windows 2000 version 1.0 en masse, which they'd have to do to leverage COM+, will affect all of their deployed systems. Their administrators have to be retrained too. And since it's OS version 1.0, given MS past history, no one can expect the beast to perform well out of the box. Plus there's many 3rd-party entanglements to consider. This is hardly a rollout to consider lightly. [Your premise is false. COM+ does not require Windows 2000 everywhere; rather only on servers.]

What gets obsoleted isn't binaries, but toolset documentation and support. When VS6 came out, for example, all the VS5 documentation disappeared overnight. Poof, gone, buy the new toolset or die. If COM+ worked over NT4, that wouldn't be any kind of problem. Since it is coupled inextricably with W2K, however, it's something that will be daunting for many organizations. This, I think, makes EJB the better choice under many circumstances. But not all - like I said, this choice isn't cut and dried.

As to EJB consistency, I was under the impression that the holes were closed in version 1.1. If not I'm very interested in any pointers or examples.

As to choices, I have to say I mostly appreciate rather than deplore them. ComponentManagedPersistence, for example, seems just the ticket for writing agents that represent external devices. StatefulSessionBeans, for another, seems like a very nice way to bolt on connections to (non-enterprise)JavaBeans. Architecture is not yet a commodity, so we need these choices. --PeterMerel

Yes, many of the services that the ComPlus (COM+) runtime provides to COM components (objects) do overlap with existing EJB technology.

For Instance COM+ is:

However, most interesting is the ability to change COM+ container parameters (such as number of objects in the pool), at runtime for any object (and sometimes method) and hence almost facilitating the application of AspectOrientedProgramming (AOP) patterns.

--MatthewJamesEaslea

"What gets obsoleted isn't binaries, but toolset documentation and support. When VS6 came out, for example, all the VS5 documentation disappeared overnight. Poof, gone, buy the new toolset or die"

How do you figure? Of course, a new toolset would require new documentation! How else do you describe the new features?? How did the VB5 documentation disappear? Did someone steal it out of your cube? I know plenty of people still using VB5 or VB4 for that matter and they have their documentation and they get support from the MSDN phone lines. There is no-one forcing you to buy a new toolset. People buy something after an analysis of whether it will help them do things better. I'm at a loss at what you are talking about

All the service packs and post-.0 docs disappeared from the MS site. Perhaps you can still order them on CDROM; I don't know, but if you get good support from the MSDN phone lines you're doing better than anyone I know.

"How much pain? For a large organization to consider rolling out Windows 2000 version 1.0 en masse, which they'd have to do to leverage COM+, will affect all of their deployed systems. Their administrators have to be retrained too. And since it's OS version 1.0, given MS past history, no one can expect the beast to perform well out of the box. Plus there's many 3rd-party entanglements to consider. This is hardly a rollout to consider lightly."

I don't deny that MS learn from their mistakes, and I hope you're right and W2K is stable, but I think you'll still agree rolling it out on a large scale is not without the other risks I described.

Whatever, to be honest, I'm more interested in your EJB inconsistencies point. You've said a couple of times now you think this is a killer. Ignoring binary compatibility (byte-code compatibility is more than adequate for my purposes), what are these EjbInconsistencies? --Pete.

Comments refactored from WhyUseMicrosoftTransactionServer:

See following papers on limitations of EJB:

The interesting thing is that the above two papers were developed at least over one year ago. The Microsoft MTS/EJB whitepaper was published in July 1998, and Chappell's paper in November 1998. A lot has changed since then - IBM WebSphere and BEA WebLogic have grown up, J2EE has emerged, and MTS is now a part of COM+. Anybody have references on new comparison papers? -- PhilipEskelin

I don't think that any new comparisons have been done but DavidChappell did do a more recent piece at http://www.chappellassoc.com/art1cs.htm entitled "Application Servers: COM-Based vs. Java-Based." There is also his piece at http://www.entmag.com/displayarticle.asp?searchresult=1&ID=699912107PM entitled "Ninety Percent Pure Java."

The closest I have seen to a newer comparison is: COM/DCOM Wins CMP's "Well-Connected Award" http://www.networkcomputing.com/1010/1010f1win.html CMP's Network Computing magazine announced that Microsoft COM/DCOM won their "Well-Connected Award" in the Middleware Technology category. Contestants in this category included Enterprise JavaBeans (EJB) and CORBA. Also see the Microsoft press release about the award.

How much pain? For a large organization to consider rolling out Windows 2000 version 1.0 en masse, which they'd have to do to leverage COM+, will affect all of their deployed systems. Their administrators have to be retrained too.

What you say above isn't quite true. It is true that in order to use COM+, organizations will have to deploy COM+. But not en masse. The analogy is the EJB server - do you have to deploy Weblogic EJB Server to every desktop or even every server ("en masse") in order to build an EJB-based system somewhere in your network? Certainly not. You will access such an application system via HTML, JSP, Servlet; so all you need is a browser or other http-enabled client on the desktops. The WebLogic server is deployed near the data. Likewise for COM+ and Windows DNA, substituting ASP for JSP. COM+ and Windows2000 must be deployed on the server side, presumably near the data. Clients can continue to use whatever they wish to access it, including http running on a Linux box. Clients can also access via old-style COM; for example, a Win98 client may invoke a server running in COM+/Win2000 via COM. The client need not do anything special to invoke the COM+-contained logic.

Granted retraining will be necessary, but that is the case with any new technology, including EJB, COM+, Wiki, etc. -- DinoChiesa

There is a difference between deploying an EJB server and COM+ ... COM+ requires a new operating system. This operating system has new ways of doing things and some of these are incompatible with the previous operating system. An EJB server is an application you can deploy to your existing infrastructure. -- RichardColley

You haven't made a good point. This "new operating system", meaning Windows 2000, certainly does things that are different than other OS's, including NT4, Solaris6, 7, or Redhat6.2. But what do you mean by "incompatible"? Installing a W2000 box in your corp network doesn't make the network cables start to smoke, if that's what you mean. In the same way, I wouldn't suppose starting an EJB server somewhere in your network would cause perdition, either. So what is your point, exactly, Richard?

Running COM+ requires W2000 on the server. It requires training in the details of how to manage COM+. But running EJB requires ... a new EJB server - presumably it is a product you did not have installed in your network previously. And it will require training in the details of how to manage the app server. Yes, your EJB server may run on an existing machine, with its existing OS. But...is that a key business benefit?

Not-trying-to-be-dim-witted-but-I-just-don't-get-it-ly yrs,

-- DinoChiesa

Well, yes, it is a business benefit, because managing an EJB server is about as hard as managing "yet another daemon" on a UNIX machine. Not very difficult for most sys admins. Of course, some EJB servers are complex enough to require a DBA to administer it. Dozens of WebLogic servers hum along for months on our Sun Enterprise 4500s and 10ks without a hitch. -- StuCharlton

But the initial investment in time and money is just as large. It is *not* just a deamon. It is almost an OS. Going from NT to Win2K is minimal once you know one. I used Bea WebLogic and it was a huge investment for me to learn it, install it, and manage it.

[Restarting part of this thread to communicate more clearly, which I don't think I was doing earlier...]

Ignoring the OS side of things, I contend that WebLogic has relatively easy setup and administration features, based on my anecdotal experience in dealing with several Windows and UNIX administration groups. This is to contrast your anecdotal experience with WebLogic, which I found to be somewhat surprising as it contradicts my experience. I'm interested in learning more.

I also think that IIS & COM+ have relatively easy setup and administration features. EJB and COM+ both offer very similar feature sets. I don't think it's fair to say that EJB would be "more difficult", which Dino implies above, in installation, maintenance, and training, because I think a Windows administrator would require training on basic COM+ administration concepts when such a system is deployed.-- StuCharlton

In general experience I've seen developers do the configuration and deployment of components more than administrators, for both COM+ and EJB. Administrators mainly make sure things are still "running". Separating the role of the developer from the deployer has been one of the goals of component technology, and I think we're getting there, just not quite yet.

At least what administrators have been able to do with an EJB server, in my experience, is to troubleshoot problem logs fairly easily, and tweak database connection pools or message bus connections if need be. A more complex server like GemStone (which is like an object database) needs a DBA. -- sc

Moved from ComPlus...

Well, this is all lovely and very exciting, but yours-truly was premature declaring the game over. Check out RogerSessions's comparison of COM+ with the EJB 1.1 spec at http://www.objectwatch.com/past.htm. Life is about to get weirder. -- PeterMerel

Well, before reading on, keep this in mind: RogerSessions doesn't have a clue (or doesn't want to have one). In all his newsletters he confuses specs and implementations. In EJB connection pooling, instance pooling, load balancing, caching, distribution, ... are left to the implementation. So you think about your project, write down the requirements and then choose an appropriate EJB server which implements the desired features. He also has no clue about the specs. He is confused about EJB Beans, EJBObject, Session/Entity Beans and BMP/CMP.

See http://wwwzenger.informatik.tu-muenchen.de/persons/backscha/ejbsig/archive/ejb_interest_08_1999/msg00433.html

-- StephanSchmidt

Well, this is all lovely and very exciting, but yours-truly was premature declaring the game over. Check out RogerSessions's comparison of COM+ with the EJB 1.1 spec at http://www.objectwatch.com/past.htm. Life is about to get weirder. -- PeterMerel

I'd take what RogerSessions says with a grain of salt. He seems to know much more about COM than EJB. As such, some of his opinions are biased because of lack of knowledge (for that matter, who's aren't?). -- HankRoark

Do you have any specific qualms with what he's saying? Where does he go wrong?

In ObjectWatch? Newsletter Number 18, the article titled SCALABILITY IN EJB AND MTS, Roger discusses the different instance management algorithms used my MTS and EJB. He describes MTS's algorithm as JustInTimeActivation? (JITA). From his description, JITA means that MTS "instantiates a local instance of the appropriate component just-in-time to receive the request." In order to scale/perform, MTS uses database pooling. Compare that with what Sessions says EJB does: EJB uses instance pooling. This means that the component instances are pooled, not the database connections. Since instances have a connection to the database, then the overhead of database connections is not realized in EJB. He then goes on to say both have benefits and drawbacks. Also, he says the idea solution would be to support instance and database-connection pooling.

So ... this sounds about right, no?

So, that is what Sessions says. I've looked over the EJB spec and I can't find a place where IP, not database connection pooling is specified. I think this is dependent on the implementation, right? (If I'm wrong on this, please let me know where I can find it in the EJB 1.0 and/or 1.1 spec.)

I'm just getting up to speed with the specs, though this sounds like what I've heard so far; Sessions goes into a lot more detail relevant to EjbVsComPlus with newsletters 20-20d. How do those strike you?

Like I said, I couldn't find instance pooling in the EJB spec. I think Sessions is confusing this with how some EJB servers are implemented. Since I haven't implemented an EJB server, I'm may way off base on this. But it certainly couldn't be too much of a leap to imagine an EJB server implementation with both instance and database pooling -- hr

I've only looked at 20 and 20a of the news letters. The comments at the beginning of 20 about EJB being like a server side JavaOS and how the JavaOS has failed rub me the wrong way. It's like he is saying EJB will fail because JavaOS failed because EJB is really just a server side JavaOS. Also, the overall tone of story of Bernice implementing an entity EJB reminds me of someone wanting to make EJB look difficult. In essence, the overall to tone of this newsletters seemed very biased toward COM/COM+ and hence seem like a poor place to get one's EJB vs. COM+ information. -- hr

Also, I cannot find the quote given by Sessions, from Microsoft, attributed to http://www.microsoft.com/com/wpaper/mts-ejb.asp, that states the following: "Enterprise JavaBeans doesn't define any specific mechanism for pooling and reusing database connections. An Enterprise JavaBeans application deployed on Windows NT can use the ODBC resource manager to pool connections just as a MTS application would because this service isn't specifically tied to MTS. But what about Enterprise JavaBeans applications deployed on other systems? Unless those systems have some way to efficiently share database connections, one of the primary benefits of a three-tiered architecture is lost. The Enterprise JavaBeans specification is silent about how this should be done."

So, with that said, I say be careful of his newsletters. -- HankRoark

I don't see that there either, but fwiw I have noticed MS morphing their white papers without notifying anyone. Certainly if they ever did say that the point seems very weak. Pooling database connections in a component is not voodoo. I think the MS paper shows a lot of nerve complaining about complexity too! -- PeterMerel Good point at MS and their site. I wonder why MS removed this comment from their white paper? -- hr

I cannot see that it is game over yet. Looking at the claims for "COM+", I was reminded of the capabilities that used to exist within the Digital/VMS world.

VMS did not mean GameOver for the Unix world. Windows2000 will have some impact if it can run on the middle tier boxes, but until it scales well enough to support midrange boxes the jury is still out. My fear right now is that to do this Windows 2000 will force the desktop to be a midrange box :-)

-- PeteMcBreen

"I cannot see that it is game over yet. Looking at the claims for COM+, I was reminded of the capabilities that used to exist within the Digital/VMS world." -- Of course it does -- most of the Microsoft Engineers who wrote Windows NT (aka 2000) are old DEC VMS engineers!

CategoryEjb CategoryMicrosoft

EditText of this page (last edited July 27, 2008) or FindPage with title or text search