Andreas Schaefer's Blog

September 2003 Archives

How to Handle Permanent Exceptions after EJB Deployment: a Proposal

Finally I found time for a technical log here at Java.net. This time I want to discuss a shortcoming of the EJB specification and how they can be fixed to make the life of EJB developers and application server administrators easier and the deployed applications more robust.

Originally the EJB specification assumed that the applications are deployed at startup of the application server and the environment remains stable for the time the server is up. With the broader acceptance of the J2EE application servers the dependencies between remote servers (DB, application servers, JMS etc) grows and a successful deployment does not mean that an application will run smoothly all the time. In some cases application server are just used to host application on the user’s computer and there is not full time administrator on duty.

Let us assume that an application contains one or more message driven beans (MDB) and they invoke other EJBs or resources to help execute the handling of a message. Now a resource used is becoming unavailable for a longer period of time and the message cannot be handled anymore. In the current specification then only thing the MDB can do is to either swallow the message and therefore lose all the pending message on the destination the MDB is registered on or it can rollback the message causing the server to resend the message immediately. The second option of course will put a drain on the server because every message will be resent until the message could be handled again or the server is putting the message away in some sort of a dead letter queue. Just imagine that a destination contains thousands of messages which are resent multiple times just to end up in a dead letter queue. What a waste of resources, isn’t it.

A similar problem occurs when a client access a stateless session bean (SLSB) because the SLSB instance is not created when the “create” method is invoked on the home interface but somewhere between the deployment and the first invocation of a business method on the SLSB instance. This means that any exception in the “setSessionContext” and “ejbCreate” method is not available to the client.

Both problems can be solved if the EJBContext would allow the EJB to inform the server about an unrecoverable error with a message and a Throwable instance. This allows the server to take the EJB and/or the entire application in question down and return an appropriate EJB- or RemoteException to a caller to inform about the original problem. The server then can inform the administrator about the problem or can try to restart the EJB/Application periodically (in the case of MDBs). Such a hook in the EJBContext could look like this:

public void reportException(String message, Throwable cause, int severity, int hintForServerHandling);

Back to Darwin's Survival of the Fittest

Lately you hear many software engineers complaining about competition in the software industry from foreign workers or foreign companies starting to compete. Finally, it seems, that the US is not an island anymore and that we are facing major competition. For me, I cannot comprehend the outcry maybe because I had to fight, learn, change and risk a secure lifestyle to become what I am now. That means I embrace change and competition because it will keep you on your toes so that your market value does not drop relative to the market. On the other hand, I can feel the agony of these developers because in Switzerland, the safe, hired-for-life work environment was turned up side down due in part by the competition from the US during the last decade. I think there are two important aspects everyone involved in these times of changes should think about.

1. Every Software Engineer has to work on his/her Market Value Everyday

Evolution is omnipotent and we have to adapt or fear extinction. In a world of global connectivity through the Internet and distributed development in companies as well as open-source projects, foreign companies are becoming more and more competitive and then can take advantage of their local environment like lower wages or lower costs of living. This means in turn that every software professional here in the US has to compensate for the disadvantages of the local environment through knowledge, skills and good communication. As hard as it may sound, everyone that is looking for a good paid, secure and nine-to-five job is on the wrong place here because the Internet boom is over, period. I, for myself, do not expect to be a software engineer in 10 years even though I have no clue yet what I will be doing then. But I am confident that I will find something that I like and where I am eager to work on. Right now I like the competition and the challenges because I can work on a job where every day is different and I never feel that I have to go to work. It is a privilege to work as a software engineer that has to be earned and then worked hard for to keep.

2. Outsourcing is NOT the Holy Grail of Cost Cutting

The dispute between a CEO of a car company and Bill Gates of Microsoft was flawed from the very beginning because they forgot that software development is a Research & Development process and not a production process. In software development, only one copy is produced called the source code and only the process of pressing the CDs and printing the manuals is mass production. This means that companies outsource their R&D department to another company. To make things worse, the most important parts of a software project are communication, communication and, did I say, communication but it is precisely communication that is difficult in an outsourced project, especially when foreign companies are involved because communication is not only difficult, but the cultural gap can be a source of many misunderstandings and can lead developers to wrong assumptions that are undetected for a long time until they appear at probably the worst time. Just remember the failure of the Mars probe where the calling component was working with the metric system and the called components in the US system (feet, pounds, etc.). Outsourcing works fine when there is a very well defined project, the tasks are simple and the tests can be made locally. Therefore projects like the fixing the Y2K bug or code migration did finish well. On the contrary, projects with vague goals and requirements, short timeline or complex or specific business rules will probably fail with foreign companies because each iteration of development will take longer due to the communication lag, produce more errors that will slow down the next iteration and therefore are harder to control from the client.

I saw outsourcing come and go a few years ago like the cost cutting idea of CASE tools or other code generation tools, but we are still coding day in, day out. I guess this wave of outsourcing will go again after a while but unfortunately managers are not paid for good, long-term decisions and so far customers are not willing to pay a little bit more for good service. When the managers or customers cannot be changed, the software engineers have to work hard on themselves and try to show the decision makers good arguments against outsourcing.

Foreign High-Tech Workers: a Scapegoat for a sagging Economy? I don't think So.

I wanted to start my weblog at Java.net a little bit differently but as a former H1-B visa holder Sue’s Spielman weblog with the title “Outsourcing in my company? I do not think so.” stroke a cord and I had to respond. The most replies turn around these sentences:

I am a true believe that the legislation currently being proposed to lower the H-1B and L-1B visa quotas will not go far enough. I think these visas should be abolished until all of the unemployed and laid-off IT workers and engineers who are US citizens are back on a payroll.

Even thought that these two sentence does not have to do much with the title or the rest of the weblog entry these sentences were (mis)understood by many commentators as a request to kick out the visa holders out of the country but it actually says the visas should be abolished. Nevertheless I think it is absurd to think that H1-B and L1-B visa holders are responsible for most of the unemployed IT workers and that a ban will only increase the desire for US companies to outsource their IT departments. Even thought we can all agree to disagree the next sentence:

The fact that a US company thinks that hiring a barely-English-speaking worker in India or the Philippines is going to solve their competitive problems is just absurd.

sounds more like said by a populist politician than an educated software engineer. What is absurd is the thought that all H1-B/L1-B visa workers are coming from India and the Philippines and that all of them do barely speak English. As example I am coming from Switzerland (no, not Sweden) and spoke publicly on many occasions.

As with the outsourcing the underlying problem is that (greedy) executives try to save money through shortsighted decisions and we all have to pay for it afterwards. In my opinion the only solution to prevent the visa holders from being extorted is to make them less dependable from their employers for a balanced competition between local and foreign employees and outsourcing can only be prevented by the customers putting quality and support over cheap products and services.

This work is licensed under a Creative Commons License.