Jesper Boeg on Priming Kanban
In this interview, Jesper Boeg, author of the new InfoQ book – Priming Kanban, discusses the keys to using Kanban effectively, and how to get started if you are currently using other approaches.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Is Java EE 5 lightweight enough?
Posted by Floyd Marinescu on Jul 07, 2006
Steve Anglin distilled the the problem to a simpler question: "Is the new lightweight Java EE 5 light enough?", and turns the conversation to questioning whether organizations care about standards or alternate light weight frameworks:
...how important are standards to your client’s and/or company’s requirements these days? For example, the Spring Framework and Ruby on Rails may not be considered standards compliant. At least, Sun, JBoss and others don’t think these are, and that Java EE 5 is standards compliant...Standards keep specs and implementations stable, secure, and keeps these from going obsolete... Which [stack] do you prefer?
Steve is inviting people on his blog to comment on their favourite stack, add your thoughts. Comments so far were that Spring is standards compliant, that standards tend to be driven by tool vendors to sell more product, etc. Similar discussions were had on the future of enterprise Java panel, and the role of tools vendors in standards definitions also emerged in a discussion between Craig McClanahan and others in an InfoQ thread about Struts and Shale parting ways. Accused that JSF's purpose is to drive tools vendors, Craig clarified:
JSF apps can be hand authored just as easily as apps in your favorite action oriented MVC framework. JSF was, *in addition*, designed to make it easy to support with tools. The proof is in the pudding ... besides the existing IDE support for hand authoring JSF apps that is equivalent to what you'll see for frameworks like Struts, you also get to choose from IDEs focused on visual development if you like that approach.
RelatedVendorContent
Improve Java Garbage Collection, Runtime Execution, and JVM visibility with Zing
Getting Started with Stratos - an Open Source Cloud Platform
Monitor your Production Java App - includes JMX! Low Overhead - Free download
Using Drools? See what you're missing! Get the Power of Drools with the Assurance of Red Hat
Lightweight?
by
Billy Newport
Posted
different strategies for different times?
by
Floyd Marinescu
Posted
Re: Lightweight?
by
Jason Carreira
Posted
infrastructure vs. apis
by
Floyd Marinescu
Posted
Re: infrastructure vs. apis
by
Alexandre Poitras
Posted
Re: infrastructure vs. apis
by
Billy Newport
Posted
Re: infrastructure vs. apis
by
Frank Bolander
Posted
Re: infrastructure vs. apis
by
Mike Keith
Posted
Re: infrastructure vs. apis
by
Alexandre Poitras
Posted
-
Depends what you mean. Are application servers going to have a smaller footprint, no, the APIs are just a veneer on top of the code thats already there, it's basically the same code under a JavaEE 5 server except now they need to support the older standards and a new one, it's not going to get smaller. From a developer point of view is there less XML to tweak yep. Besides the XML I don't see a whole lot of difference for the developer given tooling had advanced to make the extra interface classes etc basically invisible.
They really need to develop parts of the spec completely independantly and make them usuable without a container JPA is a good step in that direction. We're starting down that path also with things like caching/ObjectGrid. -
My own opinion on the matter is that things like developer-facing API/frameworks are becoming less necessary for standards bodies as opposed to infrastructural components consumed by all vendors (open source included) in the space, such as the notion of the Servlet and HTTPSession, JTA, JMS, annotations, the JVM specification, etc. These infrastructural standards bring consistency in offerings across all Java projects. Perhaps the approach should be standardize the plumbing, compete on the domain specific frameworks.
It's interesting how when it comes to SE, nobody complains if the class library is bloated (a big class library is one of the reasons Java succeeded), but in EE there is so much controversy. -
They really need to develop parts of the spec completely independantly and make them usuable without a container JPA is a good step in that direction.
Interestingly, the fact that J2EE as a platform was defined as a big umbrella spec was very important and very successful back in 1999-2000. It's what the industry needed in order to migrate away from the 30+ vendors specific platform programming models and to a standard.
However, today, your plug and play approach sounds a lot more compelling. A number of application servers have already adopted modular architectures to enable similar capabilities. -
My own opinion on the matter is that things like developer-facing API/frameworks are becoming less necessary for standards bodies as opposed to infrastructural components consumed by all vendors (open source included) in the space, such as the notion of the Servlet and HTTPSession, JTA, JMS, annotations, the JVM specification, etc. These infrastructural standards bring consistency in offerings across all Java projects. Perhaps the approach should be standardize the plumbing, compete on the domain specific frameworks
I complety agree with you on this one. Standardize the infrastructure services but not how to access them and how to structure your application. In my opinion, the different frameworks or component model shouldn't be standardized (except maybe JMX) since this is where most of the innovation is taking place. There isn't any component model in JSE and I think it's great so why JEE should be different?
J2EE encourages way too much developer to structure their code according to the type of component they are creating. At least, JEE 5 is going the POJO way but I still don't like the EJB3 specification. Why would I need a business component model? I want to be free to add whatever services I need to my objects like JPA or even homegrown ones. Spring seems to have proven that this strategy is very effective. Well, I know I am going to take a serious look at JPA but I don't think I'll use EJB3 session beans. -
Thats the problem, developers already had injection, POJO based programming with IoC frameworks and the web frameworks. As for tools, I don't think anybody makes money in J2EE tooling anymore. Eclipse is just too good.
Non invasive middleware is the way to go. -
Depends what you mean. Are application servers going to have a smaller footprint, no, the APIs are just a veneer on top of the code thats already there, it's basically the same code under a JavaEE 5 server except now they need to support the older standards and a new one, it's not going to get smaller. From a developer point of view is there less XML to tweak yep. Besides the XML I don't see a whole lot of difference for the developer given tooling had advanced to make the extra interface classes etc basically invisible.
If you and other vendors can't make things lighter, you're destined to continue to lose out to Tomcat/Resin + Spring + whatever else I need that I specifically wire in.
WebSphere needs to take more ideas from Geronimo and let individual pieces be brought in without the rest of the stack. If I just want the JTA TX manager, JMS, and the servlet container, let me configure the stack that way. Let me make the container profile exactly as much as I need, and no more. -
Billy,
Are you thinking along the lines of AOP style middleware where various aspects encapsulate services and are composited onto an application? Or are you talking about strict DI/IOC stuff.
Although DI/IOC has definitely helped with the development lifecycle, I think "lightweight" for the sake of lightweight is dangerous. Appservers provide multitudes of services and features that unfortunately have required explicit hooks to utilize. Let's not forget that we still need getters/setters to hook into "transparent lightweight frameworks". I'm not sure why this is considered lightweight compared to implementing container interfaces. Plus I think the whole "JEE is too complex" is way overblown to justify some group's or person's "lightweight framework" or agile methodology. Yes, there were mistakes along the way, but there also has been great progress which for the most part has been flippantly disregarded because of "poet architect" egos.
I think JEE is moving in the right direction after these past several years of inertia. -
I complety agree with you on this one. Standardize the infrastructure services but not how to access them and how to structure your application. In my opinion, the different frameworks or component model shouldn't be standardized (except maybe JMX) since this is where most of the innovation is taking place. There isn't any component model in JSE and I think it's great so why JEE should be different?
Writing applications in the enterprise is a different ball o'wax from writing a simple client program. An enterprise application requires additional technologies and services that suit it for scalable client access. These services (plumbing) should be reusable and pluggable so that they fit together and can be swapped (like JPA). We are not there yet in Java EE 5, but hopefully once people see the JPA benefits they will demand the same for other Java EE components. The interfacing of these technologies needs to be standarized both for this pluggability and for application portability from one app server to another.
J2EE encourages way too much developer to structure their code according to the type of component they are creating. At least, JEE 5 is going the POJO way but I still don't like the EJB3 specification. Why would I need a business component model? I want to be free to add whatever services I need to my objects like JPA or even homegrown ones. Spring seems to have proven that this strategy is very effective. Well, I know I am going to take a serious look at JPA but I don't think I'll use EJB3 session beans.
Every application should have a "business component model", whether it is EJB or just plain JavaBeans. It is just plain good software design. You don't need to use the Java EE prescribed model if you don't want to, but the benefits of doing so are endless, e.g. portability, shared terminology set and communication patterns, training, skills reuse, and the list goes on.
If the components were pluggable then you wouldn't need to even require the unused components to be in the server (unused as they might be). The problem right now is that people are forced to at least open and look at the whole Java EE pie, even if they don't have to actually eat it all. -
I complety agree with you on this one. Standardize the infrastructure services but not how to access them and how to structure your application. In my opinion, the different frameworks or component model shouldn't be standardized (except maybe JMX) since this is where most of the innovation is taking place. There isn't any component model in JSE and I think it's great so why JEE should be different?
Writing applications in the enterprise is a different ball o'wax from writing a simple client program. An enterprise application requires additional technologies and services that suit it for scalable client access. These services (plumbing) should be reusable and pluggable so that they fit together and can be swapped (like JPA). We are not there yet in Java EE 5, but hopefully once people see the JPA benefits they will demand the same for other Java EE components. The interfacing of these technologies needs to be standarized both for this pluggability and for application portability from one app server to another.
J2EE encourages way too much developer to structure their code according to the type of component they are creating. At least, JEE 5 is going the POJO way but I still don't like the EJB3 specification. Why would I need a business component model? I want to be free to add whatever services I need to my objects like JPA or even homegrown ones. Spring seems to have proven that this strategy is very effective. Well, I know I am going to take a serious look at JPA but I don't think I'll use EJB3 session beans.
Every application should have a "business component model", whether it is EJB or just plain JavaBeans. It is just plain good software design. You don't need to use the Java EE prescribed model if you don't want to, but the benefits of doing so are endless, e.g. portability, shared terminology set and communication patterns, training, skills reuse, and the list goes on.
There are only 2 things I ask of my JEE container :
1) Standard APIs (JMS, JTA, ...).
2) Standard ways to expose my components to a given protocol (Servlets, JMX, remote EJB)
On the other hand, I don't want to be forced to use any business component model except JavaBean of course. I can get all the other services a EJB provides me quite easily without resorting to an heavyweigth container :
1) A good IoC container allows me to lookup intra-application dependencies
2) A good IoC container allows me to manage my objects lifecycle.
3) Handling cross cutting concerns is way easier using a good AOP tool. Plus, I can use whatever APIs I want (homegrown, commercial, open source, ...). I don't have to deal with all the "standards" if I don't need to and I can "weave in" any product I want to use.
4) Stateful objects. State is a concept strongly associated to the remote model you use and I think it should be handled by a thin remote layer (like servlets) so I prefer using staless objects at the moment. Altough, JBOSS Seam seems quite interesting and I may be wrong in this case.
It's true that EJB3 has a lot in common with those solutions (but it's still less powerful IMO) and is way more elegant than EJB2. But the main problem is still there : the specification doesn't force the container to be embeddable and that's a HUGE turnoff (at least JBoss EJB3 supports it). So I would still have to go througth this painful compile-deploy-test cycle again and this is a no go if you use TDD.
And I don't buy the advantage of a standard in term of portability : Portability is important when the product isn't packaged with your application (for instance JTA) and runs independently on the server. But if you take the example of a lightweight container like Spring or a persistance framework like Hibernate, it is always bundled with your application so portability isn't really an issue there. As for skills, training, common vocabulary, there are tons of good books and training on any popular open source solutions.
9 comments
Watch Thread Reply