Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
What Makes for Good Software These Days?
It’s now pretty widely considered that successful software-based solutions must have at least the following five characteristics:
- Low cost
- Flexibility
- Commoditized
- Standards-based
- Manageability
This also applies to both open source software and commercial solutions. In the remainder of this article, I’ll look at Apache Axis and see whether it possesses the above characteristics. This should help to determine how well Axis stacks up in a service-oriented world.
What Is the Cost of an Axis-Based Solution?
The fact that you can download Axis for free doesn’t mean it has no cost! All technologies have a total cost of ownership (TCO). Among others, this cost comprises the following:
- Ease of learning
- Ease of use
- Bugs
- Update paths and deprecation
- General risks
My own opinion about the TCO of Axis is that much of its cost derives from the installation phase. You have to be a pretty determined end user to break through the pain barrier of installation and deployment of Axis. What about learning Axis?
Some software packages are easier to understand than others. I’m not sure why this is so, but I’ve observed it often enough to convince myself it’s true! Take AspectJava as an example, which is an open source, aspect-oriented programming toolkit. AspectJava is a well-documented piece of technology, but it takes a while to break the outer shell and get into it. Apache Axis is also a little hard to breach for the reasons described above. In any case, TCO is increased if a software technology is hard to learn and master.
Ease of use will clearly affect TCO. If software is hard to use, it will take longer to get productive with it, which will make it a more expensive proposition to use that technology.
My own use of Axis hasn’t uncovered any bugs, but in general bugs present an important cost element. A serious bug can prevent effective use of derivative software features.
As framework software evolves, developers find better ways to do things. This also applies to legacy elements and often gives rise to the need to deprecate (or remove) support for specific API calls. This is a thorny issue that can add substantial refactoring costs to derivative software releases. For example, if I use an API call and that call is deprecated, the platform may no longer support the original call a few releases later. In this way, my code can become obsolete. Keeping up with the API changes results in what is potentially an unknown cost. For Axis and other open source software, the need to refactor APIs must be balanced against destabilizing end user software. This is an issue faced by both open and closed source developers.
The general risks of open source software have been fairly widely reported. Many CTOs shy away from open source on the grounds that support is potentially problematic. As the open source model matures and large organizations start to push more of their staff into the area, many of these objections will go away.
How Flexible Is an Axis-Based Solution?
We now know that you can use Axis to create web services, which can be of different types depending on your requirements. In some cases, you may want your service consumers to send and receive raw XML. Axis provides a fairly flexible service model. You can easily make changes to an Axis service and then redeploy that service.
Is Axis a Commodity?
I don’t think anyone would say Axis is a commodity at this point! Indeed, it’s not clear whether an open source technology can even become a commodity. But what I mean by a commodity in this context is simply that the technology is very widely used. If Axis is the technology of choice for SOAP clients and servers, it can become a commodity.
It’s possible the SOAP facilities that come as part of the .NET platform are more widely deployed than Axis, given the millions of Windows machines in the world. It’s also possible that Axis is somewhat Java-centric at the moment. Obviously, the language-agnostic nature of .NET doesn’t have this characteristic. These are interesting considerations: not everyone may want Java-centric SOAP, but not everyone may necessarily want Microsoft-centric SOAP, either. So, will Axis or .NET become the commodity item?
What about Axis and Standards?
Axis is strong on standards. It fits J2EE like a glove! This opens up the world of J2EE-compliant application servers. By association, this also allows Axis users to leverage the technologies that form part of J2EE (for example, XML, messaging, transactions, management, and so on). This is a key Axis advantage.
Axis and Manageability
On its own, Axis has limited management facilities, but that’s not the whole story. As described in the Informit Java Reference Guide, you can comfortably navigate through the Axis service lifecycle using command-line facilities. But it’s important to understand that Axis is an ancillary product in the sense that Axis services are deployed onto an application server. This means that the Axis services can to an extent be managed by the application server facilities. The latter are improving all the time and the J2EE compliance of Axis ensures that Axis is manageable—for example, Tomcat supports Java Management Extensions (JMX).
Tomcat supports JMX for simple get (retrieve) and set (update) commands. The Tomcat JMX features enable you to list all the loaded servlets with the command shown in Listing 1.
Listing 1 Interacting with the Tomcat JMX proxy servlet
http://webserver/manager/jmxproxy/?qry=qry=*%3Aj2eeType=Servlet%2c*
After executing the command shown in Listing 1, you may have to type a user name and password. If the command is successful, you should see a ton of information about loaded servlets.
Another manageability area in which Axis can help you is during installation/deployment with its so-called happiness page, as illustrated in excerpt form in Figure 3. The figure helps you to locate missing components, apply those components, and then retest. This beats cryptic failure messages!
)
Figure 3 Axis happiness page
To register Axis with Tomcat, you need to copy the contents of the webapps/axis folder (in the Axis setup directory) into the Tomcat webapps folder (in the Tomcat setup directory). Assuming that the happiness page is truly content, you’re ready to run Axis once this latter step is complete.