 |
|
 |
|
||||||||||||||||
|
by Bruce Tate | ||||||||||||||||
Don't Make me Eat the Elephant Again | |||||||||||
| |||||||||||
|
When I got an early glimpse of the EJB3 directions from the ServerSide conference and from the Colorado Software Symposium, I was tremendously excited. I've since tempered my enthusiasm, but it's been difficult to put those intangible reservations into words. In this article, I attempt to put some of my initial misgivings into solid, logical arguments.
The Hunt
You see, for me, this adventure has been a rocky one from the beginning. I got dragged, kicking and screaming, into my first encounter with EJB. Everyone was doing it, but until I joined a startup in 2000, I'd successfully avoided the beast. Soon, I was an independent consultant, and I knew that I'd have to bring down some big game to feed my family. I steeled myself to join the hunt, and a messy one it was. I mean, around me was total carnage -- broken projects, stalled careers on top of a stalled economy. I knew that I'd have to work hard to learn the ways of my game. Reluctantly but vigorously, I took on the inevitable preparations, going to monthly classes, reading five best-practices books a day, and even learning UML. At first, it proved elusive, but after months of wandering in the jungle, I finally landed the animal.
Bringing One Down
Immediately after conquering the beast within a real application, I looked upon the carcass with pride. I do admit, I expected it to be prettier. But soon, I could hear my mom standing over me, saying, If you're going to hunt one, you have to eat the whole muddy, bloated, stinking elephant. I mean, you can't just drop it and leave the carcass sitting around. What would people say?" So I ate entities, and gorged on both stateless and stateful session beans. I wrote my book and my courseware, and built best-practices white papers, and consulted. I ate it all. The thing was, I thought that after putting in all of that time, the elephant would sustain me for a while, that I'd be able to make EJB work. I expected to be able to camel those resources, and let the energy boost kick in as I needed it. And I'd occasionally have little victories, but big problems continued to plague me:
I couldn't test the stuff. I know there are testing solutions such as Cactus and J2eeUnit that made progress, but at best, those solutions made an untenable solution barely tolerable. With enterprise systems, automated testing is life.
I couldn't teach the stuff. It took too long to teach the new developers how to hunt. Each new teammate had to pass the initiation, and eat the elephant.
I couldn't escape. If I didn't eat the whole thing, the result was a stinking, rotting mess. Once I carved off that first bite, I was committed. So was my code, and my pocketbook. Also, with each new release, I felt like I had to eat a whole new elephant.
For example, take EJB security. Please. More often than not, I needed instance-based security, allowing me to secure a group of invoices based on their memberships in, say, a department or a division. But EJB wanted me to lock down individual methods or classes. This left me in the untenable position of cramming my own programmatic security on top of their mandated declarative version. Dutifully, though it gave me a little indigestion, I'd invested in the hunt, so I gagged it down.
Another Elephant
Consider EJB container-managed persistence (CMP). While I was hoping to feel just a little satiated, my performance stank because I had to use remote interfaces and had no access to the relationships that could have let my relational database do more of the work. So I was forced to use bean-managed persistence, which is kind of like bringing your own fitness machines to the health club. And then, just when I began to feel like a survivor contestant that had been pushed too far, my jungle guide pointed to another, seemingly cleaner, tastier animal in the distance, called Elephant 2.0. Right away, I knew that I'd eat that one too.
And I stalked it for months, and like many customers, I never really completely brought it down, but I stunned it enough to start dining. And I ate: CMP, MDB, JNDI. And life was a little better, especially on the persistence front. But while I was slogging through six files to do simple persistence, my friends were laughing and dancing around their POJO applications with ordinary JDBC. And they were doing much more, with much less.
So I got newer, more powerful equipment: XDoclet, a high-powered elephant gun; Cactus, a kit that let me check each byte of elephant for disease before I put it into my mouth; and a newer IDE, which is kind of a chocolate sauce for elephant. And I was actually able to force the ever-expanding bites of elephants down, but it was getting old.
Walking Away
So I simply walked away from that voice in my head and the plate that was never quite empty, and immediately began to feel better. My books went from Bitter to Better (Better, Faster, Lighter Java should be in book stores and Amazon right about now.)
I want to be clear here. I respect the original elephant hunters (and inventors) for bringing enough of the industry together to settle on a standard. In fact, the original hunt was based on sound principles: we needed to introduce services outside of the scope of our business logic. In fact, some people will still only be able to eat elephant; some problems are best solved with EJB. Some can live with the inherent limitations, to achieve the benefits. To those people, I say: more power to you.
But usually, I don't have to feed a whole tribe. I just think that the hunt is targeted, sold, and used in many situations that don't call for an elephant. And when you oversell it, and force-feed too many customers a steady diet of elephant, bad things happen.
So I learned to serve other game to my paying customers. We even deployed enterprise applications on Tomcat. We slimmed down the number of physical tiers, and used POJO persistence with JDBC. Other times, we used Kodo or Hibernate. Often, we needed a few token EJB session beans for declarative or distributed transactions, but I had a feeling that other technologies provided a better answer for declarative transactions, too. I dabbled in Aspect-Oriented Programming (AOP), but didn't really feel that it was ready for me or my customers.
Finally, I discovered the simplicity of declarative transactions in solutions called lightweight containers, Spring in particular, and my evolution was complete. Call it chicken. Sure, it's bland; it takes on the flavor of the food that you prepare it with. And that's exactly the point: you can more readily adapt it to your intended purpose. Since there's room on your plate, you can choose other dishes to serve with your chicken. And chickens are a heck of a lot easier to hunt than elephants.
In truth, I expected chicken to be a tougher sell. After all, it's an open source, er, free range, project. It's also younger than the typical elephant. And "Chicken Hunter" doesn't look nearly as impressive on a resume. But I was wrong: it couldn't be easier to sell. Sure, there is a learning curve, and a new set of problems, but I like eating chicken better than an elephant. My customers like the taste, and they don't have to eat it all at once. They can bite off a little plain (POJO) persistence, dabble in inherited context for testing, and nibble around AOP for declarative transactions. I've noticed that in my body, the benefits are immediate, and powerful. I'm leaner, faster, and stronger. I could have chosen Pico, maybe with Keel, or soon, HiveMind, and I'm convinced that the benefits would have been similar.
Another Animal Emerges
So what do I see skipping around in the jungle, but a huge, elephant-sized, four-legged cheeseburger? Boy, does it look tasty. Could that be EJB 3.0 written on the bun? In fact, for EJB 3, the expert group has worked hard to pull some of the best ideas from other hunters. We'll see POJO-oriented persistence, built explicitly for the relational database model (much like Hibernate). We'll also get to use POJO façades, like we do with Spring and Pico. Now, that's a change of diet that I can live with:
I can test my objects outside of the container. In Better, Faster, Lighter Java, I suggest that testability and simplicity go hand in hand. In fact, I believe that automated unit testing is the most significant process enhancement that we've seen in the past five years.
I can achieve full transparency, with respect to a service. In short, I can code in a POJO style. Without a doubt, the most important feature (in terms of productivity) for a persistence framework is transparency. EJB3 will bring POJO-style programming to EJB, and not just for persistence.
I have an easier strategy to deal with metadata. JSR 175 lets me include metadata, stuff that I used to have to put in unwieldy deployment descriptors, into my source code, without forcing me to put that data into my class proper.
The four-legged cheeseburger will finally sustain me, won't it? Could it even taste good? I really want to like this beast. It certainly looks the part, from a distance. So I should feel happy, right? But my stomach has been uncomfortably churning with memory, and I'm hesitant.
As I get a little closer, I have my suspicions that the huge cheeseburger in the jungle is actually an elephant with a couple of huge buns and a few condiments strapped on. Sure, the condiments will make it a little easier to choke down, but will you still have to eat the whole thing? I'm just a tourist hunter. I didn't make the elephant, so I don't have a full view. If I get the details wrong, forgive me. But from here, I see a few problems:
The Composition of the Standard
The best standards have a single purpose and vision. As with applications, effective standards build layers with progressively broader abstractions. Ideally, I'd like to see an EJB architecture that defines how to produce, package, and consume services from models formed of ordinary JavaBeans. That is the fundamental job of EJB, isn't it? Abstract away the crud that's necessary for the enterprise, so that you can better focus your code. Avoid the need to rewrite each service by defining a standard way of consuming those services. You could still build an elephant, if you're sure that you need one.
The problem is that the first cut at the EJB3 standard tries to also define the services that we will consume. Perhaps my biggest fear is that EJB3 builds yet another persistence standard, from scratch, that splinters the market and forms a barrier of entry against the next Hibernate or some current quality solutions like JDO. In fact, why tie EJB persistence to any framework? Why not allow pluggable persistence, and allow the ORM community to continue to evolve and innovate?
I see three vibrant persistence communities with successful niches. JDO (with more than 20 relational products and less than five purely non-relational products), Hibernate, and POJO code-generation strategies are all persistence approaches with solid justifications and strong followings. In fact, SolarMetric's Kodo has hundreds of relational customers, many of them with clustered high-volume deployments. And as I write this article, there's no JDO representation in the expert group. In short, I'd rather see EJB define how to package, produce, and consume services, rather than define exactly what those services should be.
In fact, this approach of defining a service within EJB is fundamentally inconsistent with the rest of EJB: for messaging, EJB lets another standard define messaging, and it embraces the standard. EJB customers would be better served if EJB3 allowed pluggable persistence, or separated another service. Similarly, EJB embraces existing standards for the expression of metadata, and the management of transactions. I know that it goes against the motivations of the J2EE application-server vendors, but it's in the best interest of customers to let them choose the packaging that makes the most sense. Let vendors bloat their packages with as many services as they want. Just don't force me to buy the whole thing to do enterprise development.
J2SE 1.5
The proposed EJB3 enhancements will tightly couple EJB to J2SE 1.5. I'm all for the latest SDK, but most customers just aren't ready yet. In fact, most of the larger companies lag two years or more behind the latest JDK. Heck, a whole bunch of them are still running J2SE 1.3x. Howard Lewis-Ship still supports JDK 1.2 for Tapestry, because his customers demand it.
But EJB will require JSR 175 (.NET-style metadata), so you will definitely need SDK 1.5. This coupling will probably mean that EJB3 will not see widespread adoption for at least one and a half to two and a half years. And there's real pain now. But the real problem is that once again, I have to eat the whole elephant. Or, I have to wait two years or more. From where I sit, neither is likely to happen.
The Metadata Philosophy
I greatly appreciate the effort of revising deployment descriptors, and XDoclet sometimes does feel like a little bit of a hack. But I don't think that we know enough about JSR-175-style metadata usage models to be betting the EJB3 specification on that technology. On the .NET side, it is unclear whether this style of programming will become the norm. You can also find many knowledgeable developers in the community that think the EJB approach to metadata may be flawed. Active threads on TheServerSide and blogs on java.net point to potential problems. (See the references at the end of this article.) For example, perhaps binding metadata to source code is even moving in the wrong direction by actually coupling code that used to be independent to metadata. Also, it looks to me like the injected metadata will bind you to the container. In short, I'd much rather see best practices emerge before we standardize.
So that's where we are. When I land this four-legged cheeseburger with buns, I need to swallow a new persistence model, JDK 1.5, and a whole new, experimental metadata model, all in the name of improved productivity and simplicity. That's a huge, gaping mouthful. Explain this to me: why wouldn't I just continue to eat chicken? And why would the market opt for two to three more years of these maddening gaping mouthfuls, when in the end, they may find yet another elephant hiding beneath those buns? And if this EJB3 turns out to be better on the digestive system, wouldn't moving to chicken first make an easier transition?
Some Hope
Fortunately, some independent minds within the JCP, like Richard Monson-Haefel, are working hard to add real sanity to the persistence space. Some recent threads in cyberspace point to the desire to have the JDO and EJB3 expert groups work together. It looks like there's been serious movement on both sides:
-
Some in the EJB3 expert group, such as Richard Monson-Haefel, are willing to discuss the option of moving persistence into a separate JSR.
Some in the JDO group, such as Bruce Snyder and Patrick Linskey, are willing to move JDO as far as it needs to go to support EJB3.
If it proves inadequate, some in the JDO group have expressed willingness to build a new standard for J2EE POJO persistence.
This first step would be the most important, and the most significant. It would consolidate persistence for J2SE and J2EE under a single, complete standard for the first time. (JDO might have been that standard, but did not address object-relational mapping.) It would allow a cleaner model for integrating alternate persistence solutions. It would also unify the purpose of EJB, as a platform for producing and consuming enterprise services. And it would free customers who are struggling with CMP to move forward in a safe direction, since it looks like CMP will be supported only for backward compatibility.
As for me? I just don't want to eat a whole elephant. Please, don't make me eat the elephant again.
References
-
Better, Faster, Lighter Java: Just released, this book makes a case for simplified development, and lays out five simple principles for better, cleaner designs. It then looks at two open source projects, Spring and Hibernate, and looks at how to integrate those into better Java applications.
-
" Persisting Problems": This blog and post make the point that persistence should be broken out of EJB3. Some of the industry's most respected developers, including members of the JDO and EJB expert groups, agree.
-
"What's Wrong with @Inject", and the corresponding discussion: This article makes the case that the EJB metadata implementation may not be ideal.
Bruce Tate is a kayaker, mountain biker, father, author, and Java programmer in Austin, Texas.
 |
View all java.net Articles.
Showing messages 1 through 24 of 24.
-
EJB3 is not an Elephant
2006-03-13 17:25:26 andrig [Reply | View]
I think you have gotten some things wrong about EJB3. First, EJB3 persistence is pluggable. There is a service provider interface that has to be implemented by the provider. The provider is specified in persistence.xml. This allows the persistence provider to be swapped out at will.
EJB3 is also supported in J2SE, it doesn't tie you to the application server. In fact, I have written an application that is started from a main method of a Java class that uses a Stateless Session bean, and three entity beans. All of the EJB3 capabilities are there, with transactions and persistence. You can even do message driven beans, although I have not had the need for them.
EJB3 also doesn't do away with things like Hibernate. Hibernate is infact, the persistence provider for the JBoss EJB3 persistence implementation.
You also talk about testability, and since EJB3 is not a heavy component model, but simple annotated Java objects, you can use all the normal tools for unit testing. In my case, I have been using Eclipse's standard JUnit integration to do all of my unit testing, and it works very well. There are some tricks to make it all work, but they are not very hard to overcome.
On the topic of binding meta data to implementation classes, I have had some of the same uneasyness that you describe. Is this really a good thing to do? After actually building a couple of applications though, I must say that I have fallen in-love with the annotations, and not having deployment descriptors is great! When you think about it, everyone has been binding their meta data to their implementation classes all along anyway. Since no one really did EJB development without XDoclet, you were putting your meta data into the implementation classes their anyway. The only difference is that you have a pre-processor that generates the deployment descriptor. Big deal! While with this approach you could certainly still change the generated deployment descriptor to change behavior, it would be out of sync with the code. This leads to all sorts of trouble. Besides, you really couldn't get the benefit of being able to change descriptors without careful packaging considerations. For example, you would have to do an exploded deployment, otherwise, you would have to rebuild your application to get a regenerated war, jar, ear, etc. I never found the separation to be very useful in the first place.
Another thing to consider is that with EJB3 all of the patterns that everyone was using can really be tossed out the window. For example, transfer or value objects become a completely unnecessary thing. You just implement Serializable on your entities, and you can use the same POJO through all your application tiers.
I could go on and on, but in summary, EJB3 is finally what we have been looking for all along. It truly makes Java development on the server side easy. Now on to the unification of the web tier. Check out JBoss Seam for that. Talk about another lead forward!
-
Be a vegetarian, itz good for health
2005-03-03 11:02:27 hephaestion12 [Reply | View]
May be we don't have to eat the elephant. Because, as a software engineer we have already ate enough throughout our life.
Now, we should practise on how to ride the elephant. All the body parts of elephant were consumed enough throughout our life. It looks big now because, all the body parts were put together into a running machine,
Follow buddism and don't eat meat,
-
CORBA; The other big game animal
2004-06-21 06:47:06 tpiselli [Reply | View]
So what was I eating when I was writting CORBA applications? Its been fun to watch the industry shift to different distributed computing technologies through the years. I still use everything I learned back in the CORBA 2.2 days and smile when people today "discover" things I learned by trial and error years ago. Oh how I miss the days of writting IDL files and running them through an IDL compiler. Hunting chicken just isn't the same.
Tony
-
Elephants? More like a blue whale...
2004-06-17 12:20:14 gperreault [Reply | View]
About 2 years ago, someone told me that in order to do my job, I would have to program in java for the web, but, not to worry, it too was an object oriented language and the transition from C++ would be a breeze. What they didn't say is that to get anything done in web java, you have to learn at a minimum 5 concepts; java, JSP, XML, HTML, ant. And that does not include the servers such as Tomcat, WebLogic, Sun One, etc, or the myriads of IDE that popup every 6 months or so. Furthermore, we still don't have struts involved here, nor EJB or even all the requirements of manifest files, classpath, intricacies of JVM class loader, class visibility, parameter files, and the virtually hundred of support packages that have become standards of some sort.
And to top it all, someone had the cruel idea of pretending that javadoc would be the ultimate, final, decisive repository for all the documentation necessary to use a class in a package. Of course, interdependencies and prerequisites are too much to hope for. Example are a no-no since java is so self explanatory anyway.
So, maybe some of you have decided to become elephant hunters. Well, for some of us, the enterprise decided that everyone would be eating whale, and they made sure there would be plenty around for everyone. So, while you talk about new standards and improved ways of doing thing, all I see is new poorly documented package making their way to my desktop and my work environment with a mail message that they are now the "standard du jour" which we will use from now on.
Please, just stop it! Take a break. Go on vacation for 2 years. Put a freeze on code change. Let us finish the first whale before you give us another one.
Sincerely,
Fed Up.
-
Elephants? More like a blue whale...
2005-02-15 03:40:08 stuaxo [Reply | View]
Yes it's true the whole J2EE thing put me off programming; but then the IT bust happened so I didn't for a while, now I'm doing J2ME via php I can tell you it's so much nicer to do something that doesn't need about 8 different frameworks that change by the month!
(Well j2me has its own problems, but I prefer these kind of problems!) -
How to get good at creating Java CGI real fast
2004-06-17 18:02:27 rickcarson [Reply | View]
HTML takes about half an hour to learn the basics. If you want to do advanced stuff, you can always (er, usually) look at the source to see how its done.
Once you know HTML, learning the basics of XML takes about another 5 minutes. Learning all about parsers and doms and all that could take a lot longer, but if you know some basic Java String manipulation, you can fake it from the 5 minute point (minus, it may (or may not) be more 'brittle') (plus it will run a lot faster, and if you wrote it it should be easy for you to maintain) (NB: the String class does the heavy lifting) (NBNB: this is in the context of small chunks of XML passed around as 'messages', not huge 100mb databases, mkay?)
Once you know HTML and Java String manipulation (ie what you get for free on the String class, not the abomination that is regex), it is a very very short leap to Servlets. The big hurdle for Servlets (and, in fact *all* web programming) is that they are stateless.
There's just no getting around this. Even with things like ASP.NET you still need to get over this hurdle. Its hard. The good news is, that everyone else has to jump the hurdle, and that in Java there is an easy way to do most things, so its the only real hard bit. (You can self inflict painful ways of doing things on yourself if you want - see JSP and all the myriad of JSP frameworks, masochists only need apply)
Use Apache/Tomcat/Netbeans to get up and running with Servlets fast. Most other Appservers are a collossal pain in the butt to install and configure (on the order of *weeks* as compared to *hours* for Tomcat).
As a programmer, you will probably find it easiest to do your HTML layout in Tables. Go and learn the table, tr, and td tags now if you don't already know them. You might also want to have something like a menu or menu bar, so in your next coffee break pick up an HTML book and learn frames.
Avoid JSP (why learn three languages (Java + JSP + HTML) when two (Java + HTML) will do???). Avoid any of the frameworks that build on JSP.
Learn JDBC. If you know SQL and ODBC this should be fairly easy. If you don't know SQL, invest in an SQL prototyping tool (such as MS Access - you can quickly mock up your tables, and then drag between them till you get the query you want, and then copy and paste the SQL into your code. If you don't know JDBC, look at the vendors help files for how to configure and call their particular flavour of JDBC driver. (NB: do not use any MS database to *store* your data - MS Access is flaky, and SQL Server likes to corrupt its indexes)
Total Time:
Time taken to learn Java + Time taken to grok stateless programming + 1-6 hours.
Todays lesson:
(a) JSP sux
(b) there is an easy way to do everything, use it
(c) JSP sux -
How to get good at creating Java CGI real fast
2004-06-21 07:13:07 gperreault [Reply | View]
Sounds like my wife when she tells me it will only take a morning to paint the whole outside of the house. 1 hour for each length sides, 1/2 hour for each ends. With a good sprayer of course. Total time 3 hours.
-
Entity-based security
2004-06-17 07:50:39 bill_cchkk [Reply | View]
Very interesting article, Bruce. I especially appreciated the quote about instance-based programmatic security in EJBs. We have an implementation of this for a J2EE project, but it's very specific to our application. Do you know of any more general solutions to this problem? Or is it one of the issues to be resolved in EJB 3.0?
I read up on the Spring framework, and it does not appear to address this problem. Did I miss something there?
TIA,
- Bill
-
A clean sheet of paper and no agenda
2004-06-17 05:03:29 dancres [Reply | View]
A key difference from my perspective is that a lot of the lightweight containers etc. have been able to start with a clean sheet of paper. This allows them to avoid legacy design constraints and make use of more recent technology.
In addition, many of these people only ever had the intention of trying to make things better. They don't have an agenda defined by the fact that they have an existing product which they'd like to see people continue to use.
-
Five books a day?
2004-06-16 14:36:40 homam [Reply | View]
Bruce, did you mean you read five different books in their entirety each day or switched between five different books everyday?
-
pressure from the little guys
2004-06-16 12:49:18 conwaym [Reply | View]
I have strong hopes that pressure from some of the IoC/Lightweight container advocates, as well as the Hibernate types, is registering with the vendors on the JDO and EJB3 JCP bodies. I'd much rather be able to advocate a complete and workable standard than endure endless religious battles in-house about who'se framework is better. If J2EE can just do something REASONABLE with persistance, we all benefit, and the standard can advance.
I don't buy that dependency injection versus JNDI means all that much to your typical developer, it's way too much 'inside baseball'. I do think it's a huge hole that you essentially have to ignore big parts of J2EE (thru crummy CMP persistance) and do something non-standard...
A lot of dissing of J2EE at the end boils down to CMP. If that was not an issue I don't think IoC would be getting that much attention. That's not to say those interesting ideas, AOP approaches, etc. don't have a place in the standard, it has to grow and evolve. An industry standard with wide vendor support and a healthy open-source community keeping it honest is what we need.
I think, tho, that I want to take 'pragmatic' back...With a workable CMP and JDO implementation (work that out guys!), and backing by the vendors, you won't worry about eating the elephant, I'm afraid that the elephant might eat you!
Cheers,
MC -
pressure from the little guys
2004-06-16 14:15:28 batate [Reply | View]
Excellent comments. Let me see if I can provide a counter argument, in the spirit of the article.
Note this article is about EJB, and not J2EE. I actually think that there's a whole lot about J2EE to like. I especially like the way that you can scale your complexity. If you want to use messaging, you can...otherwise, just leave it behind. Not so with the container.
I do think that there are real differences between proposed EJB and Spring. They all relate to productivity:
- Metadata strategy. I like the Spring strategy better. It does not bind you to the container. Improved flexibility usually leads to better productivity down the road.
- Pragmatic exception management. It's much cleaner in Spring. You can do as much with less effort.
- Elegant facades. Check out a Hibernate facade in pet clinic, one of the Spring examples. You'll be able to do the same with JDO.
- The packaging. Spring makes it easier to leave behind parts of the framework that don't fit.
And I could go on and on. So it's not all about dependency injection. It's about pragmatic and simplified decisions, that the authors of Spring made over and over and over.
I've bet my career on Java. I'm just not willing to tie it to EJB any more. In short, I don't want to eat the elephant. There are great elephant hunters out there. And now, there will be a few more elephants for them. -
pressure from the little guys
2004-06-16 15:17:36 conwaym [Reply | View]
I have downloaded Spring and AspectJ together, I play with it at home when I'm not playing 'Reading with Pooh' with my kids. It's neat stuff. But if you have a shop with 100 programmers just getting into Struts, this does not even rate...J2EE to many (and the wise, I would suggest), is really about creating a .war file with struts and jsp's, and getting it deployed. App servers can in some fashion be considered tools for sysadmins to cluster, deploy, and monitor all of this stuff so it doesn't go down when a disk crashes. Then you have a full suite of 'stuff' to handle what comes down the pike. I expect MDB's, as well as the 'extraJ2EE' concerns such as workflow and integration will get much greater use where I work. Standards like BPEL and stuff like WS-security are big items of interest, we can all only digest so much...
Add to that a decent POJO persistance layer (we have TopLink right now), and the complexity that's spoken of in J2EE doesn't really touch the developer once you can create a decent .ear. We need a workable EJB3 and JDO, it doesn't have to be model-pretty, just not suck. I could make this a one sentence post by just saying that again...really we'd be gold if we could have that. I'll live with JNDI, call me a trog! I've been happily using JTA/Stateless Session EJB's for some time now, and only after being told at the server side and NFJS that it was 'heavyweight' do I realize I've had problems all of these years! I say that facetiously, because I value and am interested in things in AOP and Spring. I also know I don't know what could happen down the road.
In TopLink, for example, I can either let it wrap my code in transactions, or tie into the underlying JTA if I need to, so what does IoC really do? Is no JTA 'light enough'?
I don't claim to be a pattern junkie, but if I write a bunch of beans, with a bunch of setters for the dependent objects, I'm expecting and externalizing that something is going to set all those up for me. In that sense, am I not actually dependent on, and commiting to IoC containers? How the heck are those dependencies going to be resolved otherwise? If I drop those beans into Tomcat, it doesn't know what to do with them...right? You need the framework and descriptors of your choice. That might be belaboring the point, but once you commit $$$ to a project, you need some assurance that it will be relevant a year ago (I know, IoC and you are all pure POJO and everything is good, I will alow that can be argued).
Too bad there is not a standard for IoC containers you could bank on...maybe that will be J3EE or J4EE. My point here is that I want to have patience with J2EE and Java. I started out soon after the bouncing heads doing Cafe and dbAnywhere, and even as bad as jdk1.0.2 and the awt blew chunks, we wowed a bunch of external consultants, which was gratifying. Java and J2EE has always been waiting for your particular API to be...shall we say 'corrected' in the next release, and I'll do that because I need and believe in Standards. Even if there are parts that don't quite fit the bill, the payoffs have been enormous. In many senses the choice on Server side Java has been a bullseye that we hit here from about 6 years distance. In retrospect it's been fairly incredable how we're still running code that was originally developed for the server in JDK1.1. Part of my problem with IoC is not technical...I don't want the standards fragmented because that's worth Pico, Spring, and HiveMind together!
Anyway, keep IBM and Oracle in line! Just chiming in for your 'run of the mill' developer.
MC -
pressure from the little guys
2004-06-16 15:29:16 batate [Reply | View]
Ahhhh...a mighty elephant hunter. To such a warrior, the hunt would not seem so difficult.
I do understand your perspective. To you and those like you, I say the same thing that I tell to happy poeple who ask me if they should adopt a persistence framework that's new and interesting. Keep pushing what you're using. Ride it into the ground. Push it until it breaks.
(I bet O'Reilly gives me somre strange breed of elephant for my next book.)
Take care.
-bt -
pressure from the little guys
2004-06-16 17:00:34 conwaym [Reply | View]
Sure...
I'm not carying on the thread here other than to say I attended some of your stuff at NFJS at RTP. I'd be the first to recommend the 'Bitter' books or the NFJS series...excellent..and to check out Spring at
http://www.springframework.org/
I don't think you can call yourself a complete Java geek without getting your hands dirty on IoC or AOP!
Cheers,
MC -
pressure from the little guys
2004-06-16 19:13:17 batate [Reply | View]
I remember you well. Your comments in my session, and those here, are well reasoned and logical. I like practical thinking. I'm dead serious about using what works for you. Others may not have had such a good experience with EJB.
Take care.
-bt -
just to say
2005-10-24 05:56:03 ceddup [Reply | View]
"But if you have a shop with 100 programmers just getting into Struts, this does not even rate...J2EE to many (and the wise, I would suggest), is really about creating a .war file with struts and jsp's, and getting it deployed"
Is it me or Spring does look just like Struts did a few years ago?
I think we shouldn't forget that a thing is easy to learn because it is simple and well designed, not because it's old and has a lot of documentation!
-
Arn't Elephants on the protected animals list?
2004-06-16 12:32:04 zander [Reply | View]
I think that means that we should outlaw Elephant Jinxing and Butchering!
Oh; wait, this is not the greenpeace website?
 java.net RSS Feeds
|
