EJB vs Spring

[Stan Sokolov]

Guys,
does it has any sense to start use EJB session beans rather then use Spring framework. I have work a lot with session EJBs. I could not say that technology is bad but development not easy because running application server on development workstation is slow. EJB container is necessary to be started even if you want to debug a simple batch process that contains interaction of more then one stateless beans. We are using Hibernate as a persistent framework. I know Spring has a good Hibernate integration it also supports bean's pooling. So can somebody says me if there are scenarios when using of EJBs is still a right choice or EJB is just an outdated technology that should be avoided?

[Valentin Tanase]

Hi Stas,

Hi,

Try this one http://www-128.ibm.com/developerworks/library/ibm-ejb
As for the EJB technology itself is not outdated, only the current release is :-) It also has the bad reputation that it will be revisited for the third time in only few years and it won�t be much compatible with the current one. This is one of the many reasons why all this open source tools gained so much popularity. Whether they will win the market again the big guys I really doubt it, but if you have to develop a new project I would rather go with Spring and Hibernate rather than EJB 2.0.
Regards.

[Balamaci Serban]

I don;t know how much of this i can take. I am really going to a phase of really just hateing java. I went for java not too long ago. The language itself, more than a year, i quite disliked it. Belive it or not, i was really enjoying the pointers in C++. Then not too long ago, mostly the time i registered on the forum, i got me a book on databases, curse the day that i did , and it had a nice picture of EJB. It talked about easying the developement. We all know how big of a lie is that.
We come to the point of App Servers. (I am currently unemployed, looking for work, guess i would settle at 400E if i am lucky to get a job anyway as i have not yet participated on any big projects as required). So what would my next employer use as an app server: WebSphere, WebLogic, JBoss also the Spring framework maybe, others...? How about the clients? Guess i will have to learn to swimm in at least 2-3. Ok let's talk about EJB and bang the J2EE a little later.

EJB really made sense for me back then. Actually no, when they talked about entity beans. The ORM mapping seemed some theoretical fad for book writters and pattern designers. Not good old sql where u can control every tinny inch of what's going on the low level database. Well i finnally got it after some time. Te answer is cache. Entity beans means data ready in the same process as the application. Not abideing by the rule that on every call of a method of the bean the container does an ejbLoad to read from the database and actually serving it from what was left in the memory from serving another user's call without doing an inter process communication with the database would really show some improvements. Granted that, but the programing overhead is a killer. They moved away from the SQL and we got a whole bigger package the EJB-QL and of course the SO MUCH HATTED BY ME XML. Everything is in xml. Whole pages of code. There is not that much java left as there is XML. Pretty soom everyone will know XML tags better that java classes. Every container with it's plus XML descr. of course. XML for servlets, tag libraries, for session, entity, message beans. How about the mappings of hibernate- come on...- Spring it seems i will have to learn, can;t coment on that i haven't got to that part yet. More XML right?
Entity Beans means you are no more tied to a particular database. Yeah right. Like i would just go in the middle of the project : Hey this database really is crap, let;s change to MS SQL or better yet lets do ORACLE.
Hibernate gives u more control, but it's much more harder to learn. With EJB you don't optimise at the database level, u don;t care if the data is in a normal form or not, you just need to think how would it fit more your object design. You wanted to have a separate a table with cities name, and pass the city id in the Person table an id to that. No more, that would mean you would have to create a Cities object and set a relationship with that also. More easily to just put the city name as a String in the Person table.

Session Beans, well they're good for mostly one thing i guess. Distributed transactions and implementing the bussiness logic at the middle level in case of another type of client besides the web tier. Anyone can think of another use for them ?
Sure the resource pooling seems nice in theory, i can;t confirm in practice.
More about descriptors now There is no problem. We have tools for descriptors generation. And IDEs. Yeah, another problem. Best IDE i've work was Intellij IDEA, only 500$(got the crack for it, of course, 500$ that's like 5 months rent for me, i;m not that stupid). More likely the companies i guess they work with Eclipse or with some Aplication Server project designer. And for Eclipse be prepared to spend some time just fixing and finding a colection of plugins that barely do the job done. And be prepared to write some descriptors by hand. For most of them, Eclipse will of course sugest the keywords for you, but not offer some graphical tool to just set the parameters, or an already configured example. No, that would be too easy. And of course, learn Ant, which is in itself a new language.
Why this seemed like a good solution? What chance do we have against .NET? Well for me something on the serverside that was supposed to run on Windows....... hmmmm........ hmmm...... bad idea i said back then. But what do u know? The Java JVM seems it's not the optimal one for linux, and the Aplication Servers run on Windows. SAY WHAT??? So we're competing with a tehnology that can and probably uses native code. Windows became more stable and there seem to be not that many patches coming up every day. So the .NET have on us the following advantages. Only one AS, u just learn that to the bone, just one IDE, and that IDE is all everyone has, and you can be as productive as anyone. Just concentrate on the bussiness developement.(the EJB motto, how funny that sounds ) That one stuff for microsoft means everyone is ussing that and so more tutorials, more people out who may have encountered your problem. The cost u say.... The most expensive asset in a company are the employs. Investment in tehnology and hardware is one time only or at least, not every month anyway. And how about the GUI Interface. That;s mostly crap in Java and a web based IDE is not enough. Most users care how theyr GUI looks and how they can interact with it.
Ok enough writting. It went away from the subject. Sorry, i should have started a new thread. On the other hand there is PHP just to take care of JSP. Most web pages just need to pull something from the database. Simplicity in it;s purrest form. You don;t get to cache at the middle tier, granted the transaction support is lacking, but...
So does anyone have the same fear that J2EE will have maybe not such a slow death?
[ July 18, 2005: Message edited by: Balamaci Serban ]

[Valentin Tanase]

Hi Serban,

Welcome to J2EE world! I mostly agree with you, I�m in the same boat, developing apps using a technology that I have no much admiration for. Unlike you, I�m doing this for a while and I feel frustrated to see so many software crap promoted every day. To your list add Struts please, which is one which I dislike probably the most. On the other hand I have to say that I take the whole advantage of this complicated and cumbersome technology, because I can develop this crap making pretty good money. People are realizing that they need at least couple of skilful developers for each project and they are still willing to pay good money for that. So far this is the biggest advantage of using J2EE (from a developer perspective of course).
As a matter of fact I�ll do one step further and I�d like you to think about application servers. Take WebLogic for example. WebLogic is more than an entire industry by itself. Now let�s see what is all this complication for: basically to display dynamic content to a browser client ?! All the �great� arguments that J2EE brings, like middleware components, instance pooling, design patterns, best practices, etc. are only propaganda and nothing else. In my opinion the web server & app server & � they all should be part of the operating system. Whether this OS components use EJBs or not in order to process http input doesn�t matter at all. It is just a black box that has an interface with the users. All it matters is that every developer can write a very simple server-based application using any basic programming language and making basic OS calls. For example AS400 developers should be able to write a "middleware" using RPG. But of course that also means that it would be no market for WebSphere, WebLogic, Resin, etc. All J2EE developers will go out of job as well and basically nobody will benefit out of this. Just another paradox of the way this world works: a good think by its nature will actually have only bad consequences for everyone.
Bottom line is that whether we like it or not, we have to keep �loving� it and this for the sake of each and every one of us. This is also the reason why I strongly believe that J2EE & Java won�t go out of business so soon. Things will change here there, but the big guys and the big money will always be there. Can you see BEA, IBM, Sun, etc. just stepping aside and saying: "hey, we were all wrong, please accept our apologizes, we feel sorry and we just cannot take your money anymore" Can you see this happening? So enjoy life, be pragmatic and just take as much you as you can from what�s giving. They make money, we make money and everyone is happy.
Regards.

[Stan Sokolov]

Guys,
do not simplificate the J2EE. From my standpoint J2EE is perfectly separate UI and backend development and offers some generic ways to solve typical tasks that developers face during development. Design patterns and tachnologies choices are up to developers and actually I completely agree that struts is a piece of crap, specially when you start to try yse its internatiolization ability that in fact are just a disability. But in general Java is a right choice of business component development. I like C++. But speaking frankly this is not a language to build up unexpensive business-oriented solution because C++ needs skills that often not available offshore. In turn Java and .NET are much broader available on US local and offshore market. So why business should not utilize this advantage ? Weblogic and Websphere are monsters - no doubts but open source tomcat that my company uses is simple as a wood brick and suitable for even big comercial application.

[Valentin Tanase]

Hi Stas,

Thank you for your reply.
I�m not trying to simplify J2EE and I agree there are still plenty good design ideas and technologies within J2EE. JSPs, servlets, JDBC, etc are only few examples. Just for the argument sake let�s focus on those that are far from being that great and let�s try to analyze the impact they have on J2EE community: EJBs. Let�s do a simple recap:

EJB1.0: RMI calls although the beans were located within the same JVM (no silly local interfaces). How could SUN even think that this is going to work, for building enterprise, highly scalable and mission critical application and system? Why IBM, BEA, etc did not say a word after reviewing the specs? Didn�t they have engineers capable of figuring this out before releasing the product?

Those ser files made deployment horrible despite all tools available at that time. In �99 I got the opportunity to take training in Bangalore/India. We were there over 50 engineers and many of us had good OO experience in both Java and C++. At the end of the training the teacher gave us one week to finish a small project involving EJBs. The result: only 5 of us were able to finish (in a week!) that small project. If SUN would fairly conduct such a test on a small population of average engineer they would understand that their technology is not going to honor any of the promises they did in the first place.

EJB2.0. Entity CMP: every transaction starts with running ejbLoad at the beginning of the transaction and ejbStore before completion. The result: no way to cache the data between transactions. How can one deliver a highly available system without any data caching?

Entity BMP: the n+1 selects problem says more than I can say. The result: people need to use straight JDBC or to seek vendor specific solutions.

Instance pooling: in theory sounds great and it adds a lot of �weight� to EJB technology. In practice it doesn�t add many benefits though. With the very powerful garbage collection algorithms these days, the other alternative of creating/removing new/old bean instances on demand it�s also a great choice.

Transactions: the container rolls back a transaction automatically only when the application throws a system exception. Whatever the reason behind this is really confusing and doesn�t make much sense, especially with CMP.

Local interfaces: what for?

Designing: having some type of beans that models the business logic and other type of beans that represent the data model is far from being a dazzling designing choice.

Clustering: great idea, but cluster-aware stubs are almost useless in practice. Mostly the clients either use the local interfaces or the container will do lot of optimization for collocated ejb objects, ignoring the stub�s load balancing algorithm.

And the list can grow. The result of all of this is that the there is a growing uneasy feeling inside the J2EE community about most �dazzling� of SUN�s technology. Managers tend to turn their attention back to web-centric applications and feel more confident employing open source technologies like Spring or Hibernate. The company I work for used to be an EJB/Weblogic workshop. They are not to be blamed, since we did everything we could to see the technology working. Today we�re using Jboss/Tomcat, Spring, Hibernate, SiteMash, etc. Only open source software as you can see. They are all great technologies and bright ideas, but unfortunately they are not the kind of technologies I�d like to be an expert in. Whether I�m right or wrong it�s not the point; the point is that SUN defamed its own technology beyond the point where it could be an attractive option. Personally I�m just a spectator that has to switch gears again and learn whatever technologies make the market today. Honestly I got tired of doing this.
Now do you understand my frustration?
Regards.

[Stan Sokolov]

# EJB1.0: RMI calls although the beans were located within the same JVM (no silly local interfaces). How could SUN even think that this is going to work, for building enterprise, highly scalable and mission critical application and system? Why IBM, BEA, etc did not say a word after reviewing the specs? Didn�t they have engineers capable of figuring this out before releasing the product?
1. Business man
2. I worked in IBM before then EJB has come to the picture. IBM used home-grown "persistence builder". Comparing to "persistence builder" EJB is a lightweight, easy maintained choice. It was time when no hibernate no spirng were available. People put everything within one servlet using "Magic servlet" anti-pattern. So for this time EJB probably was a right initiative.

# Those ser files made deployment horrible despite all tools available at that time. In �99 I got the opportunity to take training in Bangalore/India. We were there over 50 engineers and many of us had good OO experience in both Java and C++. At the end of the training the teacher gave us one week to finish a small project involving EJBs. The result: only 5 of us were able to finish (in a week!) that small project. If SUN would fairly conduct such a test on a small population of average engineer they would understand that their technology is not going to honor any of the promises they did in the first place.
Again comparing "persistence builder" it was not a bad result :-)

# EJB2.0. Entity CMP: every transaction starts with running ejbLoad at the beginning of the transaction and ejbStore before completion. The result: no way to cache the data between transactions. How can one deliver a highly available system without any data caching?
- As far as I know this is very configurable at least on websphere. If you do not have a cluster and there is no chance that DB is accessed by third party process you do not need obligate a container re-read the date before/after transaction. So cashing should work.



# Instance pooling: in theory sounds great and it adds a lot of �weight� to EJB technology. In practice it doesn�t add many benefits though. With the very powerful garbage collection algorithms these days, the other alternative of creating/removing new/old bean instances on demand it�s also a great choice.
I have seem "The Middleware" perfomance tests dated on 2002. EJB session facades/CMP entity together outpeformed plain JDBC and almost reached platform specific .NET solutions. From another turn CMP mapping is a pain in the ... . Hibernate mapping is much more simple and elegant. That why I am using Hibernate now.

# Transactions: the container rolls back a transaction automatically only when the application throws a system exception. Whatever the reason behind this is really confusing and doesn�t make much sense, especially with CMP.
Hmm. I am using the same pattern when devepoping my non/EJB based solution. My own context using the same way to determine if transaction should be commited or rolled back. Business code is not commiting or rolling back. Business code has to throw an exception in case of failure. Btw this is a greatest thing that I like about EJB - container managed transaction. When I used EJB it was a real pleasure to use it. But debugging Session beans is not easy - you have to run an app.server first. What is time consuming and needs a server-class workstation. Spring is might more resource-wise unexpensive solution. But from my opinion. Once you start to use SPRING holoywood-principe of the application design you won't be able to swith to something else leter.


# Local interfaces: what for?
Just to don't have all this mess with COBRA. I have no idea why SUN has decided that somebody even needs this RMI/COBRA based EJB. I will not be surprised if EJB 3.0 will not have any relations neither to COBRA nor RMI

[Roger Chung-Wee]

For me, the most compelling reasons for using an EJB server are transactions (especially CMT) and - not even mentioned so far - messaging. I have little doubt that JMS is a success: if I were to develop an application which needs messaging, I would look no further than EJB technology.

There are other, not so obvious reasons why one would use a J2EE server. I work for a big corporate and I'm sure that Spring and/or Hibernate would be unwelcome. These products may be better in some respects than what we use, but you have to look at the overall picture. We do all J2EE development using WebLogic Server. Some of our apps are tiny, some are huge. It doesn't matter if it's EJB or just JSPs and servlets. We are also heavily into Web Services. I must say our architecture is quite complex, though. In such a situation, it makes sense from a development, production and cost point of view to standardise on one, heavyweight server which meets all our needs.

Oh, I've just remembered something else: support. Our big, and many not so big, apps need support. I don't know if we still do it, but for years we had a support contract with BEA. You have to bear in mind that this is essential: no corporate is going to sign a contract for an important product which does not have guaranteed support.

[Valentin Tanase]

Stas and Roger,

Thank you for sharing your thoughts.
Other opinions will be welcomed too.

I work for a big corporate and I'm sure that Spring and/or Hibernate would be unwelcome.

Lucky you :-)
Regards.

[Venkat Thiru]

J2EE/EJBs are bundled with services. And, may be one in 100 scenarios you will change your architecture after designing the project(unless you work for a dynamic small business). If your architecture is not changing you can trade-off your object/service coupling to an extent and gain the power of distributed computing.

Spring is a good framework but does not provide all the services that are required foro project development. Transaction service, go find JTA etc., Data access, go find hibernate/iBatis etc., presentation/controller layer go find struts/or something.

Probably not, for a fast paced environment. It is good too use spring but EJBs can do better.

Venkat

[Valentin Tanase]

I�ve been trying for a while to advocate the idea that EJB is far from being what it was promising and SUN, IBM & Co could be blamed for this. Of course different people could have different opinions, but I�d like you to read a reply to similar criticizing opinions posted by one of the greatest and pioneering designing minds that authored most of the fundamental EJB Design Patterns:

The problem is that everyone else chose to use EJB primarily for it's framework benefits (for the reasons I described in my blog), in a local manner. This should not have happened. Sun and the appserver vendors are partially to blame here for making EJB look like solution to world hunger, and the rest of the blame falls on the overzealous users (myself having been one of them too, hehe). Perhaps the greatest example of mis-use is the EJB expert group caving in to popular demand and making EJB have local interfaces. That just made the problem worse. A better approach would have been to state publically after EJB 1.1 that EJB is meant to be used for building large scale systems with DISTRIBUTED components, and all those who do not need remoting should use a framework like struts and be gone.

Signed [b]Floyed Marinescu[b/]
If you want to read the whole article and other people opinions:

http://dynamicsemantics.blog-city.com/abriefhistoryofejb.htm

As for me I�ll stop criticizing EJB on this forum. It definitely might offend or annoy enthusiastically, talented and passionate people and in a way criticizing EJB on an EJB forum is like worshiping Jesus Christ in a mosque :-)
Regards.

[domi o'brian]

What EJB can do better when compred to spring?

EJB learning curve when compared to spring.
Too complicated to maintain.
Now ejb 3 is out. So what is the future of EJB,
i just have an intermediate knowledge of ejb 2.
I bought three books and spent so much time in learning this//

Originally posted by Venkat Thiru:
It is good too use spring but EJBs can do better.

Venkat