In a new article on Java World, a real-world case study is presented of a J2EE project that used a simple methodology to build an e-government solution for the US Department of Energy in less than 5 months. The case study discusses the benefits derived from using J2EE, and how application security was accomplished, and more.

The article can be found at: http://www.javaworld.com/javaworld/jw-01-2002/jw-0118-j2ee.html

I'd like to know how they ended up with twice as many lines of JSP code as Java code.

Does that sound typical?

Tom

I would speculate that the 12,000 lines of JSP code also includes a lot of HTML.

I've found that "lines of code" stats are a pretty inconsistent measure of complexity between projects and sometimes even developers... but 300 lines/JSP and 120 lines/.java seems in the ballpark.

>> Does that sound typical?

Definitely. Making the presentation look nice always requires a lot of code. Accessing a database using an O/R mapper or even JDBC doesn't require much.


It's really silly to be commenting about this project based on the sketchy statistics. We have no idea how much javascript they used, what 3rd party packages they used, what JSP framework they used if they used one, etc.

Neil

Don't you think that

"51 Java classes with about 6,000 lines of code
43 JSP files with about 12,000 lines of code
25 database tables"

is a little bit too much for a simple survey application ?

Not really. The original Java Petstore was around 8,500 lines of server side code in 60 odd classes and about 2,500 lines of client side JSP with lots of java code mixed into the JSP.

Normal metrics would assume about 10 person months of development for such an application.

NOTE: It IS really difficult for an HTML designer to work with JSPs that include java code. A custom tag library is much friendlier, providing it does not confuse the WYSIWYG editor.

The AltoWeb solution would probably have allowed them to build this application in a few weeks, as opposed to 5 months (as we did for the Java Petstore). We would also have allowed them to utilize the transactional nature of EJBs without any extraneous deployment descripting, and to have deployed it across a variety of application server.

We have real customer success stories that reiterate this kind of productivity increase and flexibility.

Steve Wilkes
Principal Technologist
AltoWeb Inc
swilkes at altoweb dot com | www.altoweb.com

Apple recently shipped WebObjects 5.1, it now supports EJB, servlet deployment, and makes its components accessible to JSPs.

They also shipped the Sun's Petstore application, and a WebObjects port. The port was less than 1/10th of the size in terms of lines of code for the same app.

Given your metrics that means it could be done in a month with WebObjects. (sounds reasonable to me)

I think customers would appreciate that savings, and developers would appreciate not having to write so much garbage code.

There is no mention regarding the use of EJBs in the case study. This seems to validate (at least as one more data point) that most organizations use expensive J2EE containers for serving JSPs.

I think with only 51 Java classes in the entire project it is safe to say that they didn't go anywhere near EJB, considering even the simplest EJB requires at least 3 classes (not counting mdbs). I also get the feeling that they didn't deploy on a full J2EE Application Server because they repeatedly refer to a Servlet Container. Most likely they are deploying on something like Tomcat or Resin.

You are right. It could be the standard edition of Websphere, which has a servlet container but does not have an EJB container.

Its great they put it together in five months and that it is deployed on a zSeries (which is what we are doing).

I'm curious how successful they were at keeping the business logic devoid of any UI code? Bulky JSPs lend me to believe that there could be too much code in the UI layer.

Yes, I agree that it is great that they deployed it on a zSeries, but I am not sure about how they did it and if it is the best platform for that kind of application.

They wrote that they used IBM's HTTP Server, a variation of Apache...does this mean the HTTP Server doesn't run on zSeries? - as I know the IBM HTTP Server on zSeries is a Lotus Domino WebGo Server and only on distributed platforms a Apache variant. If it runs on another platform how did they plugin the servlet engine? WebSphere is a plugin for the HTTP server and does not run in a standalone mode.

If you want to use the S/390 Workload Manager for scaling your application, it has big imapacts on your application design. As you never know to which container instance the next HTTP request will be send to (and in a sysplex you even don't know on which server), the session has to be persistent and shared. I experienced big performance issues with that.

Another point is, that I think zSeries is not a good platform for JSPs and Servlets.
1. It is very slow in comparison to other systems, like SPARC or RS/6000.
2. It is very expensive in comparison to other systems.
3. If you use WebSphere 4.0 on zSeries, every Servlet or JSP will be translated into a stateless session bean.

I think zSeries will be a good platform for transactional applications using EJBs on IBM's WebSphere 4.0, but don't use JSPs or Servlets on zSeries if you do not really need the quality of services you get with zSeries.

Another issue with Java on zSeries I have experienced is, that many API (like Apache Xercec, Xalan, FOP...) do not work out-of-the-box as on other platforms, e.g. because of EBCDIC problems. If the API you need is not supported by IBM (see for example www.s390.ibm.com/xml for supported XML APIs) the affort to port the API by yourself has to be calculated. I had this problem with the Apache FOP API which is not supported and does not work on zSeries without changing the sources...

Mirko

Great article, but there was one point that just escaped me.

"With our J2EE architecture, creative graphic designers could concentrate on presentation logic..."

All of the creative graphic designers I know loathe anything having to do with programming. Also how was the presention logic done...straight JSP?

On the back-end I suspect that EJBs were avoided to keep the project simple and staight forward. From the project description, the data access requirements are not very complex. (Not that I am not saying that that is requirement for EJBs...) We've built many apps with complex data models using Japple and without using EJBs. ;)

Cheers,
Bill Thompson
--
William G. Thompson, Jr.
Chief Japple Evangelist | www.japple.org
Saucon Technologies
bthompson at saucontech dot com | +1 908 947 7145 | www.saucontech.com

I think this is a great read for project managers. The fact that a successful project generates only 6,000 lines of code in as much as 5 months really drives home the fact that software is not about code, but about people.

Guglielmo