Talk:Jakarta Enterprise Beans

--112.135.112.37 (talk) 10:04, 20 August 2014 (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•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" ("enterprise javabeans": 2,000,000 vs "enterprise javabean": 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).

 Done --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.".

 Done Arjant (talk)