Java EE 6 Overview
Here’s a very high level overview of some of the features in Java EE 6. The most interesting to me is that web.xml is being made optional by adding more annotations. There is also a new notion of “profiles” which allow you to pick and choose what features of JEE (specs, frameworks, etc…) you want. Watch the video here.
Finally on Twitter.
I’ve been putting this off for a long time but have now decided to create a Twitter account. If you are interested, you can follow me.
Web Services Conceptual Architecture Document Helpful
If you, like me, are trying….struggling to learn how to implement and/or consume web services there is one document that will help conceptually. I happened to find an IBM document entitled Web Services Conceptual Architecture that laid out the architecture for web services way back in 2001. Even though its old and full of pompous IBM predictions about web service standards (that have not yet come true) it is still a useful and relevant document.
I’ve had a hard time finding references that do not assume you understand the architecture of web services and I’ll bet that you have too.
How to share session between web modules in WebSphere 6.1.
I recently had the *pleasure* of attempting to integrate a second Java web application module into an existing Enterprise application. Throughout what became a mere exercise, I ran into several problems that were not well documented on the web. I found enough documentation to wade my way through to a solution but thought it would be helpful to document my experience for others’ benefit. This post is a brief discussion of the actions you have to perform to share session amongst multiple web modules within a single Java Enterprise application.
Environment
The environment is a run-of-the-mill Java Enterprise business web application. The JEE version used is 1.4, Java SDK 1.5 (IBM implementation), running on IBM WebSphere 6.1 application server (fixpack 17 in case that matters). The application is deployed as an EAR with a single WAR. Also important to note is that the application server and web module class loaders are set to load from the application up (inverted, or “parent last”). The IDE being used is the WebSphere Development Studio Client version 7.
Requirements
The desire was to separate a web service client from the one WAR in the EAR and deploy the client as a second WAR inside the EAR. It was necessary for servlets in the two web modules to share session state. In other words, I wanted to have all the web modules in my EAR use one, and only one, session. The two web modules would also be sharing some common code where each module maintained its own copies of the JAR files.
Solution
To meet these requirements there are multiple steps you must take. The requirement to focus on here, especially if your situation is not exactly like mine, is sharing session amongst multiple web modules. Sharing session is not a part of the servlet specification and so leads to some traps. Each step is explained below.
Step 1: Turn on the Shared Session Context IBM extension in the enterprise application configuration.
A big problem with wanting to share session state between web modules or applications in a servlet container is that the official servlet specification forbids it. You can read it for yourself in the Session Scope section of the version of the servlet specification you are using. IBM overcomes this limitation with a non-standard (a.k.a. proprietary) extension that you can toggle called Shared Session Context. How to toggle this extension is documented here. You simply flip on this switch and WebSphere starts sharing session state across web modules.
Remember that, if you decide to use this IBM extension, it is non-standard and it is then unlikely that your web application will be portable to other application servers. For sure, you will not be able to run your application on Apache Tomcat since that container adheres strictly to the servlet specification.
Step 1a: Work around a bug in Rational Application Developer (RAD) IDE for WebSphere.
NOTE: If you are using another IDE such as Eclipse, NetBeans, or IntelliJ IDEA, you can probably skip this step.
There is a bug in certain versions of Rational Application Developer (RAD) and WebSphere Developer Studio Client (WDSC) that must be worked around in order to perform Step 2 without error. Before you continue you should read the IBM bug report and determine if your IDE is affected. If not, skip straight to Step 2. If you are affected, follow the directions in the bug report. If you do have to work around the bug you may notice some side effects that I noticed after doing so. The side effects were acute with my application because it has a large number of files in it (approximately 150MB). You may not experience these problems with your application.
Side effects I experienced after using the work-around in the IDE bug:
- The Integrated Solutions Console for WebSphere took minutes to load some pages.
- Publishing my application to my development server took ~90 minutes each time.
- I lost the option to change class loading order from Parent_First to Parent_Last.
Step 2: Change the class loader policy from Multiple to Single.
Turning on Shared Session Context in Step 1 immediately reveals another problem related to class loading. By default, WebSphere uses unique class loaders for each WAR within an application. So even though two WARs might instantiate the exact same class, the Java runtime does not consider the resulting objects as compatible because they were loaded by different class loaders. The problem when trying to share session across WARs is that an object placed into session by one WAR will not be usable by another WAR. IBM has documented this part of their WebSphere architecture here.
For example, consider the situation where a web application installed in WebSphere is comprised of two web modules: AppA and AppB. Assume that the WebSphere server has been set up as in Step 1 above. If the two web modules are sharing session then it’s going to be common for a servlet in one to place an object in session for a servlet in the other module to retrieve. For instance, consider that AppA places an instance of java.lang.String into session for AppB to use as shown below.
String stringPutIntoSessionByAppA = “appA stuff.”;
session.setAttribute(stringPutIntoSessionByAppA);
When AppB pulls this object out of session as below,
String appBString = (String) session.getAttribute(“stringPutIntoSessionByAppA”);
which only works because of turning on the non-standard option Shared Session Context, an exception like this will be thrown:
ClassCastException: java.lang.String is incompatible with java.lang.String.
This error illustrates that the two classes, whose package and class name match exactly, are not considered to be the same class by the JVM at runtime because each one was loaded by a different class loader.
To fix this problem you have configure the web application to use a single class loader for all web modules within it. This class loader setting is changed through the WebSphere Integrated Solutions Console (a.k.a. the administration console). With the server running, log into the Integrated Solutions Console and click on Applications –> Enterprise Applications and then click on the name of the application whose settings you are changing. Under the Detail Properties section click on Class loading and update detection. Finally, you have two choice as shown below.
Class Loading Properties for a Web Application in the WebSphere 6.1 Integrated Solutions Console.
In the section WAR Class Loader Policy choose the option Single class loader for application. Click the OK button and then save the configuration. This setting will cause everything (all WARs and EJBs) in the EAR to be loaded under one class loader and allow session to be truly shared between two WARs.
Summary
If you want to write a web application for WebSphere 6.1 consisting of multiple web modules and you want all of the modules to share session you will have to do some configuration. The first step, turning on Shared Session Context, is an IBM proprietary extension to the servlet specification. Turning on this feature causes other problems and forces you to change your class loader settings on the server in order to get session sharing fully functional.
More Software Incompetence
In a past post I showed an example of how malfunctioning software can lead intelligent humans to make poor decisions. In that case, blind trust for the competence of the software was the most likely cause. Here is another example of acute software incompetence.
New credit card statement....is that right?
This is a scan of an account statement for a newly opened credit card. This is a real credit card that I recently signed up for. You can see it’s new by all the zeros on the page. You might, however, notice one number larger than zero, quite larger.
Somehow, with only a $1000 credit limit total the creditor is willing to give me a cash advance of $9,999,999,999,999! That’s 13 nines. That’s one dollar short of 10 Trillion dollars. That’s just not right.
Fortunately this won’t hurt me for two reasons: one is that I never use the cash advance feature of a credit card, and the second is that this mistake is so gratuitous that I know it can’t be correct. I haven’t called the credit card company yet because I’m actually just curious to see what happens after the account has some activity on it.
What’s interesting about this, from a programmer’s perspective, is that such an oversight was allowed into production code. A brand new account seems like an obvious test case to me. And what this means is that the software development process at the credit card company failed in several ways. At the unit test level there either was no unit test for the cash advance limit or it is missing an important case. At the interface level it means, again, that no one ever checked the common scenario of a new account with no activity. Even though it’s impossible for me to know, it may have even been a requirements issue. Maybe no one ever asked for this to be checked, who knows?
Software Incompetance (can lead to human incompetance)
The picture below demonstrates a big problem in the current state of software usage. Right now it is too inefficient for a corporation not to automate many processes. However, the software used to automate those processes is just not as smart as people are. Most of the time this works out alright, but not always. There are always edge cases and edge cases are what can make a big difference in how sophisticated your software really is.
Now, if a human with a little common sense were making the price tags, and not a software application lacking in sophistication, the price tag below would probably not have been created because it just doesn’t make sense. Interestingly, the opposite, and more damaging, situation occurred. Because a dumb program created a price tag just because of a single penny drop in price some thoughtless employee felt compelled to actually hang it! This is indeed a failure in software and our trust in it.
Eat your own dog food?
For some reason this saying popped into my head today. I think I was tenuously thinking about unit testing and I remembered that I’d heard the phrase “Eat your own dog food” at some conference session on testing. Then I thought, “what a stupid saying!” Even if I had a dog food company I wouldn’t literally eat the dog food, I do have some common sense. I would, however, definitely feed the food to my own dogs.
Now, I now what is meant by the expression, but, for some reason, this just really irritated me. This phrase now sits in my mind as intelligent as when someone tells me they took something for “granite”.
Here’s a rather serious Wikipedia entry on Eating one’s own dog food.
When software fails at the wrong time…
I recently had to take my pregnant wife to the hospital to treat a kidney infection. One of the first things we did after we got into a room was to answer an absolute torrent of medical questions. The nurse performed data entry into the hospital’s patient management software while she was asking the questions. The process took about an hour to complete. All the while my wife was not being treated and was in severe pain.
Now, had nothing gone wrong with the patient management system, the sheer amount of questions would still have taken at least forty-five minutes. I’ll grant that this time was necessary, especially because my wife is pregnant, to ensure that the diagnosis and treatment were done correctly. However, the extra fifteen minutes that my wife had to suffer through existed only because of failures in the patient management system.
The first problem was that the nurse was stumped when she tried to put in the answer my wife gave to a question and there was no drop-down entry for it. The question was “are you allergic to latex?” The answer, as so often happens in real life, was “sort of”. The nurse became aggrevated because the choices for her to choose from to enter the answer didn’t include an answer like that (which actually was that she is sensitive to latex). As a result, the nurse wasted time trying to force my wife’s answer into one of the application’s pre-defined choices. She actually resorted to trying to talk her into claiming that she has a full-blown allergic reaction to latex when that isn’t true! A poor implementation of software caused a nurse to do her job poorly. That is absolutely unacceptable.
The rest of the wasted time was due to some other glitches in the patient management system that weren’t as serious as serious. The application completely shut down at one point without an obvious cause. Later, the nurse had to re-type in a few sentence’s worth of explanation three times because the data wouldn’t save properly the first two times. Fortunately these events didn’t have as much of a negative impact on patient care as the first problem, but they did waste valuable time.
The point is that software developers should always strive to elliminate software failure, yet there are times when failure in software means more than just lost time and money. That critical failure, as in my anectdote, can cause extended suffering and loss of good, humane care when it is needed most. If you are a developer on such a software application then you should be ensuring that your software works correctly for real situations. This incident shows me that the software industry still fails to provide what people really need in real situations.
Programming under the Scientific Method?
Just as a good blog should be, here are some loose thoughts on programming that I’ve had lately. I have spent some time thinking about my process for writing code. In fact, I’ve been thinking about what I have been able to glean so far about the process that the mass of programmers in the world go through to write software. The impression that I have is that writing software is not scientific enough.
The germ of this idea is that I’ve never felt that I could quantitatively prove that the way I write code actually produces a working, correct result. This was before I really understood the idea of unit testing. I started going to conferences and working on a Masters Degree in Computer Science and began to learn about the idea of unit testing. Only at first, I thought that unit testing was the answer to qualitatively proving that my code was working and correct. Unit testing certainly appears to be the answer because of its emphasis on incrementally proving that the code is correct as per the rigor of each test. Yet, after about a year of actually working with unit testing I’m starting to question the true strength that unit testing provides.
There is no doubt that unit testing provides rigor around the software development process — theoretically. At any software development conference there is no shortage of unit testing pundits who espouse the benefits of the practice and explain the process for incorporating testing into your development process. And attending these conferences is largely a group of people whom have no doubt that unit testing is an honorable practice. Practically though, the test is usually only as strong as the will of the programmer to write a good test. The example being that I can write very poor unit tests for every unit either because I misunderstand the process or because I don’t care enough to write good tests. Neither is helpful in providing evidence of working and correct code. Further, even though the discipline of good unit testing can provide some proof that code is working and correct, there is almost no proof (I have only heard anectdotes) that starting the practice of unit testing actually changes the quality of software.
The failed panacea of unit testing for providing quantitative proof of working and correct code lead me to think about why it didn’t really solve the problem. Eventually the Scientific Method came to mind. When that happened I wondered why we don’t talk about the software development process in the context of such a solid framework? The Scientific Method works for all other sciences, why shouldn’t it apply to Computer Science?
So, finally, here is the main thought in this post. I believe that at least understanding the Scientific Method may improve the process of software development . In this post I won’t explain the Scientific Method or talk about how it applies to software engineering in a practical sense, instead, I’ll only mention that thought and leave it for you to ponder.
I think that the reality is that writing working and correct software is a grand challenge and requires rigor if it’s ever to become a standard. Great ideas such as unit testing (and its accompanying process Test Driven Development) undeniably add to the rigor or software development but fail to make a complete process for developing working and correct software. I’m curious to know if thinking about software development in terms of the Scientific Method would help bridge the gap between writing code and unit testing to make a cohesive process that can be analyzed and proven quantitatively.
…
There are a lot of scattered thoughts here that are either leaving gaping holes or need expansive exploration to fully explain. I understand that and I hope that myself or others can fill in those gaps. I’m immensely interested in exploring this idea and discovering where it leads.
Groovy and XWiki
The more I use a wiki at my day job the more I come to rely on it. I have found it to be an outstanding documentation and note-taking tool. At work I installed the Moin Moin Wiki which myself and two other developers contribute to regularly now. We are using version 1.6.something and have been happy with it.
I recently installed a new kind of wiki at home. XWiki, the self-proclaimed second generation wiki, is more than just a wiki. XWiki adds the very desirable capability to add two kinds of scripting languages directly into the wiki pages: Groovy and Vortex. This capability could allow you to write quick-and-dirty web applications directly in the wiki. It’s all object oriented and runs on a JEE back end.
In my brief encounter with XWiki so far the most exciting part is the Groovy support. Groovy seems to be exciting lots of Java developers and I’m one of them. XWiki also has a very flexible and, so the XWiki developers say, an enterprise ready wiki architecture.
The major problem I see with XWiki’s Groovy support is that the code is embedded directly in the wiki pages. At first glance this seems to be bad form when I think of all the “best practices” I’m always attempting to digest and use.
I’ll have to investigate more to see how this all plays out. Let me know your opinion if you have some experience with XWiki.
