Talk:Jakarta Enterprise Beans

--112.135.112.37 (talk) 10:04, 20 August 2014 (UTC)<!-- Reduced importance to Mid from High; does not appear to be a general area of knowledge; likely High f

Applications
The writeup is too technical. The whole EJB concept is useless if it can't relate to real world applications. Sltan 06:18, 11 October 2005 (UTC)


 * I've rewritten the first half of the article, hopefully it is a bit more comprehensible now. More improvements would be welcome, as always. --Marlow4 20:10, 19 October 2006 (UTC)


 * I agree, nothing in this article actually describes what the PURPOSE of EJB's is. I am very familiar with several other languages and came to this article to learn whats the big deal about Beans?  All this article says is:
 * Beans are components that are modular and can contain business logic. That description could also describe objects, classes, even subroutines depending on your definition of "modular".  All this is saying that this is "yet another construct for making systems", but it doesn't say at all how it dffers or relates to other coding constructs.
 * A bunch of history about how people loved it, then hated it, revolted from it and them make peace by making a compromise version. Nothing is actually stated about WHY it was so complex that people didn't like it, or why the rewrites like Swing or Hibernate were better.
 * There are different types of Beans. The variation descriptions might make more sense if I knew what they were variations From.  I can understand Stateless verses stateful for shared or exlclusive access, but please, access to What?  Are beans just glorified Classes?
 * Multiple beans can be in an EJB Container. What?  Why?  The link to "EJB Container" takes me to ...  Enterprise JavaBeans.  Helpful.  Please have a section called "EJB Containers" if not it's own topic.
 * Beans have 1 class and 2 interfaces which have class and instance methods. Yeah I can pretty much understand that, but again, WHY? what is a Bean used for? What does the "Home" interface refer to, or the "Component" interface?  Are they just connecting to other beans in the same "container"? other remote clients? remote web services?  I really need an example of a real-world use.
 * This article requires that you already know what Beans are and what they're good for. I came to this topic having heard I should check them out, but after staring at this for an hour and reading all other referencing articles I could find, all I can tell is that it's some kind of construct built from a couple other constructs.  But why someone bothered to make it in the first place, or why it's significant, I've no clue.  Waste of an article as it stands right now. Unlox775 22:39, 8 January 2007 (UTC)

I think what EJBs are for are also hinted in: "...the problems that the EJB standard was attempting to address, such as object-relational mapping and transactional integrity, ..." "...original EJB specification's primary virtue — enabling transactional integrity over distributed applications ..."

Better if these can be expanded?

Wonder if it is useful to include hints on how the "lightweight" J2EE solutions can do for transactional integrity over distributed application. Thank you --Friend2008 (talk) 04:12, 10 April 2008 (UTC)

More info about EJB3
It could be intresting having more infos about EJB3

EJB criticism?
Someone more knowledgeable than me should write a section on EJB criticism. There is a widespread belief that the EJB model is flawed (a lot of programmers I know won't touch an Entity Bean, though they find uses for Session Beans).

As an example, we have this statement by |this blog by Bruce Eckel: We now know that EJB 1 & 2 were based on an entirely flawed set of use cases. Because of the damage this (still slowly dawning) realization has wrought to Sun's reputation, it's hard to know whether EJB3, which probably should have been called something else to disassociate it with the failures of its predecessors, will succeed, despite the fact that EJB3 is like a breath of fresh air.

If you read well in the article is written "EJBs should be used in large, distributed, transaction-intensive enterprise scenarios where scalability is a key factor." if the application is "easy" yo have not to use EJB


 * Also the EJB3 spec addresses most of the criticisms (which as you say were myriad and justified) of the earlier specs. So a "criticism" section would be fairly moot now (widespread criticisms of EJB3 have yet to surface and IMHO are unlikely).  Either way though, the amount of criticism EJB 2 & 2.1 got and how that led to the massive changes in 3 would be important material to detail in the article.  --Marlow4 22:28, 4 July 2006 (UTC)

I agree that someone more knowledgeable should write the section. The naivete of the author paints a warped picture:

"Granted, the problems that the EJB standard was attempting to address, such as object-relational mapping and transactional integrity, are complex."

"Although high-quality developer tools made it easy to create and use EJBs by automating most of the repetitive tasks, these tools did not make it any easier to learn how to use the technology."

Firstly, these things aren't all that complex (complexity is always relative), and its not especially relevant if the design is supposed to be so that the programmer doesn't see what is under the hood. Also tools are similarly irrelevant since they aren't part of the API itself.

Sounds to me like this was written by an "anti", with some token "pro" sentiments inserted, but not thought through. Would be interesting to hear some genuine "pro" perspectives...

Personally I am anti most business software and have little experience with Enterprise JavaBeans (buzzwords, and pointless design patterns and APIs are everywhere!!!)... otherwise I would try to write a correction myself... but it would be a pile of lies!!! :P

I would disaggree with the following perspective (from above) for instance: "if the application is "easy" yo have not to use EJB". I would counter than an application has to be easy enough for Java and EJB for you to use EJB. Java, and by extension EJB, is not appropriate for highly performance critical software... the virtual machine, clever typing system and exception handling render it impractical, as much as these are all good things in other fields (e.g. web interface to a database) where they save you time with cross platform issues and creating a robust and secure solution. Don't delude yourself into thinking this software is either big or complicated because big or complicated businesses use it. More often than not its a pile of trivia...

My two cents...

IMO, many of the most interesting criticisms are criticisms of EJB 2.0 and have been compiled by the authors of EJB 3.0 as a list of what to move away from. The other big source of critisms against EJB 3.0 would be from the "Sessions are evil" camp, which people with the largest scaling needs would be a part of. Eventually you can outgrow even the biggest solitary database for a web application, and once you start hitting those levels, you have to move away from thick web applications to Service oriented architecture (SOA). These criticisms could just as easily be leveled against the biggest competitors for EJB. (SOA isn't a competing technology so much as a design philosophy that calls for many small non-homogenous servers working behind a fleet that itself has minimal business logic). —Preceding unsigned comment added by 67.183.113.131 (talk) 03:46, 9 August 2010 (UTC)

194.168.3.18 (talk) 16:00, 31 March 2008 (UTC)

Rename File linke to Enterprise JavaBean
I think this article should be moved to Enterprise JavaBean instead of using the plural. – Doug Bell talk&bull;contrib 23:01, 22 January 2006 (UTC)
 * The whole technology is "Enterprise JavaBeans technology", the specification is "Enterprise JavaBeans" and the common usage is overwhelmingly "Enterprise JavaBeans" (: 2,000,000 vs : 257,000). Pimlottc 22:52, 16 July 2006 (UTC)

I agree with Pimlottc in that I think the article should be named Enterprise JavaBeans and the corresponding entry for JavaBeans should similarly be named JavaBeans. Are there any comments? --Todd Bezenek (talk) 15:06, 20 May 2008 (UTC)

I've been in the industry for ten years and have never heard anyone refer to the technology in the singular. You can have the object Enterprise JavaBean in the singular, but that has a completely different meaning. The article should be about the technology for interfacing between classes and DB, not about one of the objects which is used in said interface. For example, you could say that Java POJOs with EJB annotations (assuming the 3.0 or later release) work together with SQL connection declarations and the Database interaction framework to form the Enterprise JavaBeans System. However the term "Enterprise JavaBean" refers only to the POJO and not the framework. —Preceding unsigned comment added by 67.183.113.131 (talk) 03:03, 9 August 2010 (UTC)

I moved the article (back) to Enterprise JavaBeans, because that's how it's called officially. The mindless application of some rule that requires the singular for the title of an article would otherwise also require, e.g., Strut, JavaServer Face, and, for that well-known Microsoft operating system... Window. It just makes no sense that way. RFST (talk) 18:28, 22 January 2012 (UTC)

"When you've got a hammer, everything looks like a nail" And of course people broke all sorts of things trying to use EJBs where they really just didn't fit. Creating Spring simply invented another tool. Now Spring is the new hammer. I wouldn't use Spring as the primary container in a large enterprise architecture.

Redirect from EJB Container
I just searched for "EJB-Container", but i was redirected to this page (EJB). Nevertheless, I think it would be a good idea to spent an own article to EJB-Container, not just a redirect. What do you think? (Jochen)

The Name
Those who are not immersed in the JavaCulture won't know anything about the technology from the name Enterprise Java Beans, as the name is semantically content-free. It's cute and all, and that's good for marketing, but what meme is triggered by the name?

Metaphorical Understanding
A significant population exists that is more familiar with Microsoft's offerings. Could someone please add a paragraph showing what in the .NET Framework correponds to Enterprise Java Beans, if any, and vice versa?


 * I know almost nothing about the Microsoft platform, but from what I do understand the nearest equivalent to EJB would probably be DCOM. --Marlow4 20:10, 19 October 2006 (UTC)

ADO's would be a better analogy to EJB's, in my opinion, but I disagree with the need to state this in terms of Microsoft offerings. Microsoft doesn't really compete in this space, from what I've seen. Microsoft owns a large portion of the smaller business website business, but the larger installations I've seen tend to be open architectures where you can mix and match pieces more easily. —Preceding unsigned comment added by 67.183.113.131 (talk) 03:32, 9 August 2010 (UTC)

Architecture Picture
It would be nice if somebody with artistic knowledge could create a new architecture picture that isn't made with mspaint and exported to jpg!

Criticism of EJBs
The History section contains many criticisms of EJB, but doesn't provide any sources to back these up. Additionally, there's are a number of weasel words, e.g. "[EJBs] were adopted more and more by businesses who had become disillusioned with EJBs" and "many programmers found the APIs to be just as difficult if not more so, leading to a widespread perception that EJBs introduced complexity without delivering real benefits". Hertzsprung 12:41, 24 September 2007 (UTC)

I agree, the entire criticism section reads like POV (whether or not it actually is), mainly because there are no citations. Seanhodges (talk) 12:20, 1 February 2008 (UTC)

Currently the old criticism is right at the start of the article in the section "Rapid adoption followed by criticism". It has a NPOV dispute warning dating back to 2007. Since the criticism fully applies to a legacy version of EJB that has long ago ceased to exist for most practical purposes, I wonder whether it's still a dispute. Even outspoken proponents of EJB, like Reza Rahman, 'admit' that the problems mentioned in the criticism section where valid in the days of EJB2 and that later incarnations of the spec have worked hard to address those very concerns. Although even after all this time it's still really sensitive material, I wonder if we can tone the section down a little bit (but don't remove any of the primary points of criticism), make it just a little bit more neutral, and then remove the NPOV dispute warning? Arjant (talk) —Preceding undated comment added 21:40, 16 May 2011 (UTC).


 * ✅ --RoyBoy 04:32, 15 December 2011 (UTC)

Link to JavaBean article ?
This article does not explain whether or not the EJB is related to the JavaBean specification, and if so how. As a newcomer, this is a natural question, and it is surprising it is not addressed briefly in this page. Could someone add it please? --91.84.95.243 17:13, 28 September 2007 (UTC)
 * I heard EJB is a different concept to JavaBean. I really want to see some explaination on this too.  Any experts?  129.65.108.187 (talk) 23:01, 18 November 2008 (UTC)

EJB is somewhat related in form to JavaBean in the 3.0 generation. They are quite unrelated before that. A JavaBean is simply a JavaClass with getters and setters so that you can consider it a simple store of information. The EJB has getters and setters, but the information makes it into a database, whereas for the plain JB the information goes nowhere and disappears when the program ends (unless you have separate code to prevent that). Before 3.0 the complexity of the framework caused a lot of unnecessary complexity in the front end, which is why EJBs looked nothing like JBs in the old days. The reason that EJBs and JBs were both called beans even though they were quite different in the old days is they both are a reflection of the idea that interfaces should be much simpler than the code behind them, so we think of a small amount of well-defined code we can manipulate if we are looking at it from the outside even though there is a larger amount of more complex code hiding behind the scenes. The bean is a pun based on the fact that java means coffee and a bean is a nice little "piece of coffee" you could hold in your hand. Even back in the 1.0-2.x days, the EJBs did a much better job of isolating the complexities than an equivalent amount of direct JDBC code used directly by the data clients would have, which is how they earned the name. —Preceding unsigned comment added by 67.183.113.131 (talk) 03:22, 9 August 2010 (UTC)

Thanks for an excellent explanation - if it's accurate then why not add it to the main page? 62.189.196.126 (talk) 10:42, 24 May 2011 (UTC)

Message Driven Bean advertising
Anyone else think that the reference to Quartz reads/looks to be a shameless advert for the scheduler in an otherwise product neutral section? Personally I think the example should be removed.

62.190.10.139 (talk) 15:34, 5 July 2012 (UTC)


 * I don't think this would be justified. The importance of the example is that MDBs are specified to be used as JCA inflow endpoints, which is a very specific and abstract function that would otherwise be rather hard to explain if it was not allowed to use a simple and real-world example. Of course, I could cook up an example that carefully and artificially avoided the name Quartz, by calling it a "Hypothetical timer service called Ruby", and then copy the example and adjust it for my hypothetical Ruby Scheduler. I couldn't provide a reference then, and somebody will probably remove it all because it's unsourced, original content, etc etc. As I personally put the example there and have no direct of indirect connections with any person or entity related to any company behind Quartz, I don't see how it serves as an Advertisement. Arjant (talk) 17:26, 4 August 2012 (UTC)

Terminology
The very first sentence introduces terms like "managed" whose meaning can be hard to look up. If you look up managed for example you end up with an article Managed code that says it's a .NET concept, so this can be confusing because we are dealing with Java here. Feraudyh (talk) 09:52, 8 May 2013 (UTC)


 * (Container) managed means that the container manages both persistence of data and the (distributed) transactions thereof and the (proxy) instances of your beans and bean interfaces in case that you are using either JNDI for looking up (remote) interfaces or dependency injection, amongst many other things that the container does. Container managed is a term that was coined long before ...net even came into existence. And it must not be confused with managed code. 2003:4C:C002:2:80:0:1:1 (talk) 15:45, 3 June 2013 (UTC)


 * I might be worthwhile to look into the feasibility of creating an article that explains "managed beans" or "container managed". It's a frequently used term in Java literature and applies to not just EJB or Java EE but to Spring and Guice technology among others as well. Arjant (talk) —Preceding undated comment added 12:05, 8 December 2013 (UTC)

Relation to middleware
It would be interesting to see how EJB relates to middleware, what typical middleware features it covers. Also a comparison to CORBA could be interesting. As far as I understand EJB could be used in this way. If that is wrong this probably is not interesting at all. — Preceding unsigned comment added by 85.229.5.2 (talk) 11:27, 21 May 2013 (UTC)

Errors/Incomprehensible Content
In the section on Stateful Session Beans it reads:

[...] If concurrent access to a sializes those requests, but via the @AccessTimeout annotation the container can instead throw an exception. [...]

What exactly does the author try to tell us here? 2003:4C:C002:2:80:0:3:1 (talk) 15:36, 3 June 2013 (UTC)


 * The section you refer to was vandalized or maybe someone accidentally saved a try out. See https://en.wikipedia.org/w/index.php?title=Enterprise_JavaBeans&diff=557123198&oldid=553959268 That edit indeed made no sense at all and I restored it later. It now reads again: "If concurrent access to a single bean is attempted anyway the container serializes those requests, but via the @AccessTimeout annotation the container can instead throw an exception.".


 * ✅ Arjant (talk)