Programming with
a dose of satire.
Programming
|
| ||||||||
 |
 |
|||||||
|
EJB's 101 Damnations |
||||
The purpose of these EJB articles is not to "diss" EJB, but rather to highlight what we feel needs to be improved in order to give EJB a fighting chance of success. Please feel free to share your views here. We're open to constructive criticism of the articles, and will gladly update them based on your feedback...
Message Index:
The Messages: Nice article and a refreshing stance on EJB. Itīs funny how a few people nitpick a few of your points here and there but seem to ignore that there is a slew of problems with EJB. I think itīs a shame that people who should know better often just seem to parrot Sunīs marketing department. I found it to be a fundamentally convoluted architecture with the addition of poor performance. Trying to fix it is pointless. If you follow sound programming principles (which EJB often doesnīt), you usually can do the job quicker and more cleanly. Unfortunately, as you stated, J2EE (a perfectly good tool) is obfuscated with EJB (which I find has very limited practical use if any) and may get some of its forthcoming backlash. Paul Lee pglee@earthlink.net CA Wed Mar 13 03:25:10 EST 2002 Yewww..some one dares to say the truth Hi 101 guys, Iīm really glad to see that somebody in this world is really ready to be against EJBīs when the whole world of AppServers are running towards J2EE (with EJB Support !- Is that OK ?!) From my prj experiences I could see...EJBīs especially the entitiy ones have been a disastrous ones.I could just see that using a "canon for killing mosquito" approach in the entity design.They have included so called blahblahblah features and made that practically worthless.Entities cannot replace what a plain SQL can give us.The bottom line is use plain SQLīs and stored procedures and live happily thereafter...dont experiment with these half-boiled (or overboiled !) component architectures. - Sundar sundar sunda4u@yahoo.com bombay, India Thu Mar 14 10:57:42 EST 2002 Alternatives to EJBs Itīs worth mentioning that there are some commercially viable alternatives to EJBs out there -- ATGīs Dynamo Application Framework is a great way to manage the types of problems Entity Beans were supposed to solve: persistence, transaction handling, distributed caching, etc. in a way thatīs easy to build and highly scalable. Chris Boyke cboyke@atg.com San Francisco, CA, USA Thu Apr 04 19:16:24 EST 2002 EJB Benchmark Benchmark you might want to check out: "A benchmark study comparing the relative performance of five EJB design idioms. You may be surprised to find that a flawed architecture of your EJB application could lead to performance 120 times slower than that possible with an appropriate architecture." http://www.urbancode.com/projects/ejbbenchmark/default.jsp Lee kookamonga76@yahoo.com Tue Apr 23 16:11:02 BST 2002 Some question Away from agreeing with most of the arguments...how do you ensure clustering availability without EJB? Toni Sailer Toni.Sailer@vienna.at Wed Apr 24 11:19:14 BST 2002 re: Some question First, make sure that you really need clustering. There are lots of things you can scale up before you ever need to think of EJB. Look at the numbers involved - i.e. number of users, number of transactions, frequency of database "hits", amount of data flying around, importance of the data & transactions etc. Do the numbers match up to the trade-off that you will need to make in system performance to achieve clustering? A good way to do it is to use the existing infrastructure. SQL Server and Oracle both provide clustering, and are designed to scale. If you need session failover, WebLogic can offer that in the servlet/JSP layer (expect to see your entire app slow down though - there's a definite trade-off between reliability and performance). Depending what your application does, you might also want to use JMS to implement workflows. This will give your app "instant" scalability, and will probably result in an improved architecture. Grid Computing is also worth considering: http://www.gridcomputingplanet.com/ http://www.themindelectric.com/gaia/index.html Clustering support provided by EJB servers is useful, but it isn't the only solution. Hope this helps! Matt Stephens London, England Wed Apr 24 20:58:03 BST 2002 Clustering >Hope this helps. More or less, than of course I (means the customer) really wants clustering. And sure I know that Oracle offers clustering (BTW. how does SQL cluster?). My question was about a clustered server environment with a Non-EJB-Persistence-Layer (e.g. Toplink). How do you manage clustering in this case? What about load balancing of your persistent data objects? (WL clusters via the Home Interface of the EJBs). This is not a EJB-pro posting, just a simple question, how to replace features an EJB container provides. Hops things become clearer now. Toni Sailer Toni.Sailer@vienna.at Vienna, Austria Thu Apr 25 10:24:08 BST 2002 Preaching to the choir... I've been a java developer since 1.0 Beta and have seen Java go through horrors, but have stuck by it. That's changing... EJB might be the biggest scam since "push" technology. 99% of all applications need a simple business layer approach and a good object-relational database model. Servlets as web service using soap (or not) do the trick too, plus you get built in ssl type security over https. EJB is just too complicated to get stuff done on time and on budget. Plus the commercial servers are notoriously slow. I'm curious to hear what people think of the Apache Torque. Scott Fauerbach scott _at_ zenlogix _dot_ com Phoenix, AZ, USA Thu May 16 18:43:13 BST 2002 jvm and app servers how many jvms are there in an app server,may sound a bit odd, but wanted to know this, could any one reply, need clarifications on jvms and appserver interation, as such., thank you anand anandpatwari@operamail.com hyderabad, india Mon Jun 03 10:36:57 BST 2002 re: jvm and app servers Depends on the app server and how it's configured. At a minimum, a Java-based app server uses one JVM. At most, it uses however many JVMs it's been configured to use. Usually, extra JVMs are set up on different server nodes to allow the app server to scale up. This is why EJBs use RMI (remote method invocation). Matt Stephens London, England Tue Jun 04 13:22:06 BST 2002 I DISAGREE!! If it is the lack of knowledge to understand J2EE, why blame Sun of their marketing practices? The J2EE cleary says that it consists of diffrent technologies like servlets,ejbs.. etc under one roof called J2EE . I do not agree with what ever you posted. I have not read all the articles in detail, but thing that caught my eye was that the learning curve needed for EJB is steep. I do not think so. I came from the Microsoft background (VC++ and Delphi) and It hardly took me a week to understand and write an EJB code. Ever since I have been using the technology and I have no complaints. Please do not send a wrong messge.. adam adma@nospam.org New Jersey , US Wed Aug 14 21:45:42 BST 2002 yes good job guys. constructive criticism is most welcome after sun's & tool vendor's propaganda. Coderman Thu Aug 15 12:12:24 BST 2002 Is Sunīs hand over Java to strong? What would happen, if the jcp is managed by an organisation like oasis? Would this foster the quality and advancements of Java specs? When you look at the expert group for the EJBspec (http://jcp.org/jsr/detail/153.jsp) all big players are in the boat and I can't understand why they accept the Non-fixing of (at least) the severest Damnations of the current EJB spec in new versions... What do you think? Kriss Weissmann k.weissmann@gmx.net Munich, Germany Mon Sep 09 13:10:05 BST 2002 Good article One of the biggest problems is that companies jump to adopt the next big tech wave without taking the time to build a prototype of this "new thing" and perform some form of sanity check. I had the opportunity once to be at a client site where the previous consultants used EJB for the application when in reality all they needed was a jdbc solution. That seems to me more of a problem than the spec itself. Matt Virginia, USA Mon Sep 09 18:08:34 BST 2002 Popular Alternatives to EJB Are there any popular industry standard alternative tools (besides ATG)that solve the problems like caching, transaction management, concurrency issues and scalability that EJBs supposedly fix. These tools should not decrease performance though! P R prats74@yahoo.com Mumbai, India Tue Sep 10 19:17:14 BST 2002 This is mostly very dumb. Most of your comments were directed at the fact that there are multiple servers available to run EJB's on, and therefore there is not strictly one way to deploy something. Well, yeah. If you want _one_ way to do things, there's a Washington-based company you could hook up with. They'll tell you exactly what to do and how to do it. Other problems you cited, such as the quality of the reference implementation, shouldn't even be on the list. No one is expecting anyone to use the reference implementation for anything but messing around. No other platform does a better job of abstracting the objects from the database than EJB's. The mythical "Component and Store"-based language you mention doesn't have a name yet, does it? In general, this article sounds like it was written by someone who just discovered EJBs after learning how to program by using VB for several years. I can sense the frustration you seem to be experiencing because you're deprived of your visual environment, and are having to write code to make EJBs work. Get creative, and deal with it. EJBs aren't for children. I've only been using them for a month, and while I find them somewhat complicated, the complexity makes sense. Neil Peart npeart@rush.com Tue Sep 17 17:43:15 BST 2002 A great study on EJB Thank for this EJB resume! You're critics shows that you have worked with EJBs! But I would like to say that EJB 1.0 (i.e. stateless bean and statefull one) work well for me. For myself the problems is coming with EJB 1.1 and entity beans. First of all the event model doesn't fit the reality (i.e. find the keys then find the data / locking / ...). And when EJB 2.0 arrives with EQL than you're ready for abstract computing theory. I just feel that this language is not mature and very difficult to implement for those who programs EJB container. It's gonna be even worse when subquery will one day be release in spec and mandatory! Thierry Giguere gigueret@bigfoot.com Quebec, Canada Wed Nov 06 00:11:37 GMT 2002 On a positive note Having seen companies see an opportunity to improve profits ,and then invest heavily in new business models for a new interconnected world supported with EJB technology - (distributed,component-based with simple OBJECT TO ENTITY mappings ,then it was 1.0), I think I know which side I'd be backing. Give them a good thing and they want more -Complex object to entity mappings. Surely, the key issue here is new business models, business at the speed of thought etc? Sure, if you are making good money doing things the old way then leave well alone. But then, now , you can't even be sure who your competitors are anymore, and what they are up to. Give EJBs a chance . You can probably use a barrage of other technologies to do the same things, but if you can get all you need at one shop...the same applies to learning curves. I hope Sun will take these valid criticisms on board and EJB technology will improve. HS Thomas HelenThomas3@compuserve.com England Mon Nov 25 19:27:26 GMT 2002 Database Engine Architecture For years I have successfully using database engine architecture to solve all the business problem I met. I implemented all the business logic with Oracle database PL/SQL. All the rest are client, I do not care it is VB, Java, Servlet ... It is simple and it works. ---------------------------------- Well I see things from a pure data viewpoint. I found this view is much more simple and effective to solve complex computing problem than OO view. After whatever kinds of computing, the final result is data is changed. It seems SUN design the whole EJB thing, completely ignores there is a thing called relational database. Rui Hu rui.hu@nice-business.fi Finland Mon Jun 23 14:09:57 GMT 2003 Alternative to EJB Hi everyone, I am CTO of Promind Systems Inc. We have developed new application server based on in-memory SQL database and Open Source tools (XML/XSL) for Enterprise Web applications. A/SQL is Relational Application Server. It comes with free Open Source XML/XSL Enterprise Platform. URL: http://www.promindsystems.com Check out Web site - there is loads of info, free download, Flash movies etc. Thanks! Serge Miat serge_miat@promindsystems.com San Francisco, CA , USA Sat Aug 16 00:37:57 GMT 2003 Loose coupling vs performance vs development time I don't use EJB on a daily basis, but I use some of its concepts. Lots of complaints I read in this article are about the time it takes to code and the time it takes to execute. Of course, using direct SQL statements is fast and easy, but what becomes of your application when you add complex rules ? Maybe a SQL join will get me faster to the name of all EMPLOYEE in a DEPARTMENT, but how many SQL statements will I have to modify if I change the definition of an EMPLOYEE name, or if I decide to change the way employee names are stored ? With EJB, development is difficult, execution is slow, but you have a more flexible code. Code that can evolve, that you can adapt to new requirements without changing too much of the existing code. In other words, EJB is an attempt at loose-coupling. Ok, EJB is a failed attempt. But when I read that EJB is anti-relational because it will grab primary key sets as opposed to record sets, I'd say that the writer of the article is anti-loose coupling. Thierry Danard tdanard@yahoo.com Sat Jul 17 04:22:53 BST 2004 Interesting Views I have just started developing with EJBs almost 2 years after this article was written, and it is interesting that some of the points mentioned are applicable while others I have found do not necessarily apply anymore. One thing is clear, EJB's are slow but CMP can be tweaked. Also using a persistence framework can help. I'm currently using Apache Torque with session EJB's, no Entity Beans - the reason is mainly because we have specific database design issues but also this may actually be faster... The other thing that I have found is that using XDoclet and Apache Ant makes life much easier when it comes to packaging and deploying EJBs. I can basically package and deploy my entire application with one command... Also using JBoss means I don't have to restart the server everytime I deploy my application, it is "hot deployable"... On the whole I do agree about some of the misconecptions about J2EE and EJB and the specifications being all vague. Trevor Miller Pretoria, South Africa Mon Jul 19 13:20:52 BST 2004 Empower and his new clothes Interesting discussion, I would agree EJB and dB's don't mix - patterns do exist for Result sets etc.. Also from my experience companies don't change the back end dB that often after much capital\operational expenditure (training, operation processes etc...) One good thing about EJB 2.0+ is the MDB, but other MOM system do exist, with in memory clustering across machines. Having spent the last 10 years designing middle tier system in C++,Delphi & J2EE with a host of technologies, people are too eager to jump of the band wagon and believe the hype. But now J2EE development teams need to cover a lot more scope (deployment experts etc... cost of project hardware). Some how Moores law works, but the poor performance and fatty systems seem to absorb up Moores theory ! Stephen stephen_owen_2001@hotmail.com UK, UK Tue Mar 08 18:43:17 GMT 2005 2006 and it's still sucks Do yourself a favor and just stick with the other J2EE technologies: JDBC, JMS, JTA, etc. David McCullough dmccullough@vuetechnology.com USA Tue Mar 28 23:02:24 BST 2006 Earlier Messages:
<< Back to the Latest EJB Forum Messages |
||||
All trademarks and copyrights on this page are owned by their respective owners.
Stories and articles are owned by the original author.
All the rest Copyright Đ 1998-2005 Matt Stephens. ALL RIGHTS RESERVED.