For Java developers the evolution to Web services simply seems the next logical step. Not surprisingly, then, commercial J2EE platform vendors have also jumped on the bandwagon, weaving special Web services capabilities into their development tools and application servers. How important are these features in smoothing the creation and deployment of Web services? How real are their advantages over open source? Which J2EE application server is the best platform for Web services? To find out, we rounded up the two leading commercial J2EE servers, BEA Systems’ WebLogic and IBM’s WebSphere, plus a solid also-ran, Sybase’s EAServer, and the most popular open source J2EE server, JBoss, and we put them to the test.
Deploying Web services on each of these platforms, we evaluated their related management capabilities as well as their support for the core Web services standards, SOAP, XML-RPC (Remote Procedure Call), WSDL, and UDDI. We also looked for flexible configuration and a set of features, such as support for JMX (Java Management eXtensions), JNDI (Java Naming and Directory Interface), JMS (Java Messaging Service), and JTA (Java Transaction API), that we would expect in any enterprise-class Java platform.
In our test scenario, we implemented a multitier supply chain composed of four Web services developed using Metrowerks CodeWarrior and Eclipse. One service allowed a retail customer to buy a product from a retailer. A second service allowed the retailer, in turn, to purchase wholesale goods from a supplier. A third allowed the wholesaler to purchase raw materials from a parts supplier. Finally, a fourth service allowed all of these parties to track their shipments. We coded all of the business logic in Java, and created adapters to implement each component as a Web service. Using compliance verification tools from IBM and The Mind Electric, we made sure that all our test applications adhered strictly to the four core Web service standards: SOAP, XML-RPC, UDDI, and WSDL
The chief benefit of Web services is flexibility — allowing application logic to be changed without altering the service interface and disrupting business partners. Deploying, modifying, redeploying, and ensuring that your Web services are always available are the key ingredients of a successful Web services recipe. Therefore, our test focused on how smoothly our four solutions handled these tasks.
The open source alternative
To compete with the commercial contenders, our open source solution would need several elements. We chose JBoss 3.2.1 as our application server because it’s generally considered the most popular and most feature-rich open source J2EE application server available. Apache Tomcat 5.0 served as our servlet engine, and Apache Axis as the SOAP implementation.
Installing all these tools was simple. Unlike the commercial solutions, JBoss and Tomcat require no fancy installation routines. Simply unzip or untar (depending on the platform) the application files into your directory, and you’re off and running, no thinking required. And because of the small size and simplicity of the installation, it’s easy to create hands-off installation scripts that won’t clobber your network.
The downside of the easy installation turned out to be a lack of configuration options afterwards. All we had for JBoss were two basic tools, the Application Manager and the Administration tool. Both are functional, but sparse in features and customisability — either you work their way or you use something else. Even so, you’ll find most of the features you need for enterprise manageability as long as you familiarise yourself with JMX (Java Management eXtensions). The JBoss architecture is based on JMX and MBeans, and the server uses a variation of the JMX Mlet syntax to specify configuration information.
Compared with the GUI-based tools provided in WebLogic, WebSphere, and EAServer, the management features in Axis, Tomcat, and JBoss were mediocre. We found it more difficult to administer our open source server than any of the commercial solutions, mainly because of the depth of knowledge required to customise or change anything.
Expertise is also required to take advantage of advanced features. For example, implementing server clustering requires proper manipulation of MBean syntax at the server command line and in the supporting application.
Moreover, JBoss lacked tools for managing large, multiserver enterprise installations. On the upside, once our server was configured correctly, we hardly needed to manage it at all — it just kept chugging along. And some third-party management tools, such as performance management and Web services orchestration software, are available for JBoss, thanks to partnerships with several open source vendors.
In our deployment test we took our standard J2EE .war (Web Archive) file and deployed it using the Tomcat Application Manager without any fuss. We had several options in deployment tools, including the Tomcat Application Manager, the popular open source Ant tool, or an XML configuration file. There was no need to restart the server after deployment. We simply deployed and started accessing.
Undeployment was also uneventful, once we got the hang of our management tools. We were able to remove the application without a restart. We also had the option of simply stopping the application without removing it and taking it off-line for reconfiguration. As with WebSphere, however, we did have to restart the server after we modified our application and redeployed it.
One thing that was apparent from our testing was that JBoss supports all the relevant standards. It just doesn’t do so via menus, wizards, or cute talking icons; you’ve got to know J2EE and Java syntax. If you fall into that category, JBoss can provide a granularity of application control rivalled only by the Web Services SDK offered by IBM.
Further, although this review paints JBoss as functional though Spartan, changes are on the way. The upcoming version, JBoss 4.0, promises exciting new features, including an enhanced JMX microkernel that will allow features and components to be added individually; that means no additional overhead for resources you don’t use. And a new programming framework, called AOP (Aspect Oriented Programming), means development teams can enable plain old Java objects to mimic J2EE-like functionality or even add EJB-like transaction attributes to them. The battle between commercial tools and open source innovation is far from over.
Web services workshop
BEA’s WebLogic was the first commercial product we tested following our initial open source test, and differences were apparent right away. WebLogic offers a full range of configuration options, a rich set of enterprise-class features, and an elegant GUI for implementing them. Not only did everything run correctly out of the box, but we were up and running in only a few minutes — that’s impressive for an enterprise-oriented development environment.
We were also impressed by the flexibility of the installation process, which was streamlined and simple, allowing us to quickly pick and choose which components to install and which to register as services on a Windows server. One helpful addition would be a scripted, hands-free installation process that would make it easier to install on multiple servers.
Once installed, configuring WebLogic held a few surprises. Chief among these was the frequency with which we had to reboot the server. This was surprising from two perspectives. First, WebLogic is written in 100 per cent Java, which generally means fewer reboots. Secondly, WebLogic is designed as an enterprise-level application platform, so it’s difficult to understand why BEA would force you to bounce your production server for configuration changes as slight as switching the HTTP listen port. BEA does provide hot deployment support for JSPs and EJBs, but has yet to deliver hot deployment to the Web services arena.
These gripes aside, the flexibility we saw in WebLogic’s installation process carried through to server configuration. For example, there is an extensive set of configuration options for individual server instances, allowing you to reconfigure practically every aspect of the basic configuration, the cluster, the deployment, and performance tuning. There is also support for Ant-based Web service configuration tools providing built-in compliance checking.
During testing, WebLogic performed well, but with a few gotchas. First, we were required to make changes to our application in order for it to function on WebLogic. Second, although we tried, we weren’t able to deploy our test application directly from the server console. Instead we had to use BEA’s new companion IDE, WebLogic Workshop. Third, after we deployed our application, it was easy to reconfigure via the console, but every change required a server reboot.
WebLogic Workshop also had its share of ups and downs. A time-saving tool for creating J2EE apps and Web services, Workshop provides a visual development environment similar to Microsoft’s Visual Studio. Additionally, Workshop provides a run-time framework that manages service deployment, and also adds testing and debugging features. All the ingredients for a successful IDE are here, but Workshop was still a little raw, even from our limited testing perspective. However, once you get used to Workshop’s naming and descriptor requirements, integration between IDE and server is actually quite impressive.
Entering the WebSphere
The first thing you notice about WebSphere 5.0 and WSAD (WebSphere Studio Application Developer) are the CDs. It’s as if you opened up a promotional package from Columbia Records. After sifting through the 54 included discs, you’ll probably find what you’re looking for.
IBM ships the works — app servers for every operating system, clients for the same, the DB2 database management system, toolkits, deployment manager, a directory server, edge components, and more. Looking through all this stuff, it’s hard not to get the feeling that you’ve gotten your money’s worth.
Despite the overabundance, installation is fairly simple, though unexpectedly time-consuming. In fact, we had more trouble figuring out which CDs to install than we had installing them. You’ll even find an installation verifier that checks to make sure everything installed correctly.
Configuring WebSphere is also straightforward, and IBM has added some likeable new features. For one thing, we liked the log viewer. It’s not as easy to use as the one from Sybase, but it has a true log analyser built in. Systems administrators will also like the Performance Viewer, which allows them to track summary reports on system resources, including EJB usage, HTTP usage, and more.
WebSphere’s network deployment options contain several wizard-style tools designed specifically for deploying, configuring, and managing Web services across a large number of servers and server clusters. Several of these tools can be automated, and for those of you married to the command line, IBM still provides plenty of functionality there as well.
Our deployment test went exceptionally smoothly with WebSphere; in fact, we’d say WebSphere performed best of the lot in this department, even if it is browser-based. For one thing it was extremely easy and intuitive to use — no learning curve here whatsoever. Nor were we required to make any proprietary changes to our application to get it to run; in fact, WebSphere makes standards support as seamless as JBoss.
Further, WebSphere installed all of our J2EE-specific components with no renaming or fuss (and we tried a bunch of them just for fun, including J2EE .ear, .ejb, .jar, and .war). Unlike WebLogic, none of these configuration changes required a server bounce.
Undeployment was similarly impressive, though not so exciting to write about. The application simply disappeared — no reboot required.
We had little reason to use WebSphere’s companion IDE, WSAD, because so much of the Web service publishing process is built directly into the WebSphere console. We did use WSAD for our import testing, similar to the way we used Workshop with WebLogic, and the IDE imported all our J2EE components without a hiccup — though it did take rather long to accomplish this task. Once our services were imported, we used WSAD to modify them and found a Web service-oriented IDE worthy of Big Blue’s name.
WSAD is Java-oriented in its approach to Web service development, requiring that services be developed within a Java class that follows the basic bean pattern. You’ll also find that WSAD is oriented towards large development teams rather than individual programmers. For example, a test copy of WebSphere’s Application Server installs with every WSAD installation, allowing multiple programmers to test their parts of an application simultaneously without conflicting. For those interested in more command line and less GUI, IBM also provides the IBM WebSphere SDK for Web Services, though we didn’t get a chance to test this.
In summary, WebSphere rates highly as a manageable Web services publishing platform.
Services by Sybase
Sybase’s EAServer 4.2 is set apart by its intuitive and efficient IDE and enterprise-class relational database. It’s hurt, however, by a lack of support for some Java Web service standards, notably JMX. And although EAServer negotiated our test without much trouble, it simply isn’t as polished as WebSphere.
Installing the EAServer suite was simple. We liked the ability to pick and choose our installed components so easily, and once installed, the server was up and running right away.
EAServer has added a few new features specific to Web services. Displayed on the left side of the GUI in tree format, these include a deployment tool, an installation tool, and a Web service utilities section, which includes a packager, deployer, and installer. Need more functionality? EAServer allows developers to write Java plug-ins to the management console for even more advanced customisation.
We also liked EAServer’s navigation capabilities. This is truly a purpose-built environment. That means that you’re not limited to the UI elements and potential security flaws of a Web-based management console. Even IBM’s WebSphere didn’t provide an interface this efficient. And for those who want it, Sybase allows full administrative functionality at the command line.
Our deployment tests ran without any trouble, though we did have to restart the server to access the newly deployed application. In general, Sybase and WebLogic follow the same steps for deployment: first, deploy; second, install; and third, reboot the server. That last one is the doozy.
Among the nice features we found was built-in versioning, which makes it easy to track iterations of a deployed application and roll back to previous known working versions, if necessary. EAServer also allows you to export your application back to a standard J2EE .war or .jar file. We didn’t see this ability in WebLogic or JBoss. It’s not a deal breaker, but it is a nifty tool to have at your fingertips.
All in all, EAServer performed quite well without a bundled Web service-oriented IDE. Indeed, its ability to import and export any J2EE-compliant program file means developers aren’t locked into any one IDE but are free to choose from a vast assortment of third-party products.
As a Web service publishing platform, EAServer could use a few improvements, such as support for JMX and Microsoft .Net. We’re not privy to what Sybase has planned for the next version, but if EAServer includes the right mix of new features, it will be a strong competitor among Web service management platforms in future iterations.
Server of services
In the end, our testing brought a number of interesting results to light. First and foremost, the inclusion of tools that strictly support Web services standards, or that ease or accelerate the coding process, is not a sufficient criterion for platform selection. With the possible exception of BEA’s highly sophisticated Workshop IDE and its conventions, all these products generally tie in their ability to support Web service development.
More important differences lie in how smoothly these platforms handle services deployment, how much control they provide over Web services applications during run time, and how well their feature sets meet enterprise requirements.
Overall, we found that IBM’s WebSphere handles Web services deployment and management better than the rest. WebSphere also provides a rich set of enterprise features, although all four solutions have strengths here.
Finally, although JBoss had all the programming goods we could hope for, it really needs to improve the quality and breadth of its administration tools to compete at the enterprise level. But it’s more than adequate for smaller fish that don’t want to pay exorbitant licensing fees.