Wednesday, October 30, 2002

Thanks Rikard Oberg for setting the world straight on the nasty benchmark at the

Review of "The Petstore Revisited: J2EE vs .NET Application Server Performance Benchmark"

Who in there right mind would use BMP? This benchmark is nuts. Wow! I can't believe this. Ouch.

Having actually developed and deployed high performance J2EE applications to production, I am glad Rikard spent the time poking holes in this benchmark. I hate to see J2EE get a black eye when it makes no sense.

Real comparison

Tuesday, October 29, 2002

Somebody asked me some questions about EJB, stubs, skeletons and their relationship to EJBHome and EJBObject

My answers are marked with **

Is it correct to say:
"The instance of the EJBHome object on the client side is created by the
EJB tool and is the stub.

** It would be more correct to say that the client talks to the EJBHome object through the stub generated by RMIC (or vendor equiv). The stub is an artifact of RMI not EJB per se. The EJBHome object is created by the vendor with EJBC (or vendor equiv).

Is it correct to say:
"The instance of the EJBObject on the server side is created by the EJB
tool (AppServer/Containter) and is the skeleton."

My Answer
** The EJBObject is accessed through the skeleton. It is not the skeleton.
The EJBObject is generated by the vendor to include support for persistence (CMP only), security and transaction support. It is a proxy object as is the stub (the stub is a proxy too). The stub is a proxy to provide remoteness. The EJBObject is a proxy to provide transaction, security, etc. support. The stub is the pitcher and the skeleton is the reciever. Together the stub and skeletong marshal requests from the client to server; this includes serializing parameters to the server object and responses to the client.

Random thoughts on Agile and Unified Process (over design)

Random thoughts on Agile and Unified Process


One of the issues with software methodologies and processes are that they tend to be extremely heavy weight or “non existent”. Many organizations have a documented process and methodology that no one follows due to the heavy burden of the mandated process. Most organizations seem to follow two extremes: ad hoc process, or heavy weight process. Ad hoc process is sometimes referred to as “no process”. I don't believe any organization can truly have no process.

The issues of having a heavy weight process seems to multiply as many popular processes combined to make the unified process. By combining the thoughts and ideas of many groups and schools of thought, the Unified Process (UP) if followed in detail has in essence created a process that is too heavy weight for most organizations. Most advocates of the Unified Process, advocate a scaled down version of UP. I am not against UP. In fact, I believe there are many projects and corporated cultures that demmand something like UP.

There is value in having a process. There is also harm in adopting a process that has too much baggage. The primary focus should be on providing customer value and not generating artifacts. Some organizations get so bogged down in generating artifacts that they forget the emphasis should be on providing business value through software, i.e., the working code is the most important artifact.

A backlash against process and methodology seems to produce a bumper crop of interest in alternative methodologies and processes as follows: Featured Driven Design (Coad, abbreviation FDD), Extreme Programming (Beck, abbreviation XP), and SCRUM among many others. These methodologies and processes claim to be either light -
weight alternative methodologies or anti processes and anti methodologies.

For example, XP believes that the focus of all organizations should be on providing business value, and that the main artifacts in the process should be working code. XP does not like to use words like process and methodology yet XP is a process that is focused on quality code that provides customer value.

These groups of alternative methodologies organized into a group called the Agile Alliance. Agile projects tend to be very successful for dynamic teams. This is not to say the Unified Process does not work for some organizations. In fact, there is benefit in adopting a process and following it, and UP can be scaled back to fit an organizations culture. Many corporate cultures would be better served by a lighter weight agile methodology.

Often code that does not have a design is criticized heavily, as it should be. But another problem occurs, a less published and cited problem, the over design of code. Code should be as simple as needed to fulfill the customer’s requirements. Complicated designs can lead to as much damage if not more as having no process and poor designs. Many organizations spend too much attention on the newest technologies and applying the latest design patterns. Over design is endemic of a heavy weight process like missapplied UP.

This is not to say that design and design patterns are not useful. On the contrary, all processes mentioned both agile and unified focus on applying design effectively amongst other practices.
It has been a long week.

My week went something like this:

On Monday, I spoke to an IT organization in Manhattan on Web Services. We covered an overview of SOAP, UDDI, WSDL, ebXML and more.

Tuesday through Friday, I taught an Advanced EJB 2.0 course. The course covered EJB CMP, CMR, EJB QL, Session Beans, Entity Beans, Message Driven Beans (MDB), and more. We deployed examples on both IBM WebSphere and BEA WebLogic. This course was the high light of my week. Three students in the course, independently, told me that this was the best technical course that they have ever taken. Everything went very smooth.

While I was in New York, I went with a friend to see a tribute to a composer (his name escapes me). The show was wonderful and I had a really good time. I am not a big fan of musicals and dancing. I much prefer dramas to musicals, but I think my tastes are changing, as I get older. I really enjoyed myself. This is the second musical I have seen in a row that I have enjoyed.

Then on Saturday morning I took a 4AM flight from New York to Chicago to attend the Great Lakes Software Summit. I was a speaker at the Summit. I did a three-hour tutorial on Java Tools for Extreme Programming (XDoclet, Ant, JUnit, JUnitPerf, JMeter, Cactus, HttpUnit, etc.). I also did a three-hour tutorial on EJB 2.0 CMP (CMP, CMR, EJB QL) and XDoclet. I love XDoclet.

This is the second event in the Software Summit from the Complete Programmer Net that I have participated in. It amazes how well groomed and technical the speakers are at this seminar series. The level of technical content, real world experience, and good speakers are top notch. If you are doing enterprise development, and you can attend one conference this year, I highly recommend the Complete Programmers Net Software Summit series. Attendees come up to me at the breaks and say the same thing that I am saying. This seminars are top notch source for new information.

Saturday night at the conference was a lot of fun. Jason Hunter organized a war party of speakers to hit the town in Chicago. Actually, “organized” might be too strong of a word. Hmmm… Jason incited a mass of speakers to go from the Hotel to venture out in the great unknown of downtown Chicago…. unknown to me at least.

Although, I have been to Chicago, I never stray far from my hotel. I am glad he incited such adventureness. We all had a blast. We went to the Navy Pier. The war party of speakers included Bruce Tate (Bitter Java), Sue Speilman (the Struts book author), James Duncan Davidson (the original developer of Ant), Jason Hunter, John Carnell, Maciej Zadwadski (the developer of Ant Hill), Kyle Gabhart (the Java Pro) and many more. More on this later if you are interested.

I attended Sue Spielman’s presentation on Struts 1.1 features. It looks like I have some catching up to do. Struts is really growing and maturing. We started using Struts at eBlox in the early beta days. We were desperate for a good MVC architecture, and Struts fit the bill. It is exciting to see all of the new 1.1 features. I look forward to reading her new book.

I got to spend some quality time with Erik Hatcher the author of Java Development with Ant, one of the best written technical books that I have ever seen. We rode to the airport together. Erik Hatcher and I use to be coworkers at eBlox. In fact, Erik was a key reason we were so successful in using Struts and Ant at eBlox. Erik is awesome.

About the speaker war party descending on Chicago Navy Pier, it is like this. We left a little late. It became the expected case of this… “Where is so and so….” “Well so and so went up to their room to get such and such…” “Hey that sounds like a great idea, I’ll run up to my room and call somebody and this and that really quick” Add a few iterations of this….. (I am guilty of doing this myself.). Then Jason Hunter, our fearless leader, had a great idea to get us out of the door quickly. He came up with a list of car groups, and he went about breaking up the speakers into several car groups. Then somebody somehow picked the destination…. Downtown Chicago. Hey…. It is my kind of town.

Sue, Maciej, John and I were in one car group. And the journey began. I drove and Sue took the helm as the official navigator. Map in hand, she navigated across the 50 mile terrain to Chicago downtown Nava Pier. Sue did a great job of navigation.

At one point however we were at a crossroad. As we approached the oncoming fork, we had to make a last second decision. Veer left and or veer right, the car group was equally divided on which way to go as we cruised 50 miles per hour heading straight for the cement divide. A semi tractor trailer coming up on my left cruising at 70 miles an hour tipped the scale in the favor of heading right. We missed the center divide and we were on our way to Chicago. As it turns out the tractor trailer was right about us going right.

Once we got to Chicago proper, Sue navigated us to the Navy Pier with few detours. It seems the map we were using was a little dated, and streets that once went through now led to a dead end. Cruising through congested traffic use to be such an issue for me, but after going to New York and Boston a few times, I can cruise through traffic with ease.

We ate at a Sushi bar, I had a Steak (beef it is what’s for dinner). This happened to be the best steak that I have ever eaten. It was wonderful. The name of the restaurant was Sushi Yukuu, and it was their grand opening week. If you are ever in Chicago, I highly recommend eating at this restaurant it is fabulous and not too pricey. It is near the Navy pier.

This week I am working on proposals, outlines, and Web Services material. Hopefully, if this next contract comes through I will get a chance to do some mentoring. I really enjoy training, but I am ready to do some mentoring and consulting again.

Wednesday, October 23, 2002

I also spoke with Andrew Barton, the co founder of eBlox, last week. I want us (him and I) to co author a white paper on building an Extreme Programming team. We had a lot of success with XP, and I want to tell the world about it.

Also, it seems Andy has created a XP bidding process. He says the new bidding/planning process really helps ensure that they do not take on "loser projects". I am encouraging him to write a white paper about this.
It is a real shame. I have not blogged in a few weeks. It is amazing how fast time goes by. I am in NY now (I live in Tucson AZ). I spoke to a group of IT professionals on Monday about Web Services. Kyle Gabhart and I (mostly Kyle) created a presentation on Web Services Survival Guide.

Three things I hear a lot in NY:
1) outsourcing to India
2) IBM WebSphere
3) dot Net

It seems if you are doing J2EE on Wall Street than you are using IBM Wepshere, which make sense given they already have a lot of the IBM big iron.

I am teaching a course this week (Tuesday through Friday) on Advanced EJB with BEA WebLogic. The course is vendor neutral except for the exercises that are WebLogic centric (at least the build scripts are). This is the third time that I have taught this course this year.

Saturday AM, I fly out ot Chicago to speak at the Great Lakes Software Symposium on Java Tools for Extreme Programming and EJB 2.0 CMP/CMR/EJB QL with XDoclet.

I took some more BrainBench tests last week. I got the highest EJB 2.0 score in the United States (3000+ people took the test in the United States). I got the highest J2EE score in the world (700+ people took the test worldwide). They have a slew of new tests for Web Services that I am considering taking.

Tuesday, October 08, 2002

Brain Wilson had a question on how to configure remote clients to talk to EJB beans in Resin.

You sent me some offline email as well with this questions and others.

I'll try to answer all the questions in this forum so they will be available
for others who search the mailing list.

1) First I would not hardcode the JNDI properties in your source code.
Instead put them in a JNDI properties file called As long
as this file is on you classpath the JNDI system will find
as a class resource and use it as the default properties for the initial
context and provider URL. Then all you need to do is create an
InitialContext with no arguments. This is the more portable J2EE way to get
your initial context.

Here is an example properties file for accessing weblogic (resin example
will follow)
Sample Listing....


2) Now the question becomes how do you configure the above for Resin. I think
the answer is here Although the link does
not specify client access per se or the file.

Try changing the JNDI properties file as follows for hessian...


Try changing the JNDI properties file as follows for burlap...


I have not tried this with Resin, but I have done similar things when
working with WebLogic and Sun's RI. I've only done local beans for web apps
with Resin EE in production.

3) You are not done yet. You also have to expose hessian protocol from your
web application that houses your enterprise beans. I found information how
to do this here...

Add the following mapping to your web application's deployment descriptor
for burlap.

Strangely.... The documentation only explains Burlap instead of Hessian.
Hessian is the preferred way to access the bean remotely (faster, but does
not sneak through firewalls as well as Burlap).

Based on the logical nature of most of the Resin package naming, I make the
following guess on configuring Hessian. (I'll try this when I add this
information to the tutorial I am writing).

4) Lastly it seems you are doing this mainly to test your enterprise beans.
I suggest using Cactus to test local beans. I think there is too much
configuration and runtime overhead to use remote beans just to test beans
that will naturally run locally within the confines of a web application.