Java & XML Data Binding

API Transparence

Before wrapping up on theory and concepts, I wanted to dive into some theoretical issues; don’t worry, I’ll keep it short and to the point! The issues I want to address relate to API transparence. When using data binding, you actually spend very little time working directly with the data binding API itself; instead, you work with classes generated by the API. Because of that, these generated classes become critical to your applications. However, when an API severs itself from the classes it generates, you can run into all sorts of nasty problems.

Note

Actually, the API only appears to sever itself in many cases. In other words, many frameworks generate classes with methods like this:

public static EjbJar unmarshal(InputStream inputStream) 
    throws IOException {
    return (EjbJar)Unmarshaller
        .unmarshal(inputStream, EjbJar.class);
}

As you can see, the method on the generated class simply hides the details of using the API from your programs. However, from your application’s point of view, you aren’t interfacing with the data binding API in your code.

Independence

The first thing you’ll want to make note of is the level of independence your generated classes offer you. In other words, are you tethered to the data binding API at runtime once classes are generated? Or do your classes run without ever using that API? The latter case is referred to as API independence. Obviously, the fewer dependencies your generated classes have, the easier deployment becomes.

Another question ...