Talk:Enterprise JavaBean

From Wikipedia, the free encyclopedia

Contents

[edit] 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:
  1. 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.
  2. 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.
  3. 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?
  4. 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.
  5. 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)

[edit] More info about EJB3

It could be intresting having mre infos about EJB3

[edit] 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 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...

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

[edit] 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)

[edit] Spring

Rod Johnson, the guy that started off the Spring_framework is very critical of EJB - that's one of the reasons why he started Spring (called Expert One-on-One originally)

Things do change with time, though; the new EJB 3.0 APIs in many ways more closely ressemble Spring (both use POJOs and support dependency injection) more than the old EJB 2.1 spec (which was rife with required interfaces, parent classes, and checked exceptions). So Spring can be called a rejection of EJB, or an inspiration for EJB, depending on which version you're talking about. --Marlow4 20:51, 29 August 2006 (UTC)

[edit] 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)

[edit] 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?

[edit] 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)

[edit] 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!

[edit] 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)

[edit] 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)