1. Universities are supposed to fill the niche in the education system in which we train people to lead institutions and invent the future. I don’t want computer science students studying Spring and Scrum (neither of which will be relevant in ten years). I want them inventing new programming languages, I/O devices, and non-Von Neumann CPUs. I want them studying history so that when they are elected to Congress, they won’t act like idiots. I want them studying language, so that when they make speeches, they won’t sound like they’re illiterate. Let the red-brick universities and multi-compass-point institutions teach Scrum and Spring. Universities should be teaching foundational skills that will be relevant for fifty years, and that can’t be easily learned on one’s own.

2. Once upon a time, the implied contract between employers and employees included on-the-job training. Staff were hired on the basis of personality, brains, and initiative, and the specific requirements of the job would be learned on company time. Today every employer wants their staff to be highly trained, but on someone else’s nickel. Why must it be up to the universities? Even if young employees are perfectly launched, they still need to keep current or they will be obsolete in 5-10 years anyway. Universities should equip people with the underlying skills to keep current - a passion for learning, an ability to focus, and a love of reading. Keeping current is an ongoing activity in any case.

3. Current graduates don’t seem to be able to read, write or do math anyway. (Here’s where I stop defending universities.) Seriously, how can anyone get through 16+ years of education and not be able to write? It’s gotten to the point where if I see a business document with no major grammar errors, I say to myself “how refreshing”. That’s very sad. Same for math; a basic knowledge of statistics is helpful in almost any area of business - but try to find someone who knows the difference between mean and median. My point is that if universities are going to do any refocusing at all, it should be on core skills.

So I urge Ivy League schools to go ahead and teach linear algebra and theory of computation and Haskell programming (which I bet we’re all using in five years anyway - seriously- but that’s another blog entry). And make the kids read Shakespeare and Faulkner. When they’re in charge of everything, we’ll be glad of it.

But I also believe in the “when in Rome” principle. As developers, we should try to conform to the spirit and assumptions behind the tools we are using (e.g. nobody will thank you for using Lisp idioms in Java). So if we have to use ClearCase, and the Atria / Rational / IBM people expect us to develop on private branches, maybe we should. Opinions?

Transaction Example

Both transactions are trying to process withdrawals of $100. In either case, if the balance is sufficient, a status message is sent to a downstream system and the balance is reduced. Otherwise the transaction is aborted. If these transactions are run in the serializable isolation level, can they be executed concurrently without fear of overdrawing the account, sending the status message more than once, or creating any other problems? Actually, no.

A cursory read of the documentation on database isolation levels might lead you to believe that serializable means that transactions act as though they are being run serially, i.e. as if they had been synchronized (using Java terminology). But that would be wrong. Databases are only required to honor commitments about serializability from the perspective of the data they store. So in the example above, the database’s only responsibility is to ensure that the balance doesn’t go negative.

Oracle read the fine print carefully and came up with a creative way to improve performance. It lets both transactions proceed full steam ahead, but only permits the first update statement to succeed. The second update will fail with an error:

ORA-08177: Can't serialize access for this transaction.

Your application has to check for this error and retry the whole transaction until it succeeds. It’s really quite smart. Essentially, Oracle is optimistically running the transactions as quickly as possible, hoping they would have been serializable. If that turns out to be wrong, Oracle tries to forget the whole thing happened by aborting the transaction. The result is higher concurrency and better performance than the more obvious locking based design, and it faithfully preserves the serializability rule.

The only problem is that in our example, the status message will get sent too many times. Oracle doesn’t care about the serializability of your non database-related application code. In the example above, only one of the transactions should succeed because the initial balance is $100. But both of them will send the message. The moral here is that you can’t use the serializable database isolation level to manage concurrency in your application code.

So what can you do? You could serialize the whole application code sequence (i.e. wrap it all in a synchronized block) but that would be needlessly throwing away performance. You could create a thread pool that guarantees that requests for the same ID will get serviced by the same thread, but that would be needlessly complicated. The simplest solution (which will work even if you run multiple instances of your entire application) is to have the database lock the row during the transaction, so that if any other transactions touch that row they will block until the running transaction completes.

Oracle allows you to do this by adding the clause FOR UPDATE to your select command, i.e.

select balance from account where id = 123 for update

That’s nice and simple, allows you to run your transaction in the usual, uncomplicated READ_COMMITTED isolation level, allows concurrent processing of different database rows without any possibility of race conditions, and doesn’t require any synchronization in your application code. Unfortunately it’s not portable. It works with Oracle and Sybase, but the rules for MS SQLServer are different.

Here is a solution, the main element of which came from a posting on the Codeplex web site from someone called XIU for which I’m grateful. I thought I would add some more detail in case anyone else has this problem and wants a more cut and pasty solution.

Say you have a class called Product, each instance of which has an ID and a Description, and a class called Order, each instance of which has a Quantity and a Product ID (to be used like a foreign key to designate the order’s product).

These classes must implement the INotifyPropertyChanged interface. Here are the first few lines of each:

public class Product : INotifyPropertyChanged
{
  public int ID { ... }
  public string Description { ... }
  ...
}
 
public class Order : INotifyPropertyChanged
{
  public int ProductID { ... }
  public int Quantity { ... }
  ...
}

Create a simple ViewModel (i.e. binding context) and set the DataContext of the main window to an instance of this object:

namespace ComboBoxDemo
{
  public class ViewModel
  {
    public ObservableCollection<Order> Orders { get; set; }
    public ObservableCollection<Product> Products { get; set; }
 
    public ViewModel()
    {
      Products = new ObservableCollection<Product>();
      Products.Add(new Product(100, "Widget"));
      Products.Add(new Product(101, "Sprocket"));
      Products.Add(new Product(102, "Gadget"));
 
      Orders = new ObservableCollection<Order>();
      Orders.Add(new Order(102, 15));
      Orders.Add(new Order(102, 32));
      Orders.Add(new Order(100, 42));
    }
  }
}

Create a helper class using XIU’s solution:

namespace ComboBoxDemo
{
  public class DataGridComboBoxColumnWithBindingHack : DataGridComboBoxColumn
  {
    protected override FrameworkElement GenerateEditingElement(DataGridCell cell, object dataItem)
    {
      FrameworkElement element = base.GenerateEditingElement(cell, dataItem);
      CopyItemsSource(element);
      return element;
    }
 
    protected override FrameworkElement GenerateElement(DataGridCell cell, object dataItem)
    {
      FrameworkElement element = base.GenerateElement(cell, dataItem);
      CopyItemsSource(element);
      return element;
    }
 
    private void CopyItemsSource(FrameworkElement element)
    {
      BindingOperations.SetBinding(element, ComboBox.ItemsSourceProperty,
        BindingOperations.GetBinding(this, ComboBox.ItemsSourceProperty));
    }
  }
}

This is a variant of the DataGridComboBoxColumn class which handles binding differently to allow the ItemsSource property to have access to the binding context. Now put it all together with the following XAML:

<Window x:Class="ComboBoxDemo.Window1"
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
  xmlns:wpf="http://schemas.microsoft.com/wpf/2008/toolkit"
  xmlns:local="clr-namespace:ComboBoxDemo"
  Title="Window1" Height="300" Width="300">
  <wpf:DataGrid ItemsSource="{Binding Orders}" AutoGenerateColumns="False">
    <wpf:DataGrid.Columns>
      <wpf:DataGridTextColumn Header="Quantity" Binding="{Binding Quantity}" />
      <local:DataGridComboBoxColumnWithBindingHack
        Header="Product"
        SelectedValueBinding="{Binding ProductID}"
        SelectedValuePath="ID"
        DisplayMemberPath="Description"
        ItemsSource="{Binding RelativeSource={RelativeSource Findancestor, AncestorType={x:Type Window}}, Path=DataContext.Products}" />
    </wpf:DataGrid.Columns>
  </wpf:DataGrid>
</Window>

The SelectedValueBinding attribute indicates the Order property containing the foreign key designating the product (i.e. which value should be edited by the combo box). The SelectedValuePath attribute indicates which property within the product object contains the product ID, and the DisplayMemberPath attribute indicates which property should actually be displayed in the grid. Finally the ItemsSource attribute indicates how to get the list of products by navigating to the parent window object and looking up the list of products from the parent window’s binding context.

Here is the complete project source as a downloadable zip file.

I hope this saves someone some time, and that it’s easier to do all of this in future versions of the WPF Toolkit. If anyone has a better solution to this problem, please let me know.

First, method invocations and any other operations performed using reflection are not typesafe:

MethodInfo methodInfo = myObject.GetType().GetMethod("MyMethod");
methodInfo.Invoke(myObject, new object[] {});

There is no way at compile time of protecting against a type error in that code sequence. Second, most programmers won’t be able to resist checking that methodInfo is non-null, to protect against a possible null pointer exception:

MethodInfo methodInfo = myObject.GetType().GetMethod("MyMethod");
if (methodInfo != null)
{
  methodInfo.Invoke(myObject, new object[] {});
}

That’s not a bad instinct. After all, who knows what kind of myObject might be passed to this code? But now we’ve subverted the type system twice. It can’t check that we’re calling the method correctly, and it can’t even check that we’re providing the right kind of object. If we provide the wrong kind of object, this code will simply do nothing, probably causing a mysterious, silent failure.

Let’s see, what other kinds of trouble can we get into? Say we refactor the code and change the name MyMethod to something else. A smart IDE can do this automatically for us - but it will miss the reflection-based calls since they are only visible to the IDE as character strings. What will our code example do in this case? It will fail mysteriously and silently again.

Reflection also undermines program correctness by encouraging the creation of implicit contracts. Normally if you want to create a clear contract between two classes, you create an interface. For example, if you have a strange kind of collection class which calls WriteAuditRecord() on each object that is added, you might define the collection to accept only contents of type Auditable, which would be an interface with a WriteAuditRecord() method. Anyone using the collection would get a compile-time type error if they attempted to compile code which inserts objects that do not support that method. That would lead them to read the documentation in the Auditable interface and learn about the contract between the classes. But you could also create a clever solution using reflection to check whether any inserted items support a WriteAuditRecord method, and if so call that method automatically. That would allow programmers to add items to the collection without changing their implementation to implement the Auditable interface. More flexible, right? Except that if a programmer accidentally misspells the method as WriteAudiRecord, it will not get called; another silent error that would normally have been caught by the typechecker. Or even spookier, programmers might not know about this special audit behavior and be surprised when their WriteAuditRecord() method gets called for no apparent reason.

I’d also like to take a poke at another sacred cow: attributes (or annotations if you’re a Java person). My main beef with these is that to use them, you need to use reflection. See above.

I’m not 100% against the use of reflection and annotations. They can be very useful when creating frameworks that need to work on any kind of object (e.g. for serialization and persistence, or for configuration systems like Spring) but my point is they should be used sparingly and you should take a shower afterward.

<?xml version="1.0" encoding="UTF-8"?>

<xsd:schema targetNamespace="http://com.joemo.schema.trade" xmlns="http://com.joemo.schema.trade"
	xmlns:xsd="http://www.w3.org/2001/XMLSchema">

	<!-- web service input types -->

	<xsd:element name="trade">
		<xsd:complexType>
			<xsd:sequence>
				<xsd:element name="security" type="xsd:string" minOccurs="1" maxOccurs="1" />
				<xsd:element name="quantity" type="xsd:integer" minOccurs="1" maxOccurs="1" />
				<!-- note the use of "unbounded"; comments can occur multiple times -->
				<xsd:element name="comments" type="comment" minOccurs="1" maxOccurs="unbounded" />
			</xsd:sequence>
		</xsd:complexType>
	</xsd:element>

	<xsd:complexType name="comment">
		<xsd:sequence>
			<xsd:element name="message" type="xsd:string" minOccurs="1" maxOccurs="1" />
			<xsd:element name="author" type="xsd:string" minOccurs="1" maxOccurs="1" />
		</xsd:sequence>
	</xsd:complexType>

	<!-- web service output types -->

	<xsd:element name="status">
		<xsd:complexType>
			<xsd:sequence>
				<xsd:element name="id" type="xsd:string" minOccurs="1" maxOccurs="1" />
				<xsd:element name="message" type="xsd:string" minOccurs="1" maxOccurs="1" />
			</xsd:sequence>
		</xsd:complexType>
	</xsd:element>

</xsd:schema>

Next, we need the trade.wsdl file which imports the schema file and completes the WSDL definition:

<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace="http://com.joemo.schema.tradeservice"
	xmlns="http://com.joemo.schema.tradeservice"
	xmlns:tr="http://com.joemo.schema.trade"
	xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
	xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

	<wsdl:types>
		<xsd:schema targetNamespace="http://com.joemo.schema.tradeservice">
			<xsd:import namespace="http://com.joemo.schema.trade" schemaLocation="trade.xsd" />
		</xsd:schema>
	</wsdl:types>

	<wsdl:message name="tradeInput">
		<wsdl:part name="trade" element="tr:trade" />
	</wsdl:message>

	<wsdl:message name="tradeOutput">
		<wsdl:part name="status" element="tr:status" />
	</wsdl:message>

	<wsdl:portType name="TradeService">
		<wsdl:operation name="book">
			<wsdl:input message="tradeInput" />
			<wsdl:output message="tradeOutput" />
		</wsdl:operation>
	</wsdl:portType>

	<wsdl:binding name="TradeServiceHTTPBinding" type="TradeService">
		<wsdlsoap:binding style="document"
			transport="http://schemas.xmlsoap.org/soap/http" />
		<wsdl:operation name="book">
			<wsdlsoap:operation soapAction="" />
			<wsdl:input>
				<wsdlsoap:body use="literal" />
			</wsdl:input>
			<wsdl:output>
				<wsdlsoap:body use="literal" />
			</wsdl:output>
		</wsdl:operation>
	</wsdl:binding>

	<wsdl:service name="TradeServicePorts">
		<wsdl:port binding="TradeServiceHTTPBinding" name="TradeService">
			<wsdlsoap:address
				location="http://localhost:9084/tradeService/TradeServicePorts" />
		</wsdl:port>
	</wsdl:service>

</wsdl:definitions>

Now we need a Maven project file that will take this WSDL and generate the Java code. Here’s what the pom.xml file looks like. It’s long and messy but it does a lot. It specifies all the dependencies and the compiler level, includes the rule to generate Java code from WSDL whenever necessary, and includes Jetty and WTP support for testing and running the web services in different environments.

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<groupId>com.joemo</groupId>
	<artifactId>ws-example</artifactId>
	<packaging>war</packaging>
	<version>0.1</version>
	<name>ws-example</name>
	<url>http://maven.apache.org</url>
	<properties>
		<cxf.version>2.1</cxf.version>
		<spring.version>2.5</spring.version>
	</properties>
	<dependencies>
		<dependency>
			<groupId>org.apache.cxf</groupId>
			<artifactId>cxf-rt-core</artifactId>
			<version>${cxf.version}</version>
		</dependency>
		<dependency>
			<groupId>org.apache.cxf</groupId>
			<artifactId>cxf-rt-frontend-jaxws</artifactId>
			<version>${cxf.version}</version>
		</dependency>
		<dependency>
			<groupId>org.apache.cxf</groupId>
			<artifactId>cxf-rt-transports-http</artifactId>
			<version>${cxf.version}</version>
		</dependency>
		<dependency>
			<groupId>org.apache.cxf</groupId>
			<artifactId>cxf-common-utilities</artifactId>
			<version>${cxf.version}</version>
		</dependency>
		<dependency>
			<groupId>org.springframework</groupId>
			<artifactId>spring-core</artifactId>
			<version>${spring.version}</version>
		</dependency>
		<dependency>
			<groupId>org.springframework</groupId>
			<artifactId>spring-beans</artifactId>
			<version>${spring.version}</version>
		</dependency>
		<dependency>
			<groupId>junit</groupId>
			<artifactId>junit</artifactId>
			<version>4.4</version>
			<scope>test</scope>
		</dependency>
	</dependencies>
	<build>
		<plugins>
			<!-- Use Java 5 -->
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-compiler-plugin</artifactId>
				<configuration>
					<source>1.5</source>
					<target>1.5</target>
				</configuration>
			</plugin>

			<!-- CXF WSDL-to-Java code generation -->
			<plugin>
				<groupId>org.apache.cxf</groupId>
				<artifactId>cxf-codegen-plugin</artifactId>
				<version>2.0.6</version>
				<executions>
					<execution>
						<id>generate-sources</id>
						<phase>generate-sources</phase>
						<configuration>
							<sourceRoot>${basedir}/target/generated/src/main/java</sourceRoot>
							<wsdlOptions>
								<wsdlOption>
									<wsdl>src/main/resources/trade.wsdl</wsdl>
								</wsdlOption>
							</wsdlOptions>
						</configuration>
						<goals>
							<goal>wsdl2java</goal>
						</goals>
					</execution>
				</executions>
			</plugin>
			<!-- Jetty support for testing -->
			<plugin>
				<groupId>org.mortbay.jetty</groupId>
				<artifactId>maven-jetty-plugin</artifactId>
			</plugin>
		</plugins>
		<!-- Eclipse WTP support -->
		<pluginManagement>
			<plugins>
				<plugin>
					<artifactId>maven-eclipse-plugin</artifactId>
					<configuration>
						<wtpversion>2.0</wtpversion>
						<wtpapplicationxml>true</wtpapplicationxml>
						<wtpmanifest>true</wtpmanifest>
						<downloadSources>true</downloadSources>
						<downloadJavadocs>true</downloadJavadocs>
						<projectNameTemplate>[artifactId]-[version]</projectNameTemplate>
						<manifest>${basedir}/src/main/resources/META-INF/MANIFEST.MF</manifest>
					</configuration>
				</plugin>
			</plugins>
		</pluginManagement>
	</build>
</project>

Among other things, the rules in this pom.xml file will generate a Java interface called TradeService (based on the names in the WSDL file). The only code we will have to write is the implementation of this interface. Although this generation is done automatically by any Maven commands that need it (e.g. mvn package or mvn install) you might want to force it to be done sooner rather than later, so that you can refresh your Eclipse project with the generated code, enabling Eclipse to recognize the interface that you’re trying to implement. You can do this using the commands:

mvn generate-sources
mvn eclipse:clean eclipse:eclipse

This generates Java code from the WSDL, then regenerates the Eclipse project files, after which you should be able to refresh the project in Eclipse. If you see errors about libraries not being found, you may need to configure Eclipse to know about your Maven repository, i.e. select Eclipse / Window / Preferences / Java / Build Path / Classpath Variables, then enter the appropriate settings, e.g.

Name: M2_REPO
Path: C:/Documents and Settings/MyAccount/.m2/repository

Once the project is properly configured in Eclipse, you can fill in the implementation:

package com.joemo.service;

import trade.schema.joemo.com.Comment;
import trade.schema.joemo.com.Status;
import trade.schema.joemo.com.Trade;
import tradeservice.schema.joemo.com.TradeService;

public class TradeServiceImpl implements TradeService {

	public Status book(Trade trade) {
		System.out.print ("Booking security ");
		System.out.print (trade.getSecurity());
		System.out.print (", quantity ");
		System.out.print (trade.getQuantity());
		System.out.println();
		if (trade.getComments() != null) {
			System.out.println ("Comments:");
			for (Comment c : trade.getComments()) {
				System.out.print (c.getAuthor());
				System.out.print (": ");
				System.out.print (c.getMessage());
				System.out.println();
			}
		}
		Status s = new Status();
		s.setId("12345");
		s.setMessage("ok");
		return s;
	}

}

We are almost done. We still need a web.xml file which will direct SOAP requests to the CXF infrastructure:

<?xml version="1.0" encoding="UTF-8"?>
<web-app id="WebApp_9" version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
	<context-param>
		<param-name>contextConfigLocation</param-name>
		<param-value>classpath:appContext.xml</param-value>
	</context-param>
	<listener>
		<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
	</listener>
	<servlet>
		<servlet-name>dispatcher</servlet-name>
		<servlet-class>org.apache.cxf.transport.servlet.CXFServlet</servlet-class>
		<load-on-startup>1</load-on-startup>
	</servlet>
	<servlet-mapping>
		<servlet-name>dispatcher</servlet-name>
		<url-pattern>/*</url-pattern>
	</servlet-mapping>
</web-app>

Finally, we need the appContext.xml file, which is the Spring configuration file loaded by CXF that defines the web service endpoint:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:context="http://www.springframework.org/schema/context"
	xmlns:jee="http://www.springframework.org/schema/jee" xmlns:jaxws="http://cxf.apache.org/jaxws"
	xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/jee http://www.springframework.org/schema/jee/spring-jee-2.5.xsd
http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-2.5.xsd
http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd"
	default-dependency-check="none" default-lazy-init="false">

	<!-- Load the needed resources that are present in the cxf* jars -->
	<import resource="classpath:META-INF/cxf/cxf.xml" />
	<import resource="classpath:META-INF/cxf/cxf-extension-soap.xml" />
	<import resource="classpath:META-INF/cxf/cxf-servlet.xml" />

	<!-- Hook up the web service -->
	<jaxws:endpoint id="ws-example" implementor="com.joemo.service.TradeServiceImpl"
		address="/ws-example" />

</beans>

That’s everything. There are six files, only one of which contains any Java code. You need to make sure you put each file in the right place:

ws-example/pom.xml
ws-example/src/main/resources/trade.xsd
ws-example/src/main/resources/trade.wsdl
ws-example/src/main/resources/appContext.xml
ws-example/src/main/webapp/WEB-INF/web.xml
ws-example/src/main/java/com/joemo/service/TradeServiceImpl.java

A zip file of this example is available for download here. To build and run it, you will need Maven to be installed on your development system. Unzip the file, and in the directory containing the pom.xml file, run the command:

mvn jetty:run

That will generate the Java code from the WSDL, build the example, and run the web service in the Jetty container. You should be able to visit the URL http://localhost:8080/ws-example/ws-example?wsdl from a web browser and see the WSDL for the web service, test the web service using SoapUI, and so on.

Alternatively you can run the command:

mvn eclipse:eclipse

and follow the directions from my earlier blog entry to run the example using Eclipse WTP, which will allow you to edit the code while keeping it synchronized with a live application server.

Good luck! If you encounter any problems using this template, please email me or post a comment so that I can look into it and revise the instructions if necessary.

Second, keep in mind that there are three important APIs which are inter-related: JAX-WS, JAXB, and StAX. Once you understand how these fit together, everything else falls into place more easily.

JAX-WS

Let’s begin our journey with the latest Sun standard for creating and consuming web services: JAX-WS, which stands for Java API for XML Web Services. This standard was introduced in 2004. You can ignore JAX-RPC, since JAX-WS replaces it.

There are three noteworthy implementations of JAX-WS. The first is from Sun, and is called JAX-WS RI for the JAX-WS Reference Implementation (they always had a way with names). The second and third are both from the Apache Group and are called Axis2 and CXF. You can ignore Axis1, XFire, and Celtix, since they are all obsolete. There is also a web service framework called Spring-WS, but it’s not JAX-WS compliant.

So if you are creating web services in Java, the first order of business is to to choose an implementation to work with, and unless you have a reason not to, you should probably stick to one that complies with JAX-WS, which means either JAX-WS RI, Axis2, or CXF.

Related to these is an open source project from Sun called Web Services Interoperability Technologies (WSIT), previously known as Project Tango. This is an implementation of several web service standards (WS-SecurityPolicy, WS-ReliableMessaging, and so on). Metro is an open source web service stack which is a combination of JAX-WS RI and WSIT (so it’s actually a reasonable fourth option).

JAX-WS is oriented around SOAP web services, but many programmers are now using the REST approach. Sun is coming out with the JAX-RS API to support that, but it’s not quite ready yet.

JAXB

Web service development requires mapping between XML and Java objects. JAXB is the Sun API for that (also referred to as JAXB2 since the latest version is the important one). There are two noteworthy implementations: JAXB-RI (Sun’s reference implementation) and JaxMe (the unfortunately named contribution from Apache). JaxMe is in the incubation stage and is not formally part of Apache yet. There are many other interesting and popular XML/Java mapping frameworks, but most of them are not compliant with JAXB. Examples include Castor (from Codehaus), JiBX (a spectacularly fast open source implementation), and XMLBeans (a flexible implementation from Apache).

A recurring source of confusion is that in the past, Sun was less clear about the distinction between APIs and reference implementations, so people would take JAXB to mean both, and you would often see online articles like “Which is better: JAXB or JiBX?” But today developers should always try to use the JAXB API, which will enable a choice of compliant implementations such as JAXB-RI or JaxMe with minimal or no code changes.

StAX

For Java code that needs to read and write large XML documents quickly without necessarily mapping them to objects, there is the Streaming API for XML (StAX). There are several implementations of this API too. There is the Sun Java Streaming XML Parser called SJSXP (another snappy name from Sun), the Woodstox open source implementation which is excellent, and the StAX reference implementation from Codehaus which is referred to simply as StAX (unfortunately perpetuating the confusion between APIs and implementations). Xerces is a streaming XML processing library which used to be part of the Apache project, and work was underway to make it StAX compliant, but that was dropped.

Putting it all together

Web services need to process XML, sometimes mapping it to and from Java objects (e.g. for creating proxy objects and an RPC-like experience), and sometimes processing it directly (e.g. for streaming results when high performance is needed). Therefore Sun designed the JAX-WS API to rely on the JAXB API, which makes perfect sense; any JAX-WS compliant web service implementation should be able to use any JAXB compliant mapping library. Other relationships between these APIs are up to individual implementations. For example, JAX-WS RI supports the StAX API, so you can use any StAX implementation for streaming. CXF also supports the StAX API, as well as a host of Java/XML mapping options including JAXB (allowing the use of any JAXB compliant mapping implementation), XMLBeans, Castor, and JiBX. Yes, they are heroes.

So if you get confused, just ask yourself clarifying questions like: Which Java web service libraries support JAX-WS? Which JAXB compliant Java/XML mapping implementation shall I use for this project? Which is better for processing streaming XML: Woodstox or the StAX reference implementation?

If you’re still confused, then just accept the recommendations I promised not to make: Use CXF for your web services (which complies with JAX-WS), JAXB-RI for your Java/XML mapping (which complies with JAXB), and Woodstox for streaming (which complies with StAX).

Error instantiating builder 'org.eclipse.stp.sc.annvalidator'.
Plug-in org.eclipse.stp.sc.annvalidator was unable to load class org.eclipse.stp.sc.annvalidator.builder.AnnValidator.

What? Did they even test this? And who is Ann Validator anyway? A quick Google search turned up incomprehensible articles with titles like “AnnValidator missing from Ganymede Update”. The gist of the articles was basically “oh yeah, we should clean up our releases better”.

I’m probably oversimplifying the Eclipse point of view, but I don’t really care. The point is, now I have to research an obscure problem in order to perform something that should be the most basic of activities - creating a simple web service, using a fresh download of a supposedly mature IDE.

There is only one thing keeping me from switching to Netbeans immediately and recommending that everyone dump Eclipse: I’m still waiting for a good Perforce plugin. Okay, two things: I’m also addicted to Max Uermann’s Goto File plugin.

It installed like a dream on top of DD-WRT, and the user interface is simple and clean. Most of the complexity is devoted to QoS functions, which I actually care about (unlike many of the obscure routing options provided by the original Linksys firmware) since I use my home computers for streaming music, Skype, and other network-intensive applications. Furthermore it provides nice usage monitoring and visualization tools. The user interface is a nice red color, the exact same shade as Campbell’s tomato soup.

After installation, my home network seems noticeably faster, but that may just be cognitive dissonance. (After all, if I spent an entire evening not making my network faster, that would make a pretty poor blog entry.) The main question now is whether my router’s reliability will improve, but from reviews online and my initial experience, I’m optimistic. We’ll see over the next few months.

If you decide to try installing Tomato, make sure your router hardware version is supported. For example, Tomato isn’t supported on the Linksys WRT54G V5 or later since Linksys removed half the RAM in all versions after V4.