Discussions

EJB has been compared with an elephant due to its complexity and heavyweight nature. According to Raghu Kodali, product manager and evangelist in the application server group at Oracle, EJB 3.0 is addressing these complexities with increased productivity and performance. In this Tech Talk, Kodali talks about the new features of EJB3, what it means for developers and how it will impact developers.

Topics Kodali addresses include:

- The runtime performance that EJBs will have for J2EE- What changes EJB3 has for session, message-driven and entity beans- What support developers should expect for older versions of the EJB specification- Where REST and XML RPC fit into the J2EE landscape with SOA API

Currently we have so many frameworks for persistence like Hibernate, JDO and for the business tier side we can use springs and lots of open source technologies. i am curious what ease is EJB3.0 going to bring before these technologies.

The concept of EJB has brought revolution in the Enterprise world and the Java Community has been enjoying the fruits of labor. I totally agree that recently there are better frameworks in the market and Sun has realised the importance of bringing all the goodies from different frameworks and streamlining the J2EE technologies. I think this evolution process is very very natural and the community needs patience instead of relying on too many frameworks. Too many frameworks makes the development process complex and at the same time we should not discourage the innovations. There should be some balance somewhere.

agree... but do we actually need all this compleities of running heavy weight containers to run our code? Spring and Hibernate has shown the simple way out but still Sun seems bringing unnecessary complexities favouring big application vendors.

Generally SUN is slow in adapting the latest which is understandable. you can't upset too many vendors overnight, the transformation should be slow. I think EJB 3.0 has features similar to Hibernate & JDO, but 'Spring' has further revolutionised the enterprise concept by eliminating the container. This is the area where SUN should focus to make the container optional. But Spring is still maturing and there are few issues like Transaction Management have to be more robust and it might take some more time to reach certain maturity. Meanwhile, I am sure SUN will definitely look into this area.

I think EJB 3.0 has features similar to Hibernate &amp; JDO, but 'Spring' has further revolutionised the enterprise concept by eliminating the container.

Please check your facts. JDO is a superset of EJB3 (Java Persistence 1.0 actually) and so has more than EJB3. Hibernate also has its own extensions. Spring hasn't revolutionised anything here, since JDO and Hibernate have run out of the container since start off. Spring simply makes all of the ORM solutions available for use, which is a good thing, but nothing revolutionary.

I think EJB 3.0 has features similar to Hibernate &amp;amp; JDO, but 'Spring' has further revolutionised the enterprise concept by eliminating the container.

Please check your facts. JDO is a superset of EJB3 (Java Persistence 1.0 actually) and so has more than EJB3. Hibernate also has its own extensions. Spring hasn't revolutionised anything here, since JDO and Hibernate have run out of the container since start off. Spring simply makes all of the ORM solutions available for use, which is a good thing, but nothing revolutionary.

Well yes, but EJB3 is a very good subset of both technologies so that you can get away with pure EJB3, in fact API wise EJB3 at the first reading of the spec seems to be very close to the state of Hibernate 3.1 API wise, there is nothing vital missing (but Hibernate has some extensions, yes)

Good point hasith,Generally SUN is slow in adapting the latest which is understandable. you can't upset too many vendors overnight, the transformation should be slow. I think EJB 3.0 has features similar to Hibernate &amp; JDO, but 'Spring' has further revolutionised the enterprise concept by eliminating the container. This is the area where SUN should focus to make the container optional. But Spring is still maturing and there are few issues like Transaction Management have to be more robust and it might take some more time to reach certain maturity. Meanwhile, I am sure SUN will definitely look into this area. -murty

Well EJB3 entity beans do not enforce any container at all, in fact it is planned that they will become a standard j2se extension. (javax.persistence)

As for the session beans, yes Spring has revolutionized it, but to my knowledge there is at least one implementation (jboss embedded) which does not need an external container.

But spring is not perfect as well in this area, sure it does not enforce a container, but the startup times once things get bigger, you add hibernate etc... are pretty much in the same area as with a container, especially if you have lots of tables to map.It may even become worse since the container preloads a lot of things which at hot deploy have to be loaded again and again in a container less or pure servlet runner approach.

(Theorectically, that you often are forced to restart the entire container for debugging purposes is a sad chapter in itself)

The whole container issue would be a non issue, if it really was started only once and if hot deploy would work in every situation, but fact is unfortunately that during heavy debugging and hot code replace a restarting of a container can happen quite often, during development.

You know the thing with all these frameworks is that they are interesting for college kids.

In my company, all those people who are so gun ho about Spring, Hibernate and other frameworks, still have to show to me their real value to the company - when they are not building another spring framework.

We are not a software vendor, we're here to make cash in other domains and IT is just a commodity. We've been in business even before the concept of computing existed.

I think that most people that are using these frameworks are forgetting that usage of frameworks itself is not the means, it's a way to make life easier for us. We tend to forget just that.Interestingly enough, people who are so excited about these frameworks tend to be consultants who bill per hour of work and most annoyingly, when it comes to using to productive high end solutions, such as Business works (just to leave the Oracle arena because it isn't just an Oracle issue here), they would rather recode from scratch in java. I have so many examples of people rebuilding their own BPM, J2EE solution within my company that I would need a book to list those projects and what they did that was downright stupid.

As for myself, I'm looking forward to EJB3 and having a fully compliant J2EE 5 Server that has no defects. That's because software vendors are so interested in creating hype (e.g. SOA) that they don't take their time to push out a stable solution. However past experience, such as Intel, has shown that pushing out something before competition albeit full of bugs is preferable in the long run. Presumably because of all these consultants ...

I think the bottom line here is that one day non IT people are going to get wiser and that is going to spell the end of all those college kids and their toys.

You know the thing with all these frameworks is that they are interesting for college kids ... I think that most people that are using these frameworks are forgetting that usage of frameworks itself is not the means, it's a way to make life easier for us.

What is the stack and set of tools that you use for building Web Applications today?

That being said, when building web applications I have used the following in the past on web type projects, based on user requirements and existing in-house knowledge & expertise (from dev to production), not always together in the same project mind you :o)

It's not easy to answer that one in brief fashion, in particular on a Friday after a long lunch ...

First and foremost, from my window, SOA is being pushed very hard by vendors and few clients are requestors ... so I see SOA as vendors/consultants creating a need where there is none. The second thing is that - we have specialized SOA consultants on board, which is why I'm saying this - I don't think that people have really understood why past IT projects have failed (when they failed) and determined how to improve things.They are pushing SOA all over the show and haven't really grasped the limits of the tools being used. As a result, we are now transfering 1Gb+ XML messages in production and are building a dedicated IDE that is capable of browsing those 1Gb+ XML messages because none on the market are capable of doing that (I'm not in on that, thank god!). Due to all the SOA hype no one wants to admit that it was a mistake to generate 1Gb+ messages in XML ...

What I see over time is that new technologies are pushed very hard in a cyclic fashion, initially there is a lot of hype around it, and then after all the hype people settle down and realize that it isn't a magic bullet: it's just another concept/tool.

The thing is that, amongst other things, IT people - and I'm one of them - love to reinvent hot water rather than improving previously delivered tools.

As I speak/write, we're busy building a third tower to host our staff near our corporate headquarters. Looking at that third high riser (40 floors) go up I realise that we, in the IT world, lack the maturity and the industrial aspect of those builders. We try/beleive that this new technology will be the answer to our past issues without trying to figure what went wrong. In fact, at the end of the day I'm convinced it's not the technology, it's mostly a human factor.

People are as gung ho about SOA as they were about CORBA in the '80s and as they were about EAI in the '90s and yet we still fail to succesfully deliver stable and robust applications ... It is interesting to note that today's SOA vendors are yesterdays EAI vendors and last week CORBA vendors: same people different label, same bugs ...

When I talk to SOA gung-ho fellows they are not capable of really explaining to me why previous CORBA/EAI projects were such a failure - when they failed, not all have failed. So how can you improve something if you haven't learnt from your past mistakes or those of the others?

Let's take a different example to illustrate the framework thing, I have this guy on the team that is gung-ho about wiki, ok so beit. We decided to put our internal discussions on wiki "A" last year. 6 months later, he comes back to me and says: listen wiki "A" sucks, I have found wiki "B" that is 10 times better ... Ok, so we change to wiki B, migrate all our data to this new wiki (3 months).Three weeks ago this guy comes back to me and says, hey you know there is this cool wiki, it's really the best, we really have to migrate to wiki "C" ... I'll let you guess my thoughts on this story that reflects general behaviour of IT fellows ...

You can extend those thoughts to other things, like Cedric's new testing framework. Well, hey, I'm using jUnit it responds to my requirements. I trained 200 people to use jUnit, and they are still trying to understand how it really works and are far from mastering jUnit, so I'm not moving to a new test framework, I have to deliver applications that work and fast. My business is not making software or testing the lastest, sexiest framework.

As for the SOA, we've just finished installing and are beginning to get some ROI from our EAI solutions, people are becoming knowledgeable on it and starting to get productive. I'm not taking a new tool for the fun of it because it implements this new concept called SOA.

However, in answer to other poeple remarks, we do look at how the market evolves, what are the new tools that are coming out. When those tools are mature and robust, if they have added value we'll use them. Right now I don't think that SOA tools are mature, if it were the case I wouldn't have to have an army of SOA consultants on-board explaining how to deploy SOA, what tools I must develop in-house because there are currently no market solutions, etc, etc. Thank you come back when it's rock solid please.

Of course, we do occasionally take none rock solid stuff, because we don't have the choice, as there are domains were IT solutions are not as evolved and mature as we would like, but that's life.

At the end of the day, I think it's how our society has evolved. 2 years ago, I switched from a 24*36 camera to a digital camera. 6 months later, my camera was out of date, out of fashion. In the beginning of the year I went to buy a new & rather expensive lens. The vendor looked at my camera and said: "hey dude, you should buy a new camera yours is out of fashion and too old for that lens". The interesting thing about that lens is that Canon first produced it in 1997, way before my digital camera existed. The second thing is that my camera is still working and giving me total satisfaction although it has some defects ...

The big problem with folks is that they do not think about big picture in the everyday rush and do not think about socio-psychological aspects of job and life much. The problem is that there are way to many people than needed to achieve 'goals' therefore main task is to look busy and important, have many subordinates, all that stuff. Young “folks” are constantly arrive and they need to distinguish themselves, they want piece of pie, therefore consciously and subconsciously they try hard to promote their “ideas” or rather misunderstandings of problems – the XML-SOAP craziness is the vivid example.

It is kind of natural forces at play: luddites of 19th century, unions of 21st ( look for recent Longshoreman strike and forces behind it), RIAA – people are trying to preserve their place and income when there is no more need for them.

As for Goodies: take serious look at Tapestry - this is only framework that provides real separation of responsibilities and allows designers and developers to collaborate - no more need to redo designer's input in PHP, Ruby, JSP, JSF, etc. Unmatched benefit IMO for extended teams.

As for Goodies: take serious look at Tapestry - this is only framework that provides real separation of responsibilities and allows designers and developers to collaborate - no more need to redo designer's input in PHP, Ruby, JSP, JSF, etc. Unmatched benefit IMO for extended teams.

One of the reasons that JSF was designed to allow use in visual tools was so that designers could manipulate the components without having to be developers. JSF allows separation of designer and developer as well.

One of the reasons that JSF was designed to allow use in visual tools was so that designers could manipulate the components without having to be developers. JSF allows separation of designer and developer as well.

It was designed to sell new tools and keep people busy. It is really funny to watch how JSF folks flip between two positions:- They say that JSF is great because JSF is designed to be used with visual builders;

When confronted with lack of reliably working visual tools (like Delphi or VB for that matter ), necessity to teach UI designers to use those tools /did somebody try to deprive HTML designer of DreamWeaver? :) /-They flip and say: no-no-no, you do not need to use visual tools, it is easy to code JSF by hands. :) Just go and redo in JSF whatever designer came up with in the HTML :)

====="It is difficult to get a man to understand something when his salary depends upon his not understanding it." -- Upton Sinclair

It is really funny to watch how JSF folks flip between two positions:- They say that JSF is great because JSF is designed to be used with visual builders;When confronted with lack of reliably working visual tools (like Delphi or VB for that matter ), necessity to teach UI designers to use those tools /did somebody try to deprive HTML designer of DreamWeaver? :) /-They flip and say: no-no-no, you do not need to use visual tools, it is easy to code JSF by hands. :) Just go and redo in JSF whatever designer came up with in the HTML :)

Sorry, but where is the contradiction? Apart from the fact that there are reliable visual tools - JBuilder, Studio Creator etc., what is the issue with having a technology that works in visual tools and is easy to code by hand?

Sorry, but where is the contradiction? Apart from the fact that there are reliable visual tools - JBuilder, Studio Creator etc., what is the issue with having a technology that works in visual tools and is easy to code by hand?Personally, I find that a benefit, not a contradiction.

Creator does not seem _reliable_ as in Delphi or VB, and JSF is NOT easy to code by hand. Well, let me clarify: I agree that it is better than than bare JSP, but IMO it is not comparable to Swing, Delphi, VB, Tapestry.

Sorry, but where is the contradiction? Apart from the fact that there are reliable visual tools - JBuilder, Studio Creator etc., what is the issue with having a technology that works in visual tools and is easy to code by hand?Personally, I find that a benefit, not a contradiction.

JBuilder is casualty in IDE wars :) http://www.javalobby.org/java/forums/t63512.htmlCreator does not seem _reliable_ as in Delphi or VB, and JSF is NOT easy to code by hand. Well, let me clarify: I agree that it is better than than bare JSP, but IMO it is not comparable to Swing, Delphi, VB, Tapestry.

You are right - I meant JDeveloper. In my opinion (having used all these technologies extensively) I think it is definitely comparable to Swing, Delphi and VB. And, I do find it easy to code by hand. Very easy. But I guess this is just a matter of opinion.

As for Goodies: take serious look at Tapestry - this is only framework that provides real separation of responsibilities and allows designers and developers to collaborate - no more need to redo designer's input in PHP, Ruby, JSP, JSF, etc. Unmatched benefit IMO for extended teams.

Not the only.Did you check Wicket? Same separation of responsabilities, and no XML.BTW, I've seen your posts regarding Applets, and I think you'll like Wicket's support for them as regular components.

I've seen your posts regarding Applets, and I think you'll like Wicket's support for them as regular components.-----Gustavo.

Chances are great that you have misunderstood my post: I usually advocate support of applets by JavaWebStart for the purposes of predictable and controllable caching, that should be accompanied by extending JWS to support repositories to avoid duplicate downloads of common components, that would lead to quick startup time.

I do not see much value in using Applets as components (like Table implementation) because if we can count on client's support for applets then it would be better to implement the entire interface as Applet and communicate with backend via protocol like Hessian. However I think that Applets are great as replacement for portlets.

First and foremost, from my window, SOA is being pushed very hard by vendors and few clients are requestors ... so I see SOA as vendors/consultants creating a need where there is none. The second thing is that - we have specialized SOA consultants on board, which is why I'm saying this - I don't think that people have really understood why past IT projects have failed (when they failed) and determined how to improve things.They are pushing SOA all over the show and haven't really grasped the limits of the tools being used. As a result, we are now transfering 1Gb+ XML messages in production and are building a dedicated IDE that is capable of browsing those 1Gb+ XML messages because none on the market are capable of doing that (I'm not in on that, thank god!). Due to all the SOA hype no one wants to admit that it was a mistake to generate 1Gb+ messages in XML

I thought that we all agree on that SOA is not equal to WS and XML. I am the first admit that a 1GB+ XML is asking for trouble. First I have to say that if you have a 1GB+ XML message you should start rethinking of your design. Secondly I am resisting our vendors attempt to make us use their WS only solution. XML is still adding too much overhead.

What I am trying to say is that the SOA concept is not bad just because some vendors are trying to say that their product is what SOA is all about.

You know the thing with all these frameworks is that they are interesting for college kids.

With all due respect, who can make such a sweeping remark?

If college students represent one extreme in terms of incessant appetite for constantly toying with new things, the other extreme is filled with people who are too lethargic even to look at new ways. This comment is a true representative of the latter group. It reminds us of some people in US, numbering in several thousands, who till today do not use electricity at home, ride horse buggies instead of cars and wear clothes they themselves weave. Is there anything wrong in it? Who would judge?

But in today's world, especially in business, one has to compete with others at every step. In late 1800s, coalminer John Henry proved human muscle could beat machines too, but at the expense of his life. If you can beat competition with Java code just written by you, using no frameworks or libraries written by others, congratulations! You are the John Henry of this century! I envy you. But in my company, if one does not use any proven framework for logging, MVC implementation, database persistence etc., he is not even given a single minute to justify, he is thrown out of the project as quickly as possible. By the way, most of the people who work here are employees, not consultants.

You know the thing with all these frameworks is that they are interesting for college kids.

With all due respect, who can make such a sweeping remark? If college students represent one extreme in terms of incessant appetite for constantly toying with new things, the other extreme is filled with people who are too lethargic even to look at new ways. This comment is a true representative of the latter group.

There is nothing wrong with playing with new thing, IF they are new. Most of the “frameworks” caused by ignorance of existing solution, inability to cooperate to improve existing solutions, foolish arrogance, neglect to study reasoning behind decisions and compromises which lead to certain design and implementation.

I think that comment is mis attributed – I would rather say that the comment comes from sane group that sees bigger picture and has some education and perspective.

Interestingly enough, people who are so excited about these frameworks tend to be consultants who bill per hour of work and most annoyingly, when it comes to using to productive high end solutions, such as Business works (just to leave the Oracle arena because it isn't just an Oracle issue here), they would rather recode from scratch in java.

BIG -1 here.

I am a consultant and make my money billing by the hour or on fixed bids. I use proven frameworks specifically because they save me time and because I don't have to rebuild things from scratch.

Perhaps writing a framework is an exercise in masturbation, but using one is very much the opposite. You seem to be big on standards proposed by bodies, but my experience is that frameworks that are worthy of my time have become standards in their own right (Spring, Hibernate).

I think your criticism is somewhat misguided. You disparage people who use frameworks by somehow saying that they'd like to recreate everything from scratch. That just doesn't make any sense.

No, I disparage people who write from scratch when they could be using a framework(s), I disparage people who use multiple frameworks and code some glue when they could be using an off the shelf solution (i.e. J2EE server)

I use frameworks, I have even written some frameworks in past projects with Vincent MASSOL. But I also use off the shelf solutions such as Weblogic when it is appropriate.

However I have a question for people who have answered me negatively: I use Log4j a lot, it's nice, it works, it's a standard in the java world for logging. Why the hell do people use, let along why did they write it, commons-logging?

Yes, I'm big on standards because I can expect java developpers to be savvy and trained on standard market solutions. Some standards are defined by bodies (W3C, JCP, ...) others are de facto standards (Log4j, Rendezvous in certain banking activities, ...)

Those are the standards that I like and adhere to: things that are used, were built for the right reason and stood the test of time.

You may be productive on the frameworks that you use, but if those frameworks aren't used in my company that's an issue to me because when you leave I will need someone to make that code live.

In other words, your frameworks are welcome if they are the frameworks that we use for which I can find trained developpers (in-house and on the market) and if they are not a sloppy excuse for not using Weblogic (example here).

.. your frameworks are welcome if they are the frameworks that we use for which I can find trained developpers (in-house and on the market) and if they are not a sloppy excuse for not using Weblogic (example here).

It means you have a company standard and guideline based on which you select new frameworks and technologies. That's a sign of maturity and I believe every sane company does have the same approach.

The rest of your comments stamping all new efforts as total waste of time, simply reflects how scared you are because of the quick pace at which technologies are changing.

But whether I am scared or not, should the progress of technology stop? And historically, almost all steps of progress initially appear to many as just chaos and disorder.

It means you have a company standard and guideline based on which you select new frameworks and technologies. That's a sign of maturity and I believe every sane company does have the same approach.

You know I'm starting to wonder if there is such a thing as sane company :o)

The rest of your comments stamping all new efforts as total waste of time, simply reflects how scared you are because of the quick pace at which technologies are changing. But whether I am scared or not, should the progress of technology stop? And historically, almost all steps of progress initially appear to many as just chaos and disorder.

No, progress should never be hindered or stopped because that brings the death of a community.

Don't get me wrong, I'm not against SOA and progress, but from my standpoint true progress has to be smart: progress for the sake of progress is doomed to fail IMO.

Too many people are saying: "hey, I read this cool thing in [put your favourite comic here] about Service Oriented Architecture. We should go for this big time, it's good for my career and my bonus because top management also read [put your favourite comic here]."

Being part of the strategy team of my company means that I have to always keep a look out for technology trends such as going to Gartner/JavaOne/... sessions. But there is line between: "Cedric uses this technology on his laptop after seeing it at JavaOne" and "2 600 IT developers are using this because it's cool".

In case of commons logging, yes there was a need for it (like in most frameworks)the reason for this was, that there were several competing logging frameworks trying to achieve different targets and a standard which was specified but not working really well, at that time people started to write meta logging frameworks to unify the codebases and some legacy code which were using different logging frameworks. One became then commons logging.

Just to give a historical view to the things. Commins logging must have done something right, because people still use it and I have yet to see a recent project not using it instead of direct calls to the logging frameworks it supports.

In case of commons logging, yes there was a need for it (like in most frameworks)the reason for this was, that there were several competing logging frameworks

I'm not a historian of frameworks, but I do remember that at some point in time there was an issue because Apache developped their own implementation of a logging framework thereby directly competing with Log4j ...

It was only but later, after quite a few people started ranting that the common API was built and the possibility to use another logging framework was rendered: they did not start by writing that API first.

If I remember well, for a long time, Excalibur required it's proprietary logging framework that wasn't Log4j.

Anyway I was refering in essence more to the competing logging frameworks more than the commons-logging API per se.

I was unable to find those mails in my mailbox and google didn't give the mails I wanted from the archives.

As you clearly stated:

several competing logging frameworks

and I'm just saying nobody needed that, there was no added value or progress there.

Also I do note that in the case of frameworks, people don't really tend to work together in a natural fashion, hence multiple frameworks for the same thing ... alas ...

For example, I still haven't grasped the real added value of the Harmony project and how it will make IT Software progress in the right direction ... but then maybe I'm being pessimistic?

"but do we actually need all this compleities of running heavy weight containers to run our code?

That depends on how you define heavy.

Our EJB applications have to be deployed to a server supporting the full J2EE spec. On the flip side the packaging of the application is more simplistic as the only thing needed in the ear is the application code, and all dependencies are supported by the app server.

In the other case the Spring applications, they can be deployed to a any compliant servlet container, but the ear is huge, and some thought has to go into the libraries that are packaged, and what dependencis are needed. (unless you don't mind having a 50mb ear file)

Another funny thing that I have noticed is that most everyone I know that is writing spring applications are deploying them to JBoss servers. So all that "Heavy" stuff is already there.

Thanks for asking. Actually we have only delivered several early previews of EJB 3.0 support and most recently shipped our 10.1.3.0.0 release of the application server. This includes preview support for EJB 3.0 in our container (OC4J), Java Persistence in TopLink, and JDeveloper support. All of this is based on drafts of the specification.

I cannot comment on the schedule for the finalization of the specification but I understand the co-specification leads for EJB 3.0 (JSR 220) Linda DeMichiel (Sun) and Mike Keith (Oracle) are working hard with the rest of the expert group to finalize the specification.

Oracle is strongly committed to EJB 3.0 and in addition to contributing and co-leading the expert group we have also contributed a community edition of our TopLink product, TopLink Essentials, as the reference implementation of Java Persistence. As the RI TopLink Essentials delivers a commercial quality implementation of the Java Persistence specification which is already available today through GlassFish for you to use.

I hope this addresses your concerns. There are previews available from Oracle, through GlassFish, and other vendors. Once the specification is final those vendors, including Oracle, will update their products to also implement the specification.

I believe that the question of when we'll see this from Oracle is more valid than it might appear at first. We're still waiting for a production-ready 1.4 compliant server. The release has been promised for almost a year now, and still it's only in developer preview. Hell, I'd just be happy for JMS 1.1 compliance, which has been around for how many years, before starting to worry about EJB 3.0.

I think Oracle, despite their activity in JCP groups and other standards bodies, has been unforgiveably slow in delivering production versions of their servers that match the latest standards. This makes it extremely hard to use these technologies in deployments, because clients and IT managers are (understandably) reluctant to go into production with a server version that the vendor explicitly recommends against for production use.

In the 18th century Enlightenment established rationality, reason and knowledge-based discourse over superstition and belief. Coming from this tradition i consider it an insult if someone tries to "evangelise" me about a technical subject. This industry desparately needs measurements, theory, experiments and enlightened discussions - not pseudo-religions and evangelisation !

Good catch! In my mind however “technology evangelist” was equal to “technology educator” but after quick reexamination I agree with you: in practice “technology evangelist” != “technology educator”, and you are absolutely right the word “evangelist” should have no place in the engineering and science fields.

First of all.. I must admit that I am, like many others, a disillusioned EJB user.And.. to be completely honest.. I am a bit enamoured with Spring.

With that out of the way.. I really have to ask this forum WHAT exactly is EJB30 spec all about?Now that POJOs are the underlying objects, persistence is not really a part of EJB (JSR-220 talks about JDO), what really, of substance is left in EJB30?The link here outlines features of EJB30:http://www.oracle.com/technology/tech/java/oc4j/ejb3/fov_ejb30.html

IMO none of them are fundamental value-adds...

"Simplified API" seemes to me to be an improvement to the pre EJB30 mess we had/have.. so ... big deal... why deal with the API at all, simplified or not?

"Use of Annotations Instead of Deployment Descriptors".. that seems to be another cop out. XDoclet provides annotation support.. so if I embed my transaction semantics in my code, that is probably a BAD thing (tight coupling). This seems to be a knee-jerk reaction to the user communities' frustration with dealing with 2/3 deployment descriptors with each EJB. So, in that sense, it is a way to plug a hole created by EJBs to begin with!

"Enhanced Lifecycle Methods and Callback Listener Classes": This again seems to be a change that is being made to plug an existing 'defeciency'.

If your application needs to cache business objects in the middle tier (and avoid round trips to the database), then EJBs makes sense, everything else (infrastructure services like transactions, security or persistence) can just as easily be supplied by different 'framework's. Not one, but many... at-least we can pick and choose.

For those who want to test that theory, try this webapp. http://technochord.blogspot.com/It is a standalone webapp that is developed using Spring. It provides all the infrastructure services you would look for in and EJB based application, except that it deploys on Tomcat(with no EJB support).

Can someone tell me what the big deal is with EJB30? To me it is just another POJO based framework, much like Spring, with two major differences:1. It has to be backward compatible with EJB < 30. That gives the spec a lot of twists.2. It has the blessings of the big kahuna.. Sun.

Matt,I think that the question that was asked is: how is EJB 3.0 better than spring + hibernate or spring + toplink?-Edwin

It isn't. First "better" is subjective. Second why does it have to be better? Standards bodies always adopt things at a slower pace then free standing projects. This has always been the case, and is not always a bad thing.

Pankaj said that he was "enamoured" by Spring, said that EJB3 has no "fundamental value-add" (partial quote), and then said "To me it is just another POJO based framework, much like Spring".

I can't see how you can love one and spit on the other. The same people who developed Hibernate and Spring are the ones developing EJB3.

Matt,I think that the question that was asked is: how is EJB 3.0 better than spring + hibernate or spring + toplink?-Edwin

(1) Extended persistence contexts(2) Stateful session beans (server-side conversational state management)(3) Annotation-based programming model(4) Choice of implementations, and a very high level of portability between them(5) Integration with container management, monitoring and hot deployment infrastructure (dev may not care, but ops *does*)(6) A standard platform and marketplace for frameworks to build on top of (eg. Seam)

Gavin,I like your answer much better (than Matt's, who seems to be pretty territorial about his EJB turf).

(1) Extended persistence contexts(2) Stateful session beans (server-side conversational state management)(3) Annotation-based programming model(4) Choice of implementations, and a very high level of portability between them(5) Integration with container management, monitoring and hot deployment infrastructure (dev may not care, but ops *does*)(6) A standard platform and marketplace for frameworks to build on top of (eg. Seam)

In a true spirit of enquiry, then, here is what I'd like to know:

- Isn't points 1 and 3 really a fallout of Hibernate/persistence rather than the core EJB3 spec? - Stateful SBs are certainly an EJB concept, but last I heard, in a web environment, statemanagement is preferably done with the HttpSession. In a non-web based application, I do understand that Stateful Session beans are useful.- Choice of implementations is awash.. because all IoC containers will allow that. If EJB3 promises a greater level of portability than other frameworks, I'd like to know how.- Since EJBs predicate a seperate classloader, I can understand how hot-deployment may be easier to implement by the appserver. So, I can see that for ops folks, EJB may be a better solution, but ONLY if your app's EJBs are truly independent modules that can be seperately deployed.- I am not sure what this last point means.. can you please explain? I have not done too much research into Seam, but from my initial reading, it seems to be framework much like Tapestry except that it has hooks into EJB3. So why is EJB3 *more* extensible to build upon, than Spring, for instance?

Again.. I dont want to prove any one framework superior (if that were even possible) to another.. but I do want to discuss these questions in a non-biased manner.

As for (2), no, tx demarcation and exception rollback semantics, dependency injection, security, component definition, etc is all done in annotations, and not by the persistence spec.

Stateful SBs are certainly an EJB concept, but last I heard, in a web environment, statemanagement is preferably done with the HttpSession. In a non-web based application, I do understand that Stateful Session beans are useful.

Using HttpSession instead of stateful session beans is about the dumbest thing that has ever become a so-called "best practice" in any programming language community. Fortunately, EJB3 has given us a chance to roll back that awful practice.

I can understand how hot-deployment may be easier to implement by the appserver. So, I can see that for ops folks, EJB may be a better solution

In practice, this stuff is also works much better at development time. I have tried and failed to get hot redeploy to work reliably in standalone Tomcat, and this single factor makes me MUCH more productive testing against Tomcat/JBoss, due to the much shorter compile/deploy/test cycle. Still, I will accept that this is probably more of a quality-of-implementation issue than a conceptual issue.

So, I can see that for ops folks, EJB may be a better solution, but ONLY if your app's EJBs are truly independent modules that can be seperately deployed.

This is very common in large applications, and will be especially common in ESB environments.

Choice of implementations is awash.. because all IoC containers will allow that

Wha??? What two currently existing "IoC container(s)" are compatible with each other? (Apart from Oracle EJB3 and Jboss EJB3.) I am not aware of any non-EJB3 IoC container which may be replaced with an alternative implementation.

So why is EJB3 *more* extensible to build upon, than Spring, for instance?

Because it is a standard. Third-parties build frameworks on top of standards. They never (or at least very rarely) build on top of nonstandard solutions. The risk to the third party is simply too great.

Wait and see: in two years time there will be a profusion of frameworks and tooling for EJB3, and you will look back at what was available for eg. Hibernate+Spring and wonder how you ever managed.

Wait and see: in two years time there will be a profusion of frameworks and tooling for EJB3, and you will look back at what was available for eg. Hibernate+Spring and wonder how you ever managed.

I think in two years' time tooling and frameworks will be available, but not for EJB3 but their underlying implementations. I mean technology like Annotations, AOP, POJO-based programming etc. I still think a combination of Hibernate+Spring will be more popular than EJB3.

Wait and see: in two years time there will be a profusion of frameworks and tooling for EJB3, and you will look back at what was available for eg. Hibernate+Spring and wonder how you ever managed.

I think in two years' time tooling and frameworks will be available, but not for EJB3 but their underlying implementations. I mean technology like Annotations, AOP, POJO-based programming etc. I still think a combination of Hibernate+Spring will be more popular than EJB3.

Ah forget it, Spring already is moving towards EJB3 as additional PA which you can put spring daos on top.And EJB3 is close enough to Hibernate and other ORM mappers that people will have an easy time to switch in between, in fact, if you look at jboss they already are pumping out compatibility apis on top of Hibernate so that the API becomes closer to EJB3 (Hibernate Annotations and Entity manager)I just want to ask in this group, all the people dismissing EJB3, have you ever had a look at the specs and implementation so that you know what you are talking about.We are speaking about APIs here, partially straightly derived from Hibernate, Toplink JDO (you name it) we are speaking about implementations here, which are inside of a container, but also can be used outside of the container.We are speaking about a general API here, which does not have any resemblence to EJB2 except the name EJB and is greatly simplified, so no need for a huge additional simplifacation layer is needed.

I constantly get the feeling that people hammering EJB3 constantly do that because they thing EJB3 EJB2+ a few extensions.

But believe me, it is as close to EJB2 as a single @Webmethod is to a full blown Webservice declaration including stubs skeletons and wsdl files.Even going from EJB3 session beans to a spring beans layer would mean you have a higher complexity. (as much as I love Spring, but it really is like that)

I still think a combination of Hibernate+Spring will be more popular than EJB3.

I don't think this statement makes sense in some ways, because in the very near future, if you use Hibernate (or at least some aspects of it), you will be using EJB 3.0 POJO persistence, so to say that one is more popular than the other is not really appropriate.

So why is EJB3 *more* extensible to build upon, than Spring, for instance?

Because it is a standard. Third-parties build frameworks on top of standards. They never (or at least very rarely) build on top of nonstandard solutions. The risk to the third party is simply too great.

Hibernate was not a standard until very recently and that did not prevent it from becoming popular and having other framework built on top of it.

Hibernate was not a standard until very recently and that did not prevent it from becoming popular and having other framework built on top of it.

talking about EJB, this is only history:step 1- gurus describe enterprise design patternsstep 2- a standard _tries_ to specify a spec describing how should some of these patterns be implemented --> ejb 1step 3- the standard is updated, the goal is to solve some problem --> EJB 2step 4- this is not enough, people are disappointed, open source projects show the community that there are other ways to implement design patterns, to solve enterprise problems, to be performant, to be productivestep 5- all the actors, experts, open source projects gurus, strong commercial projects leaders update the standard --> EJB3

With 3 iterations, i think EJB is now mature. Let's play with it and see how it great to be able to design rich domain model, how you can be productive, how applications are portable, easier to test,...

Without EJB1 and EJB2, do you think projects like hibernate or spring would have existed? maybe Gavin or Rod can reply. I really don't know what the answer is.Imagine, EJB1 and EJB2 had never existed, i think we would all be playing with CHAOS.

If your rich OO domain model hits the Oracle and your DBA tells you: "we need to optimize queries, related to an inheritance of your domain model", what are you going to do???

i'll take the discriminator strategy and put check constraint, what's wrong? I'm not going to think Merise because of my DBA, if polymorphism is optimal, i'll do my best to take advantage of OO _features_.DBA is my friend, performance is a goal, so we had to discuss the best way to handle the use case. Discriminator is not so bad if you remember check constraints.

Using HttpSession instead of stateful session beans is about the dumbest thing that has ever become a so-called "best practice" in any programming language community.

Gavin, two questions:

1. What is it that you dislike about HttpSession?

2. What is it that you like about stateful session beans?

I always found HttpSession to be handy, because its life-cycle was managed for me by the container to match the life-cycle of the "connection" that it was serving.

Stateful session beans had more precision (tighter contracts), but required more work to use (e.g. life cycle was the app developer's problem) and had more caveats (e.g. threading). In the end, I'd have to keep a refereence to one of the SfSBs from the HttpSession anyhow ;-)

Isn't points 1 and 3 really a fallout of Hibernate/persistence rather than the core EJB3 spec?

I was perhaps not quite precise enough in (1). Let me say: *managed* extended persistence contexts.As for (2), no, tx demarcation and exception rollback semantics, dependency injection, security, component definition, etc is all done in annotations, and not by the persistence spec.

Stateful SBs are certainly an EJB concept, but last I heard, in a web environment, statemanagement is preferably done with the HttpSession. In a non-web based application, I do understand that Stateful Session beans are useful.

Using HttpSession instead of stateful session beans is about the dumbest thing that has ever become a so-called "best practice" in any programming language community. Fortunately, EJB3 has given us a chance to roll back that awful practice.

I can understand how hot-deployment may be easier to implement by the appserver. So, I can see that for ops folks, EJB may be a better solution

In practice, this stuff is also works much better at development time. I have tried and failed to get hot redeploy to work reliably in standalone Tomcat, and this single factor makes me MUCH more productive testing against Tomcat/JBoss, due to the much shorter compile/deploy/test cycle. Still, I will accept that this is probably more of a quality-of-implementation issue than a conceptual issue.

So, I can see that for ops folks, EJB may be a better solution, but ONLY if your app's EJBs are truly independent modules that can be seperately deployed.

This is very common in large applications, and will be especially common in ESB environments.

Choice of implementations is awash.. because all IoC containers will allow that

Wha??? What two currently existing "IoC container(s)" are compatible with each other? (Apart from Oracle EJB3 and Jboss EJB3.) I am not aware of any non-EJB3 IoC container which may be replaced with an alternative implementation.

So why is EJB3 *more* extensible to build upon, than Spring, for instance?

Because it is a standard. Third-parties build frameworks on top of standards. They never (or at least very rarely) build on top of nonstandard solutions. The risk to the third party is simply too great.Wait and see: in two years time there will be a profusion of frameworks and tooling for EJB3, and you will look back at what was available for eg. Hibernate+Spring and wonder how you ever managed.

And also persistence frameworks: Hibernate 3, TopLink, KODO, some JDOs. They are all going to implement EJB3(JPA) API. Why should I waste my time to learn some implementation specific API? Just because for somebody Hibernate3 is 5% better than EJB3(JPA)???

Actually hot deployment works really well also in Tomcat (not as good as in some other app servers though)most people wo tend to develop on Windows just dont know that you have to adjust the context.xml or add one.The main reason for deploying against an app server even at development time is, that the app server itself delivers a lot of functionality which otherwise has to be added (most people usually dump hibernate, spring etc... into the WEB-INF which becomes a pain once the app grows bigger)

if you can split your concerns between backend and frontend and you only have to restart parts of it you can reduce roundtrip cycles tremendously.

Wait and see: in two years time there will be a profusion of frameworks and tooling for EJB3, and you will look back at what was available for eg. Hibernate+Spring and wonder how you ever managed.

I do want to ask you about the "it's a standard" argument, tho':

So why is EJB3 *more* extensible to build upon, than Spring, for instance?

Because it is a standard. Third-parties build frameworks on top of standards. They never (or at least very rarely) build on top of nonstandard solutions. The risk to the third party is simply too great.

EJB is a standard because there is a container spec and AppServer vendors are writing implentations to it. Spring doens't adhere to any pre-written container spec so, in that sense, I guess it is not a "standard". The underlying APIs that Spring supports, for example, JTA for transactions, or the aopalliance framework for method interception do follow a "standard", that is, pre existing specs.

However, that brings me back to my earlier question... why do we need an appserver supplied container when a webapp based (or Java application based) "container" (such as Spring) will achieve the same enterprise goals?

Is it just market positioning or is there a genuine advantage to using a AppServer supplied container for enterprise level applications?

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.