What’s Wrong with Modern Software Development?
- The JBoss Microcontainer and Why It Matters
- An Example EJB3 Project on JBoss5
- Running the Client
- Running the Code
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
One question has struck me about many organizations that currently develop software solutions: Why is it so difficult? Often in many cases, the end result of months of effort by a large team of developers is just a few front-end pages, some relatively simple business logic, and some back-end code. These few artifacts are typically stitched together over the course of many long evenings. I find myself asking the same question time and again: Why is this simple stuff so hard to do?
To answer this question, I think we have to look at skills, tools, and environments. In my own experience, skills often tend to be divided into groups that match the layers of enterprise development. So, it’s commonplace to have developers with just front-end (GUI) skills. Likewise, some developers prefer to work in the service layer and have little experience of front-end or back-end work. Finally, there’s another group that works a lot in the areas of persistence, message handling, etc. Very few if any developers can work across the layers.
In short, there are serious disconnects between the skills on modern software teams. There are good reasons for the existence of such disconnects. The problem of course is that the skill disconnects can lead to difficulties at the edges when the software layers are integrated.
In larger organizations, the choice of tools and environment is often made centrally—for example, a specific version of Spring may be mandatory. The same can be true of the choice of application server, database engine, etc. Very often, there can arise extreme difficulties when integrating solutions that use the mandatory tools.
So, the net effect of skill disconnects and mandatory tooling can be a kind of chaos! All the more so as the technologies change and evolve to meet new requirements. An example of such evolutionary change is the rise and rise of Java annotations.
What’s really needed is software environments and tool chains that subsume many of the integration problems facing developers. This would also help developers to fill in the gaps at the edges of their expertise—e.g., a front-end developer could learn more about service layer coding or even persistence layer development. This would help to remove the current artificial boundaries that separate so many developers.
I believe EJB3 and JBoss5 may go a long way towards making a lot of things easier. This is because EJB3 is a well-integrated software platform that goes a long way to providing a single server-side component model. Likewise, JBoss5 incorporates many features that make it a good choice for modular development (i.e., the platform grows as your needs expands). To see why this is so, let’s now take a look at JBoss5.
The JBoss Microcontainer and Why It Matters
Many application servers are monolithic beasts that contain all Java EE platform services. This means such servers are big, resource-hungry, and potentially hard for developers to learn by trial and error. JBoss is different—really different—because it’s based on what’s called a microcontainer design.
Now, don’t get turned off by the name! A microcontainer simply means that JBoss starts out as a very compact entity into which you plug extras as required. The extras can be services or user components that you add at runtime. In other words, the microcontainer design allows you to grow the JBoss application server itself from a tiny seed into whatever size you require for your solution.
I’m not going to go into any more detail on the JBoss microcontainer. There’s a ton of information on this topic in the JBoss5 distribution. Instead, I’m going to focus on demonstrating an end-to-end example of a simple EJB3 component.
Getting JBoss5 Installed and Working
To install JBoss5, just download the distribution from the JBoss website.
Pick the latest release, which at the time of writing is 5.0.0.GA. Click the Download link and save the zip file to your local disk. Open the zip file and extract the contents to a folder such as: C:\jbossas.
The next step is learning how to start and stop the JBoss5 application server.
Starting and Stopping JBoss5
To start the server, open a DOS console in the download folder and change to the subfolder called bin. Then, execute the run command. That’s it! If all is well with your installation, you should now see a few screenfuls of text ending with the following important one (they’re all important, but you know what I mean!):
14:35:21,792 INFO [AjpProtocol] Starting Coyote AJP/1.3 on ajp-127.0.0.1-8009 14:35:21,807 INFO [ServerImpl] JBoss (Microcontainer) [5.0.0.GA (build: SVNTag=JBoss_5_0_0_GA date=200812041714)] Started in 1m:36s:341ms
To stop the JBoss5 application server, just open another DOS console in the bin folder and run the following command:
shutdown –S
This should initiate an orderly shutdown of the application server. The next step is getting some Java code deployed on the server. But, before we do that let’s just get your environment set up.
Environment Settings
For starting and stopping JBoss5, you’re already good to go. However, to run some client Java code, you need the following environment variables:
- JBOSS_HOME must point to your JBoss5 installation folder.
- JAVA_HOME must point to your J2SE 1.5 SDK installation folder.
Ant must be on your system path.
The settings I used are shown here for illustrative purposes:
set JBOSS_HOME=C:\java\jboss5\jboss-5.0.0.GA set JAVA_HOME=C:\PROGRA~1\Java\jdk1.5.0_06
Once your environment is ready, you can then build and run the example EJB3 Java code. Just before we get to the code, there’s one optional configuration change you might like to make. It’s optional but I strongly recommend it.
Adding a Command Prompt Option to the Explorer Context Menu
From the previous section on starting and stopping JBoss5, there’s a very useful configuration change you can make to Windows XP to help speed things up. When you want to create a DOS command prompt (or DOS console) in a given folder, it’s a bit cumbersome to open a console and then change directory to the required destination. Instead of this, you can use Explorer and simply right-click the required folder. To install this feature, just go to this site and follow the instructions about updating the registry.
If you apply this change, you’ll be able to launch a command prompt from within Explorer. It’s now time for the EJB3 code!