Containers
Today, theserverside.com had a couple articles of interest, one was an open discussion on controller features and another was a web cast on the future of J2EE. Much of the controller discussion was people wanting everything under the sky rolled into their controllers-- tons of complexity and inevitably more XML configuration files. The J2EE web cast was quite reassuring in that top developers on the panel complained that J2EE was way to complex and that 99.9% of the people aren't even using any of the features in J2EE.
In summary, J2EE has tons of cool features but has high hurdles of entry (EJB, WS, JMS), as I like to put it. I look at the new Struts 2.0 (Shale) proposal and see Struts only becoming more complex. Don't get me wrong, business processes are terribly difficult to model, especially when your applications use legacy systems and the features that Shale is proposing would be put to good use, but what about the 80/20 case-- that 99.9% that I mentioned earlier. Is Struts setting itself up for being another, early EJB spec?
I've been developing with Sun's JavaServerFaces team (yes it's hard to believe that I'm actually working on a team for once), and it's because I feel very strongly about JSF and what it provides. Too many times have I repeated to JSF nay-sayers on the forums that JSF is extremely complex, but only if you want it to. I could write one plain Java object and plug it into JSF and have that be my complete application; or I could model a whole controller layer in 50 Java objects that talk to a business layer, etc. You are what you eat, as if it could ever be applied to pragmatic programmers, and I'm comfortable saying that I would use JSF on my next enterprise application (and we are talking about billions of dollars in transactions per year).
I want to take a step back for a moment and talk about those hurdles of entry with Java and the specs people are putting out there. These hurdles of entry can easily be tackled in 3 ways-- learn the spec, use a graphical tool to manage your code, or use a simplified API for that spec.
Learning the spec isn't a half bad idea, but I hate being concerned if I'm correctly connecting to a JMS with a Topic Connection, and it's an every continuing process that the developer himself must be concerned with.
The second option was using a graphical tool. BEA is leading the way with their workshop products that are all drag and drop development. Some may say that takes too much code controll out of your hands if you can't generate the same code in VI or Emacs. The other problem with the second option is that it might commit your whole enterprise application to a single vendor because all your code needs their tool's to deploy.
The third option IMHO is the best option with finding a simpler API to work with. This is something the EJB 3.0 spec is founded on with extrinsic definitions. Other IoC containers provide similar behavior, usually in an external configuration file of behavioral definitions. Spring is leading the way at simplifying development with the hurdles of entry for J2EE by providing simplified Beans that your code can interact with instead of 10 Objects (example is managing connections/transactions to a database with a single Hibernate DAO).
In summary, more work needs to be done to simplify specs or no one will use them. Developers have seen the light and basically regressed to container/extrinsic development. It's declarative, testable, and developers have ownership of the final product. I've been fleshing out a container called 'Strux' which uses annotation listeners and factories to wire components together.
In summary, J2EE has tons of cool features but has high hurdles of entry (EJB, WS, JMS), as I like to put it. I look at the new Struts 2.0 (Shale) proposal and see Struts only becoming more complex. Don't get me wrong, business processes are terribly difficult to model, especially when your applications use legacy systems and the features that Shale is proposing would be put to good use, but what about the 80/20 case-- that 99.9% that I mentioned earlier. Is Struts setting itself up for being another, early EJB spec?
I've been developing with Sun's JavaServerFaces team (yes it's hard to believe that I'm actually working on a team for once), and it's because I feel very strongly about JSF and what it provides. Too many times have I repeated to JSF nay-sayers on the forums that JSF is extremely complex, but only if you want it to. I could write one plain Java object and plug it into JSF and have that be my complete application; or I could model a whole controller layer in 50 Java objects that talk to a business layer, etc. You are what you eat, as if it could ever be applied to pragmatic programmers, and I'm comfortable saying that I would use JSF on my next enterprise application (and we are talking about billions of dollars in transactions per year).
I want to take a step back for a moment and talk about those hurdles of entry with Java and the specs people are putting out there. These hurdles of entry can easily be tackled in 3 ways-- learn the spec, use a graphical tool to manage your code, or use a simplified API for that spec.
Learning the spec isn't a half bad idea, but I hate being concerned if I'm correctly connecting to a JMS with a Topic Connection, and it's an every continuing process that the developer himself must be concerned with.
The second option was using a graphical tool. BEA is leading the way with their workshop products that are all drag and drop development. Some may say that takes too much code controll out of your hands if you can't generate the same code in VI or Emacs. The other problem with the second option is that it might commit your whole enterprise application to a single vendor because all your code needs their tool's to deploy.
The third option IMHO is the best option with finding a simpler API to work with. This is something the EJB 3.0 spec is founded on with extrinsic definitions. Other IoC containers provide similar behavior, usually in an external configuration file of behavioral definitions. Spring is leading the way at simplifying development with the hurdles of entry for J2EE by providing simplified Beans that your code can interact with instead of 10 Objects (example is managing connections/transactions to a database with a single Hibernate DAO).
In summary, more work needs to be done to simplify specs or no one will use them. Developers have seen the light and basically regressed to container/extrinsic development. It's declarative, testable, and developers have ownership of the final product. I've been fleshing out a container called 'Strux' which uses annotation listeners and factories to wire components together.
posted by Jacob Hookom at
1:13 AM
1 Comments:
Yep, Spring is pretty much it!
With a combination of Spring and JDO or other storage, you can build web apps effectively, and run in a lite container such as Tomcat.
This just cuts so much complexity off your app, it's not funny. Imagine if all you had to concentrate on were a few bound JSPs and some simple validation/ workflow control?
Well, it's not perfect as a solution but damn if it doesn't get reasonably close. You can concentrate on the biz requirements, all that awkward config, lookup, JDBC, data access, beanhome and servlet code just goes away.
Check it out if you haven't already.
www.springframework.orgThomas Whitmore
www.powermapjdo.com
By
Anonymous, at 12:24 AM
Post a Comment
<< Home