Programming with
a dose of satire.
Programming
|
| ||||||||
 |
 |
|||||||
|
EJB's 101 Damnations |
||
|
Message Forum - Archive, Page 1 Message Index:
Good grief! Sun needs database-backgroup guys´ help at least Record Level Security We always listen. What you need is CORBA Excellent Article Good Article But what to do now? Look at JGenerator hmm seems like sun knew this all along have a peek at jini programming model ... Yeeesshh! The Messages: Good grief! I have to say some of your comments are so terse that I am not really sure what all the comments mean. You might want to include an example now and then - it would help. Not all of these are related to EJB. You should take some time and "weed out" the comments that have little or nothing to do with EJB and re-organize them in to some special category like "general gripes about things in general" or something. For instance Conceptual 11: "Role based class/method security is rarely useful. Data security is far more important - for example the ability to filter the SQL." This very well may be the case - if I understand what this means. Is the following an example of what you are saying? For instance, if I am an account holder with account XYZ, that it would be nice if there were some automatic security system letīs temporarily call it "role based data security" that would prevent me from being able to access account-related data items that do not belong to account XYZ? This can be implemented. In fact it already has been implemented several years ago - by Gemstone and you could use it with their EJB container. I have three difficulties with you calling this "an EJB problem." First, itīs still generally a database security problem - not a problem with EJBs. What good does it do to solve this in any application space if you can still "get around" the security by going direct to the database? The problem is in passive RDBMS for which SQL 92 does not define a record level access trigger mechanism. Second, while I tend to agree with you - that it is a problem, the wide market apparently considers it only marginally so or they would stop using SQL Server, Oracle, etc, and switch to Gemstone and other active databases. The popularity of RDBMS does not mean that its suddenly an EJB problem. Third, trying to solve the problem as you suggest, "filtering the SQL" can be done in EJBs - so again, there is no real problem. The generally proposed solution is to use what is called an "active database." An active database itself responds to events and can have "record level access triggers" for RDBMS or simply "object access triggers" for an ODBMS. For more information see "The Active Database Manifesto" http://www.ida.his.se/ida/adc/intro.html Conceptual 15: "No proper handling of validation (e.g. String lengths)." This is not a problem with EJB. In fact it is not a problem at all. It can be solved with in the J2EE and EJB environments by generating a database helper class using database metadata or using any number of object-relational code generation tools. See www.javaskyline.com/database.html Conceptual 16: "No proper handling of Enumerated types." Again, this has nothing to do with EJB but has to do with the Java language. There is at least one solution I know of within EJB which was implemented by NeuVis. Conceptual 30: "ACID is not always wanted. For example, a search engine wants high performance, availability, in exchange for accuracy." Again, this is not a problem with EJB. If you donīt want transactions, donīt use EJB. Search engines generally do not need transactions. Write them in something else. The same answer applies to items 26, 27, 13, and maybe 32. But 32 is again very terse and not exactly crystal clear - example please!. 33 has too many questions in one item and again no examples. Conceptual 31: "Perhaps it should have been called TJB, Transactional Java Beans, so that people knew where it belonged." Possibly IBM could have called "CICS" "CITS" instead, and maybe Tuxedo should be called "Transcedo." By your standards only Univac had it right. Their transaction system was called TIP "Transaction Interface Processor." Get over it. In general, there are a number of important questions asked here. But there is more heat than light. Rich Katz richkatz@acm.org Pacifica, CA, USA Thu Feb 14 10:43:21 EST 2002 Sun needs database-backgroup guys´ help at least I just want say one word that sun needs help from Oracle or IMB database architects to hammar out better ways to handle database data access, sun should not be alone striggling in the dark without the help of the DB techology developed in the past three decades, which is good for EJB and sun eventurally. Everyone has its own strength. I bet Sun is not able to come up a prescription of medicine to cure all the diseases even though they know these disease too. john jgf5@dcx.com Thu Feb 14 15:44:19 EST 2002 Record Level Security Actually, the concepts of groups gets more complicated the more you think about it. Take a military organization. Plans by a company commander belong to him, but should be visible all the way up the chain of command. So you would want to have organization a belong to organization b, and everything that belongs to that organization is also belonging to the higher organization: But that company commander has an attached Forward Observer. The person should also be able to see the Plan. So you need some way to allow sharing of the records with someone who is not permanently in the group. We are struggling with this at our company right now; not the military problem, but a civilian variation on it. I canīt blame the J2EE spec for not wanting to touch it...it getīs too tricky. Adam admiyo@yahoo.com SF CA, USA Thu Feb 14 18:55:28 EST 2002 We always listen. We always listen to comments about our company and products. Don´t worry your suggestions are always considered. Stacey Beck stacey.d.beck@sun.com Newark, CA, USA Sat Feb 16 12:35:19 EST 2002 What you need is CORBA Seems like you are looking in the wrong place. There exists a technology that can do most of the stuff you are looking for. Its called CORBA. Either you can make EJB as complex as CORBA and do everything you want or leave it simple and do 80% of what you want. Thanks Sam Jones javadude@yahoo.com AZ, US Tue Feb 19 12:57:38 EST 2002 Excellent Article An excellent article all the way around. As someone else pointed out, yes, even you mix up the EJB and J2EE comments! This is ok by me, as any J2EE server out there has plenty of problems outside of EJBīs only, as you point out. What I find telling is that Sun, on their own "blueprint" (patterns) pages, frequently recommend not using or hiding entity beans! Look here: http://java.sun.com/blueprints/patterns/j2ee_patterns/catalog.html. My favorite is the "Fast-lane reader" - "Accelerate read-only data access by not using enterprise beans." I have to agree with the article - if EJBīs are not fast enough for applications like this, then what is their real benefit? I also have an answer for #86 - holes in the compatibility tests. If you have ever had the extreme displeasure of being forced to work with the iPlanet Application Server 6, you know the answer, too. This beast is full of odd and non-compliant behavior, yet Sun claims it is the first server to ever pass the J2EE compatibility tests! This is a clear case of the tail wagging the dog. Sun is betting their J2EE futures on the iPlanet server - big mistake. All of you, if you ever encounter this sucker in the wild, donīt hesitate - immediately run screaming for the nearest exit. Sun, please, if you wish to retain ANY credibility in the marketplace, develop fair and complete compatibility tests, and apply them just as stringently to your own products as you do to other products. Roger Vaughn rvaughn@pobox.com Tampa, FL, USA Sun Feb 24 23:29:19 EST 2002 Good Article Very interesting reading. My only suggestion is to be more careful when referencing *Entity* EJBs vs. Session or Message-Driven beans. It seems like the article focusses on data-driven applications that are Entity EJB heavy. I agree that is the situation where EJBs need the most work. Personally, I avoid Entity Beans wherever I can, using JDBC for read-only or view data. I am a big supporter of Session beans though, and have had great success with them. Oh, and BTW... The last thing we need is CORBA ;) Stephen Johnson sjohnson@rayva.org VA, USA Thu Feb 28 12:40:36 EST 2002 But what to do now? Hi! At first, we are very relieved that we are not the only company facing those problems. At the moment we are trying to evaluate EJBīs for business purposes. But after two month (and severals application servers and IDEīs) we have the feeling that EJB is absolutly inappropriate for enterprise use. IMHO it is even overstrained by petshop. On the IDE side we face the problem that the development cycle is by far much to long. More then a view seconds are not acceptable. And the cryptic error messages render the development costs unaffordable. If there are error messages at all! And on the EJB side the concept of fetching the primary keys first (IMHO a grotesque idea) forces the developer to shield the user from a entity bean with a session bean that fetches multible rows using a SQL statement. But if we arlready tie ourselfes to SQL why should we take the burdon of CMP? But that is not the only problem as this good article pointed out. Our conclusion: the situation is somewhat disasterous. Now our question: Do you see any way out of this mess? Will time solve all this problems or should we focus on CORBA? Kind Regards, Noel Byron Noel Byron NoelByron@gmx.net Fri Mar 01 04:29:41 EST 2002 Look at JGenerator http://www.javelinsoft.com/jgenerator We define the business at the meta data level, then render out to whatever is needed. i.e. we donīt make any final decisions about what persistance layer to use, we donīt make ourselves hostage to any particular vendorīs engine. In fact with JGenerator you can write your own engines. Lots more demos coming out soon plus JGenerator community edition so that the public can play around with it. User guide here: http://www.javelinsoft.com/jgenerator/guide/ Thereīs loads of ways to scale before you ever think about EJB. Scale up the db, lots of readonly mirrors, more memory, more caching, in memory databases, better database drivers, better pooling, solid state hard disks etc. Let your applications act as use cases, let them tell you what you need. Ignore EJB, tailor your engine for your needs. If you want a HIDEOUSLY fast database try KDB http://www.kx.com Dino. Dino Fancellu UK Fri Mar 01 19:17:44 EST 2002 hmm seems like sun knew this all along have a peek at jini programming model and rio and a better way for entity beans - write a poet like wrapper - we once built a treasury system this way. my other pearls of wisdom 1. look at cv to see if deployment etc mentioned when hiring a guy , if a guy just designs and develops well he has´nt worked in real world if u dont know how to understand real cvs well serves u right 2. look whether he knows SQL well 3. hire slightly senior guys with c++ experience in biz internet scenario even if u have to pay well 4.u will need technical project management to get u thru 5.its true real world ejb skills are hard to find any project manager who is hiring indiscriminately is doomed 6. so are big firms which have ridiculously low salaries. If your compensation is not enough to attract people with real world skills and technical project managers you are doomed to start with 7. hire a small but good team not a huge army Debjani debjaniroyc@hotmail.com Mon Mar 04 10:31:28 EST 2002 Yeeesshh! >> EJB is very transactional - it sucks when it comes to high performance queries, read-only work. "If the only tool you have is a hammer, every thing looks like a nail." So why would you use an EJB for a read-only high performance query. Why not just use a data access object directly from the client? EJBs are great for web applications where a user is typically updating a small amount of data. If I have to do a high-volume read-only query, I certainly wouldnīt funnel that through an EJB. Why do the authors think that EJBs have to be used to solve all computing problems? I had to laugh after reading 2 pages of this drivel, did anyone make it to the end? Jim Dempsey jimdempsey@att.net Tue Mar 12 22:36:17 EST 2002 << 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.