Whats Wrong With Ejb
Whats Wrong With EjbWhat's wrong with EJB is that it's being marketed as a technology that "reduces time to market for mission-critical applications, effortless scalability and portability, reduced reliance on hard to find developer skill sets, and an overall increase in developer productivity.", but is in fact all lies. The message is coming with a book-thick specification that is so complex that it must lead to buggy code. -- LozPit?
Sounds like there's a bit of touchiness there... :) Anyway, I have to agree with you in principle. The technology solves some real problems, but it's not "so easy a child could do it". EJB's are starting to suffer from AllPanaceasBecomePoison.
MartinPool has been asking me why I am only lukewarm on the EJB specification. My reason is that it depends too much on MagicCoincidentalReflection, instead of language features.
Firstly, the create(args) methods that are defined in the EjbHome. These are mapped to the ejbCreate(args) methods in the EjbBean. I presume the way this works is that the EjbBean is instantiated using a default constructor, and then exactly one of the ejbCreate methods is invoked, i.e. that whose args matches those given to the create method. Using standard language features, there's no guarantee you (the developer) will get the implementation of this right. I know because you are a smart programmer you will, but what about other people? Alternative ways to design this would have been for the EjbHome to delegate those calls to an EjbBeanFactory, which implements the same create methods. Then the EjbHome and the EjbBeanFactory could implement a common interface, constraining them to be the same at compile-time. It would also have been better (I believe) to map the create functions to constructors. (If you map create to constructors, you wouldn't be able to pool and reuse instances of EJB. Also, the meaning of create is different for Sessions and Entity beans -- RafaelAlvarez )
The second complaint is also about objects coincidentally implementing the same methods. The EjbRemoteInterface? extends EjbObject and adds additional methods. The EjbBean implementation implements SessionBean or EntityBean, and also those additional methods. Obviously the functionality that really matters to the developer is the additional methods. The developer probably has a very good understanding of those methods, and may even have them defined in an interface. He probably should have them defined in an interface, and no doubt thinks of them that way. However, EJB doesn't refer to the business interface implemented by the bean at all, except as additional methods luckily implemented by the remote interface and the EjbBean.
If this interface were explicitly named (e.g. in the descriptor), we could be more sure that the EjbBean implements the remote interface. The EjbContainer could also automatically delegate invocations on the bean to an implementation of that interface which knows nothing whatsoever about EJB.
These are fairly minor complaints compared to the value of a standardized component infrastructure. But I just wish it was a bit nicer.
-- JohnFarrell
The EJB specification does not forbid the EjbBean from explicitly implementing its remote interface, but strongly discourages it, presumably because one usually do not want to leak the EjbBean reference outside the container. This does make the programming model somewhat strange, like passing the remote reference instead of this for callbacks.
The EjbRemoteInterface? is explicitly named in the DeploymentDescriptor?. At container generation time, the EjbBean is indeed checked to implicitly implement that interface.
The biggest complaint I have against the EJB specification is its rather heavy weight programming model, which makes it difficult to decide on the granularity of the beans.
-- KaiYu
Another reason why you wouldn't want your bean to implement your Remote Interface is that the remote interface extends EJBObject. This means that you would have to implement all of the methods in the EJBObject interface! You don't want to be doing that in the bean. A simple design pattern gets around this problem:
-- Dion
It is always difficult to find the right granularity in an OO-design, especially in distributed applications. In CORBA the objects delivering services are usually kept as coarse as possible and I think this also applies to EJB. It's not wise to have lots of fine-grained objects floating around in your distributed space.
So yes, the EJB programming model is quite heavy, but considering that Beans are usually very coarse, that doesn't have to be a problem.
-- RichardSmol
Using constructors to implement ejbCreate() with different signatures is not a good idea, based on the fact that it is very expensive to construct new objects. The EjbModel? allows the EjbServer to pool instances of Ejbs for reuse whenever needed.
-- عvindMathesonWergeland
I'd be surprised if that was true. On a modern VM, allocating an object takes a few instructions; initializing it takes more, but that's all being done in ejbCreate anyway; collecting it after it dies costs more again, but the overall cost is still really quite low. It's certainly less than the database hit that accompanies every ejbCreate, and so it wouldn't really add much to the total cost. Someone correct me if i'm wrong about this.
-- TomAnderson
You are correct that the cost of object allocation/deallocation is mostly irrelevant, despite persistent superstitions in the Java programmer community. That's not the benefit of Pooling EJB instances. A session bean (for example) will almost always require resources to do anything useful. Since you'll likely do something like look up a DataSource? or another EJB upon "creation" that's where the pooling payoff comes. Most JNDI implementations are mysteriously and inexcusably slow even within the VM, so we can't afford the lookups upon every remote interface method call.
EJB's biggest problem, for me, is that it uses the CORBA/RMI style of forcing your code to catch and handle loads of exceptions (actually, javax.rmi.RemoteException). If you're doing things right, you can easily end up with a whole try/catch mess for every remote method invocation. This is also, and originally, WhatsWrongWithCorba. JavaSoft just ripped it off for RMI, and didn't sort out the mess when they did EJB either.
The result is, frankly, messy code. It's very hard to make your code clear, simple and easy to understand when the few lines that actually do something are smothered in many more lines of hideous nested exception-handling.
I think in Smalltalk this would be much cleaner (I think - my Smalltalk knowledge is very limited) because the exception handling is so much cleaner and less invasive.
ObjectSpaceVoyager? is the only CORBA ORB / EjbServer that I've seen that gets it right: it bends CORBA and EJB so that you can catch all these exceptions if you wish, but you don't have to. In other words, they've actually delivered on the "transparent distribution" idea that CORBA etc didn't quite manage. The result is that you can actually write clean, simple code that other people can understand.
The RMI philosophy is that forcing try-catches of remote failures is a feature that is necessary for robust distributed computing. JimWaldo?, the chief architect of RMI, has long been an advocate of explicit distributed computing. The philosophy is that local-remote transparency is a myth, so don't try and pretend the network doesn't exist in your software design. It may look like 'cleaner' code when you write it, but it will run cleaner code at runtime if you actually deal with the issue of distribution properly and explicitly.
I find it kind of interesting that this page doesn't mention a major failing of EJB compared to explicit transaction control. Generic EJB is always going to be slower. This is okay if you want to do financial transactions, but lousy if you want to use it for web applications (which many people do). Many people want EJB, only to find out after they have it that they really didn't want it in the first place.
-- WillSargent.
What do you find slow about it, per se?Is it the spec itself, or a particular app server? If people use EJB as a crutch for justifying poor design, then yes, I could see it as slow. However, since you mention explicit transaction control as faster, I'm curious: assume you have someone who isn't just arbitrarily demarcating all of his/her business methods with TX_REQURES, or is using RMI calls fine-grained methods. Why would it be slow then? Using client-demarcated transactions is a big trade-off with more dimensions than just performance.
EJB does not encourage good design - that might be its biggest failing. Then again, neither does COM+. They are not substitutes for expertise.
-- StuCharlton
Stu, you're right in that someone who knows the model well and knows the trade-offs will have equivalent performance. However, EJB is marketed as a solution which "takes all the complexity" away. Knowing EJB well and knowing when NOT to use it is more complex than learning EJB itself. Until proven wrong, most people will go for the least complexity possible and then wonder why their application is syncing to the database on every assignment.
I suppose what I object to over EJBs themselves is that they are marketed as a silver bullet instead of a tool.
-- WillSargent
I still maintain that WhatsWrongWithEjb is it's design-by-committee complexity. This is most apparent in it's transactions which are way too complex and offer too many models and types. The ComPlus model is simple and cleaner. Also, because of it's design-by-committee approach we have the same situation as Corba with different vendors implementing different services and vendors unable to speak to other vendor's implementations. If you use one Application Server today to serve up your EJBs it won't run on another without changes.
-- sg
I think we'll have to agree to disagree on this. I find EJB tremendously simpler than COM+. And CORBA. Though CORBA is a different sheep, since it tries to do *everything*, including curing world hunger (I think there's a CORBAfacility for that around the corner...)
COM has a lot of history behind it - as a technical trainer, I find that while COM's philosophy is easy to explain, actually explaining how to use it requires a lot of arbitrary tidbits of knowledge related to its evolution. Contrasted to EJB, I can rationally see and explain a lot of the reasons behind why they did things the way they did.
Furthermore, most of EJB wasn't necessarily design-by-committee... it was driven heavily by 2 architects within Sun, with input from several Java licences. The Java community process is quite lightweight to the Object Management Group that controls CORBA.
Also note that J2EE is intended to help this portability problem, and so far it actually seems to be working.. EJB 2.0 also includes a pluggable persistence manager to actually allow realistic (and potentially portable) container managed persistence.
I'm not a huge fan of EJB - there still aren't enough tools to really take advantage of off-the-shelf business components, it doesn't give you enough exposure to the underlying server (if you want it), and it leads lazy people to believe that they don't have to put *thought* into their designs... On the bright side, it has really done wonders to the competitive landscape... the number of choices available is great!
-- StuCharlton
Here's what I have been trying to warn people about is a huge flaw in EJB:
Slightly off-topic: Is Goodhew talking about this interview with Gosling? http://www-4.ibm.com/software/developer/features/gosling/index.html If yes, where does he say that? If no, which one does he mean? -- HaskoHeinecke
How about this interview with Gosling: http://www-106.ibm.com/developerworks/features/gosling/ (search for the word 'goofy').
Glad you asked. (I think you misunderstood the question. I've rephrased it, so the answer may no longer seem appropriate.) I had been meaning to come back and clarify that statement. Here's the part I mean and why I think EJB is not a good solution "Roger got the relevant section out of the Enterprise JavaBeans [EJB] specification, which talks about permissible vendor extensions. Not surprisingly, the vendor extensions include things like transactions management, which is fairly important in building enterprise systems, as well as security, messaging, and more. In an article, Sessions lists roughly eleven areas of functionality, which are vendor specific implementations that are permitted. So, if you pick IBM Websphere as your EJB implementation, the code that you write for your EJB application will inevitably lock you into Websphere."
It's that vendor lock-in that concerns me. It's the exact same problem with the Corba spec. Anytime, you leave things like this unspecified, vendors create islands. In our EJB development at Viridien, we were locked into BEA WebLogic and it wouldn't work on WebSphere. In contrast, COM is an exact binary specification and MTS/COM+ are exactly specified. All of this is moot anyway. DCOM, Corba and RMI are going away, thank goodness to be replaced by XML, SOAP and HTTP, as it should be. Internet standards. IBM and MicroSoft, and many others are behind SOAP. MicrosoftDotNet is in that direction. The Internet always wins. I'm glad MicroSoft finally woke up.
-- sg
So... to avoid nasty vendor lock-in, go with MicroSoft. And to avoid getting rained on, jump in the river. -- GeorgePaci
It's too complex. -- CimarronTaylor
That too. The ComponentObjectModel and MTS are a far more simpler and elegant solution.
-- sg
That's a matter of subjective opinion. I find MTS and COM to be a horrible morass of hacks turned into something barely understandable. I find recent moves towards .NET to recognize that COM on the server isn't going to take over the world because no one wanted to COM with C++... C# on the other hand...
Some of the more complex parts of EJB, like the division into several types of beans was something that really opened my eyes on how to use MTS. It seems to me like MTS/COM+ is just as complicated as EJB, but it hides the complication. For example, COM replaces RemoteException by returning error codes that must be handled explicitly, or (more often) just ignored. There is still the issue of lifetime and uniqueness of COMponents, just like session beans vs entity beans, but again, MTS leaves this for the developer to find out and implement. Q.v. CarHoare on complicated systems. MTS is just as complicated, it just obfuscates that fact better.
-- JohannesBrodwall ("I just don't wanna have to handle memory any more. My head hurts!")
The j2ee and EJB specs are suffering heavily from PatternOverdose and this results in AccidentalComplexity that will hurt many systems and developers committing today to j2ee and EJB hypnotized by marketing hypes.
The alternative being ?...
COMplus, MTS, DotNet.
COM+ certainly has it's level of AccidentalComplexity. MTS is COM+. And DotNet is beta. They're alternatives, but they've got plenty of their own problems.
Other alternatives: AllaireColdFusion, WebObjects, GemStone (using pure objects, no ejb), AtgDynamo
see also PatternAbuse -- PeterSommerlad
The way I right now are building web applications are by using languages as interfaces. I write my servlet in Java and communicates with the database using SQL (JDBC works fine). From the Internet I receives a bunch of parameter-variable-pairs that I've turned into a sort of language. When building the response page, my servlet generates XML which is processed with an XSL that the design people have written.
Thus I have above used Java, SQL, XML, and XSL, all open standards that cleanly divides the application. What are the benefits of EJB/JSP over this? I've tried understanding J2EE, but maybe I'm to much a language person... -- MartinBergendahl
That's OK - a lot of people have problems seeing the value through the hype. Here's at least a partial answer to your questions:
(1) JSP offers a better separation of view (HTML) from controller (Servlets and Beans) than just using Servlets to output HTML. Of course, JSP is not unique in this way - this same idea (code template tags) is the heart of ASP, AllaireColdFusion, and a number of other technologies as well. As to why it's better than XSL - well, I'm not sure it's better, it's just an alternate way of doing the separation between controller and view.
(2) EJB offers two things (in my mind) that none of the technologies you've mentioned offers; (a) Unified transactions across multiple data sources (Oracle, Sybase, DB2, MQSeries, etc...) and (b) Scaleable object distribution. Sometimes these are very useful things to have. For instance, if I want to build an N-tier system that might have many different client types (Application, Applet, Web, WAP) then having a single point of contact for my domain logic (object distribution) is a good thing. Of course, again EJB is not unique in this space; COM/.NET and CORBA also offer these, to greater or lesser extents. However, it's the best way in Java to get these benefits.
Regarding MVC separation in HTML-based Web apps, I would argue that JSP (as well as ASP, PHP, ColdFusion, etc.) lends itself towards greater muddling of view and controller (and often model) given the breadth of the API and how most people utilize that API. Although such separation can be done if your team is disciplined, most real-world JSP apps I have seen tend to have a heavy mix of business logic (and often direct db reads/writes) in what was planned to be used for presentation only. The older and bigger the JSP app is, the more muddled it seems to be (creeping towards Big Ball Of Mud). A cleaner approach to such separation is to use one of the many template engines, such as Velocity, WebMacro, Freemarker, etc., for the presentation layer of your Web app. These templating systems have very narrow API's geared specifically towards presentation, and thus are better able to keep the app's core rules (and data model manipulation) out of the HTML templates. -- Jeff Lewis
Look at this excellent "EJB from a critical perspective" by Philippe Mougin from TechMetrix? and the following discussion at http://www.techmetrix.com/trendmarkers/tmk1299/tmk1299-2.php3 and http://www.techmetrix.com/trendmarkers/letters/archiveletters/ejb/letejbindex.php3
"What's wrong with the EJB 2 Specification" by Tyler Jewell from BEA at http://www.onjava.com/pub/a/onjava/2001/02/28/ejb.html
People on TheServerSide are discussing it at http://theserverside.com/home/thread.jsp?thread_id=4658
Note that this is outdated now that the EJB 2.0 final spec 2 has been released.
JDO seems to be better proposition for object persistence than EJB. there is a "Java Data object vs EJB" discussion at http://theserverside.com/discussion/thread.jsp?thread_id=771
Sorry if this offends, but ADO.NET is looking interesting for persistence. Not burdened by the overspecification problem that affects with EJB EntityBeans. Includes support for hierarchies, relations, offline (disconnected) manipulation. Developers define Select, Insert, Update, Delete methods on a ADO.NET DataSet. (Sounds like EJB?) Has anyone else taken a look?
This paper contains a critical discussion about EJB in the context of web services and business objects: http://www.orchestranetworks.com/us/solutions/0105_whitepaper.cfm
Let me assume that people here already know the essentials of EJB and the arguments against it that it isn't OO. I have found EJB makes sense when providing coarse-grained services (Session) and coarse-grained objects with many relationships (Entity). I don't care that the decomposition isn't pure OO - no silver bullets, remember? The fact is that service layers make sense when doing a distributed application. You can't pretend that network latency and load aren't there when you make your model unless you don't mind your application performing abysmally. When developers use these types of methodologies in local apps (as I do) we do it to manage complexity, knowing that there is a run-time cost, but believing that it is minimal compared to the savings in maintainability, extensibility, and so forth. But our network infrastructure is not now in such a state that we can ignore its effects. We are in the AppleII generation of network apps, and it is appropriate that we are still having to take explicit recognition of our infrastrucure in our application design.
As for the whole "EJB is another form of vendor lock-in", well, I have ported j2ee apps from one server to another. Not without some pain, but in a reasonable amount of time. I even once had to port an app that had been written against a home-grown CORBA implementation of most of the EJB spec to EJB, and that was somewhat worse. But it was possible. Tell me where I am going to get almost all or even most of the MTS spec implemented on another platform please. When a client has huge new demands and wants to move to Unix for stability etc., how am I going to port this MTS app without starting over? Now the case for Mono is another thing altogether. Java is by no means without faults, and I hope that six years of market reality and design evolution have produced *something* of an improvement. When these new technologies are mature enough for actual use, say 1 year plus past beta, then maybe it will be worth taking a serious look at them. But anyone who is talking about moving to .NET based on the output we have so far is smoking their stash. You can tell the pioneers by the arrows in their backs.
Here's the problem I have with EJB: It tries to do too many things and fails at them all. First, we have stateful session beans: Nice idea, but in practice, almost nobody can use them. Why? Too slow, and the notion of state is too limited. Ok, how about stateless session beans: Nice idea. But wait, can't I do the exact same thing with RMI if I wanted? The answer is yes. And, without all of the BS overhead that EJB imposes. In fact, RMI can be used to provide both stateful and stateless type objects with minimal overhead. And guess what? Almost all of the application servers on the market scale RMI just as well. In fact, this is a given, because EJBs simply sit atop of RMI.
RMI isn't perfect, but its not bad. It gives a nice, simple, remote interface for Java. I like it. I've used it a lot. What about transactions? Sorry, I do this myself. I very rarely have to synchronize transactions across multiple data sources. And that's a kicker too, ain't it? That's EJB's entire notion of transaction: Databases. Honestly now: How many of you are doing cross database commits? Probably not many. Thus, almost all databases on the market have the built-in notion of transaction that is needed. (This means that JDBC gives you all of the needed transactionability you'd ever need). If you really need complex transaction management, then use JTA. It's much nicer.
With Java 1.3 and up's ability to Proxy calls I can very easily create my own transaction framework in about an hour that handles tracking changes to any object that's tagged with a designated interface and I have significantly more control.
I hear these things all the time:
- Threading is complicated: Yeah, but it's something that complex systems may use. If you don't understand threading and can't create your own thread pool in about an hour, you should get another job.
- Database connection pooling: Gosh darn I hear this a lot. Guess what, since Java 1.3 I can create a completely transparent database connection pool in about 30 minutes. Easy as cake. Want to know another little secret? My connection pools are orders of magnitude faster than the best application servers. Especially WebLogic, which is a total piece of crap.
Let's face facts: If a company is going to hire a bunch of CodeMonkeys then J2EE and EJB seem like a great idea. However, if you've got any talent at all, most of J2EE will make your skin crawl. Stay away if you can. -- JeffPanici
What about transactions? Sorry, I do this myself. I very rarely have to synchronize transactions across multiple data sources. And that's a kicker too, ain't it? That's EJB's entire notion of transaction: Databases.
I've got to take issue with one of Jeff's points. EJB transactions aren't just about databases. They haven't been for a while now. For instance, with WebSphere I can now have a single transaction cross DB2 or nearly any other popular relational database, MQ Series, CICS and about a half-dozen other EIS systems that have JCA connectors. That is powerful. Sure, you don't need it a lot, but when you do, it's really useful.
-- KyleBrown
The claim was and remains incorrect. You can do distributed transactions without having to program to the EJB model. The JTS API for distributed transactions is available through independent implementations related to JMS, JDBC, etc. -- CostinCozianu
SeptemberZeroFive. Earlier this year, I queried and got response from Kyle (who authors books on WebSphere and unfortunately is no longer active). He said at the time EJB was the "only way". Now he could have meant "only sensible way" and CC claimed that he is technically incorrect. -- dl
Well spoken, Jeff. There is one element I perceive to be a major part of EJBs that you did not address, however. What about scalability, especially clustering. Would you rather want to do clustering on your own, or would you use WebLogic if you really needed this?
For another write-up of the same views, see Tim Hyde's post on general@jakarta.apache.org: http://www.mail-archive.com/general%40jakarta.apache.org/msg03376.html
Kyle, I grant your point that if you need cross data-source (or external system in the case of CICS, etc.) transaction management, EJB gives you a head start. However, I would still have to evaluate EJB as a solution in such a hypothetical situation. Also, not knocking WebSphere, but implementing a session bean that wraps a CICS transaction in WebLogic, JBoss, or other application server isn't quite as easy. So, some of your point varies on which application server you happen to use, not what EJB provides out the box, per se. My point here is: How much plumbing does IBM provide on top of EJB to give you those features? (In fact, doesn't WebSphere essentially rely on CICS and simply provide EJB compliant interfaces to the user?)
As to the scaling issue, I'd simply say that - if you're using EJB for what I've seen 100% of projects try to use it for - it's overkill and too costly. I'll qualify that some more: Almost every project I've seen, and that's a fair number, that think they should be using EJB are building CRUD systems for something. That's it. These are replacements for CICS/COBOL systems written on the mainframe (3270) or RPG programs written on the AS/400 (5250). I can scale web applications like this with IP load-balancing, Apache, Tomcat, and JBoss' RMI container. I have one RMI object that implements a drop-in replacement for HttpSession for centralized state management (if session management must be fail-safe, I will back it with some kind of persistent store, like a database or serialized file, etc. This doesn't happen very often either).
I'd like to point out that I'm not against "application servers", per se. I think having a centralized place for certain kinds of functionality makes a lot of sense. What I am most strongly against is trying to create marketing cruft on top a perfectly good remote standard for Java: RMI. Jini is really what Sun should be pushing, not EJB. But Jini is something that engineers see and say, "Wow, that's really awesome. It solves all of these problems so elegantly!" And managers say, "Gosh, I'm going to need real engineers to use this Jini thing. They'll actually have to plan the system out and not use code generators...I think I'll take a look at this EJB thing."
Finally, I'd like to say that I really believe that all of this is meaningless anyhow. I've been building several Smalltalk applications over the past few months using GemStone and I can say: J2EE is like Fred Flinstone's foot-mobile. GemStone works equally well for Java, as does Poet and a host of other - dare I say it - OODBMS products. I say this because, this is what object developers want. We want our objects to live on the network and be portable. Scalability here is simple and elegant. J2EE, if it is to survive and truly simplify our development lives (and our client's bottomlines, because this is where it really matters), will have to grow up to this kind of a solution.
EJB is a phase, and the market will outgrow it. We can come back here in two years and see if I'm right. -- JeffPanici
After writing a book on EJB and studying its evolution, I think the market (and Sun for that matter) has lost sight of the original goal: reusable components. The whole hype around server-side business components built around a framework or a language seems to have dwindled. The core concept of re-using and composing components out of other components hasn't died however, it's just in the form of WebServices talking XML to one another, keeping the underlying component as simple as possible.
So assuming that EJB has failed in its mission of providing reusable components to the masses, what does it give us that helps us?
After using Oracle for a while, I've come to some conclusions: Oracle is excellent. It's fast, it's scalable, and it does a lot for DBAs. It's just a pain to integrate with objects ... O/R mapping tools have been trying with limited success... but it can work, there just needs to be more progress in this area. ADO.NET in particular has some interesting ideas for creating an object graph out of SQL calls. After working with a TOPLink+Oracle project, it's hard to go back to hand-crafting SQL calls.
-- StuCharlton
Your comments on the reusable component aspect is interesting. I've discussed this with many colleagues, and we've all come to the same conclusion: it's a pipe-dream. Here's why: Do you really think that - say - Zurich, IBM, and BankOne? would all use the exact same "Customer" component? If they did, what would that say about their intellectual property and how its controlled? You see, each business wants to think their way of handling customers, orders, deliveries, accounts, etc. is different. This is something they use to differentiate themselves in the marketplace, no matter how crazy it may sound to the software engineers of the world. In my opinion the entire component model push came from VisualBasic, which proved that there is a market for certain kinds of developer-centric component reuse. However, the rub here is that the domains one tends to find "componentized" are things like widgets, credit-card processing/bank transfer, etc. Again, companies want to believe that they are unique with respect to their core domain objects, which negates the possibility of a reusable domain component market.
We're on the same page. Keep in mind that I don't claim RMI or Jini to be perfect solutions; only better for the types of application that I see people building. And that's part of my gripe with EJB - indeed, the J2EE picture in general - it presupposes that one will use all of the specified technologies; though Servlets with a templating engine (WebMacro), JDBC, and a dabble of RMI, if necessary, is sufficient for most CRUD type web applications. Again, I'm not against frameworks that work and make life easier; something I find EJB failing at. Your point on AspectOrientedProgramming is well taken and I whole heartedly agree. But, again, this is something the market will likely see as too complicated.
Keep in mind, I don't assume that the market will accept any current OODBMS system. What I am proposing is that the technological concepts in use here will migrate to some market accepted platform - JDO perhaps (but probably not). Also, I've never used GS/J, but I think GS/S is very flexible and high-level. Sure, its not perfect; nothing ever is. However, I can build applications very fast using Smalltalk and GS/S. As a side note, Poet is a very powerful and high-level Java/C++ OODBMS product. It does support high-level indexes and full SQL and OQL. It's a fantastic product and I highly recommend it.
This brings me to my last point: Why, as professionals, must we always kowtow to the whims of those who don't know any better? If Smalltalk, Gemstone, Poet, etc. is the answer, we need to show the market this. Instead, we buckle under and use whatever fad tool comes along. I admit, until very recently, I succumbed to this pressure as well, but I've really been studying my marketing as of late and I feel strongly that there is more than hope for Smalltalk and products like GemStone. Just like ExtremeProgramming promises a way to better software development, I think we, as the people developing these systems, need to show our preferences. I'm going to better articulate myself on TimeToChange, drop by and see if we can start a revolution. -- JeffPanici
I agree about the reusable business components being a pipe dream. I've always sort of felt this way, though I think intra-organizational reuse was a good possibility, with EJB and J2EE, and probably someone has delivered on this in some small form from time to time.
Regarding J2EE: I don't agree that it presupposes the use of *all* its technologies. The J2EE blueprints talk about lots of different combinations. J2EE doesn't make my skin crawl, - in fact I'm very happy it exists at the very least to provide the standard deployment formats (EAR, WAR). Servlets+JSP with the JakartaStruts framework is an excellent choice for developing everything from simple CRUD to complex web system. I've used it with great success, and it's *fun*. The general movement towards JSP tag libraries is a positive step, one mirrored by ASP.NET - both standards seem to be approaching the level of innovation that WebObjects was at back in 1998. <grin>
How true is this? TIBCO sells a JMS implementation, without providing anything else from the J2EE platform. I don't know if it is J2EE certified, but... Anyway, as an ex C developer, C++ developer, CORBA developer, i jumped in the Java space and find J2EE too much heavyweight and verbose. I worked with WebLogic/Oracle, and the performance were so bad (Sun Enterprise E10000 servers) that we ended up by developing our own database service classes (sort of) with load-balanced RMI support instead of using BMP or even CMP. The reason ? There is more than one way to update/delete/insert into a database, and we got much better performance on relying on database features, rather than making a generic all-purpose class. And i do not see how anything generic can be faster. Also, much more stuff should be declarative within the code or deployment, with no knowledge about the resulting generated code (that should be completely hidden within the application server itself). I am actually trying the .NET stuff which at first sight looks much more clear to me. And i begin to believe that the competition between the J2EE vendors will slow Java progress so much that Microsoft will provide better application server implementation than anyone else (and believe me, i do have no shares in Microsoft corp.). As far as they (or any third-party company) port their CLR to other OS than Windows, they will get more marketshare in the mid-frame segment. -- Christian
As for "why can't we change", well, I'll leave that to for TimeToChange, but I think "we" are in the minority. Most people don't agree with our opinions of what is 'better'. I get heckled as alterno-man at work for the simple fact that I even know Smalltalk and Objective-C.
More cynically, I would also suggest that most managers don't want to hire programmers that can write their own thread or db connection pools, they want to hire cheaper programmers because people that can write those things are too expensive. Hence, the paradox of tremendous business interest vs engineering cynicism towards EJB. -- StuCharlton
If EJB strikes you as over-engineered, difficult to design & code for and not very much like Java itself, take a look at EnterpriseObjectBroker. -- PaulHammant
Just reading all this should tell you what's wrong with EJB. Simplify your lives and use .NET.
This is a false dichotomy.
Jeff - I agree with your critique, if not the details of your solution.
Until recently, I had a strong feeling that EJB existed for purely political reasons - i.e., to give companies like IBM a profitable stake in Java.
What happened recently is that, working on an opensource project with EJB programmers, I got a strong whiff of deja-smell. I was flashing back to years of dealing with mainframers.
EJB is a monolithic welfare state - oh yeah, it'll do a zillion things for you. But the overhead is outrageous.
And the creativity disappears: the beautiful thing about Java (and other OO languages) was that, even without going to eXtremes, the roles of designer and programmer became inseparable. There's no such thing as an "OOP coder" who can ignore the architectural implications. But the division of "roles" in EJB recreates that classic mainframe caste system.
What I loved about the original JavaBeans was the ideas of mobility - objects could migrate to the most efficient location in a distributed system - and unbundled services orthogonal to each other. With EJB, that's all gone.
And the attitude becomes - if you don't use EJB, you can't have database integrity, or transactions, or threading, or you'll have to reinvent the wheel, etc. Anybody out there who's old enough to remember what it was like to propose distributed computing in a corporation with a mainframe priesthood should be familiar with this mindset. -- TomRossen
Okay - I'm not the first one to see the connection to IBM and mainframes. In EnterpriseJavaBeans somebody said,
EJBs look like a Microsoft style territory grab by Sun. It will sell big boxes like Windows sells fast PCs (which is why Sun and IBM are in bed).
and somebody else said,
All these issues result from the mistake of doing things in the wrong places. They are then partially solved by building very heavyweight physical and logical infrastructure, which sells huge application servers and huge boxes to run them on, i.e. back to the mainframe model of computation.
I think this is regressive.
-- TomRossen
http://www.softwarereality.com/programming/ejb/index.jsp (EJB's 101 Damnations)
I'm surprised that no-one has mentioned this problem with EJBs: they require so much boilerplate code. This is extremely inelegant, and basically turns my brain to mush just looking at it. Yes, I know it can be generated, but you've still got to live with it. Thank goodness for XDoclet. But the fact that XDoclet had to be written suggests there's something very smelly in the EJB spec.
Java itself is a stoic and painful language IMO. It would be so easy to create a better syntax with more programmer-friendly features that still compiles to the same .class files (i.e. the language would be functionally equivalent). The "Nice" (experimental) language does this, AFAIK. JDK 1.5 goes about 20% of the required distance to drag Java into the 21st century, and it's sad that we had to wait this long.
But back to EJBs: the Java language should change to better support what they are trying to do. Imagine that: one group of people putting in that bit of extra effort, to make hundreds of thousands of lives easier. EJBs are ugly, and have other problems described above, but they are useful. -- GavinSinclair
EJB development is difficult, without a doubt, but once beans have been developed, bean clients are the beneficiaries of a clean enterprise object API. The trick is - once a design has been created - to build the beans themselves. There is a lot of boilerplate/plumbing work to do, just to get an EJB "Hello, world." up and running. A lot of complex coding and configuration conventions must be followed, and many kinds of mistakes can't be discovered until deployment time. Deployment itself can be a burdensome extra step in the frequent edit-run development cycle of an agile process.
But EJB is the way it is mostly because of its proposition: ambitious design goals tempered by implementation constraints. A distributed component infrastructure is inherently complex, no matter the component model, if client transparency is to be provided. Building components made even more difficult when constrained to a general-purpose programming language like Java - witness the greater complexity of CORBA development and its IDL abstraction.
But distributed infrastructure need not be complex. See for example: ErlangLanguage, which is amazingly simple. Unfortunately EJB puts together in one basket distribution, transactions, half-baked object persistence, concurrent execution, and the bundling of all these together breaks SeparationOfConcerns.
The real question of EJB should be: is it more complex than necessary given its proposition? What is there in EJB that is arbitrarily problematic, and not explainable as deriving from trying to reach its goals while using the Java language?
Something like EjbQueryLanguage. And the whole CMP specification.
It's not enough to say "this looks a lot harder than what I'm used to" without asking "how would I do this more simply?". For those considering its use, the first question should really be "how does the EJB proposition align with my needs?", followed by "do I really need a 3-tier deployment architecture?".
A 3-tier architecture does not necessarily need EJBs.
If you do choose EJB, you'd be nuts (or shortly driven so) if you choose to build EJBs by hand. As in any situation where you find yourself writing boilerplate, cookie-cutter code, it's time to use a generative tool. For EJB, such a tool would minimally generate, from a simple specification or model, the home and remote interfaces (and their local counterparts if needed), as well as much of the bean class, of the specified EJB components. For anyone who are repulsed by code generation, recall that this is just the time-honored approach of creating a high-level little language when the usual one is insufficiently expressive. Maybe the EJB spec. should define one, but it's already big enough.
Even with an EJB generator, you may still find yourself writing a lot of boilerplate if you mistakenly ignore EJB Entity CMP and go with BMP (or worse) for persistence of non-legacy enterprise data. But direct database programming, repetitive though it may be, is still a habit that many developers seem wedded to, even though very few of them do it well. But I digress...
-- PerisBrodsky
In some of the above, "EJB" and "J2EE" have been used as if they were synonyms. They are not; EJB's are just one of many technologies that are gathered together under the J2EE umbrella. Not that J2EE is simply a marketing term: there are real architectural principles that underly all the J2EE technologies.
For example, just because you are using J2EE does not at all mean that you are obliged to use Entity EJB's to do all of your database accesses. JDBC is one of the J2EE technologies, and you can certainly call JDBC directly. (At the most recent BEA user conference, there was a good talk about the different ways to access database systems, comparing and contrasting and illuminating the trade-offs.)
Raw EJB technology is indeed hard to use. To make it work you really need appropriate tools. Just for starters, hand-editing an XML EJB Deployment Descriptor (ejb-jar) with a raw text editor is clearly no good. Real J2EE app servers include interactive tools for building these files (such as BEA's "Builder"). Another (better) approach uses code annotations; see http://www.beust.com/cedric/ejbgen for example. And then there is the more aggressive approach taken by something like BEA's WebLogic Workshop, which really takes care of all the boilerplate and lets you focus on the substance. (I'm trying hard not to sound partisan here; I just happen to be familiar with the BEA technology and I'm sure there are other good approaches.)
The substance of it is treated in EjbFlaws. It is unlikely that Cedric's doclets or BEA's wizards can get you through EjbTernaryRelationshipExample. The EJB model has flaws by design and will have to be abandoned sooner or later because of competitive pressure from Microsoft and the alternative Java solutions from the open-source community.
Regarding "vendor lockin", it's not a bright-line binary thing, as if either you are or are not "locked" in. It's a matter of degree. Moving code between J2EE app servers isn't free, and it can't be since J2EE intentionally leaves many decisions out of scope. But it's very much easier than moving between Microsoft's technology and anything else.
The Roger Sessions quote above confuses Java language portability (the claim that a program written in "100% Pure Java" should run on any conforming Java VM (of the same version!) with a strawman claim that any EJB can be transparently and effortlessly moved between two different Java app servers. Of course these are entirely different claims. This is really so simple that one wonders whether Sessions really misunderstands it or not.
By the way, if anyone can track down evidence that James Gosling said that Java's portability goals/claims were "goofy", I'd be curious to see it. The hyperlink above doesn't work, and I can find nothing like that on the IBM DeveloperWorks site. I wonder if this is apocryphal, and if not whether it is out of context, or whether he was calling "goofy" some other claim, or what.
-- DanWeinreb
See EjbFlaws.
krish wrote:
ejb is not a good one,instead of this we can use Spring,it's having inbuild ejb..
EditText of this page
(last edited November 22, 2014)
or FindPage with title or text search