The primary limitation of existing Java/XML solutions is the development overhead incurred to work with XML. Perhaps the greatest strength of XML is that it enables data to be passed around in a structured, human-readable document. In fact it is probably this strength which has led to the proliferation of Web services; to provide a service a vendor must only accept some readable document, rather than define a custom binary data format. But for the developer, this often means using an XML parser to extract out the relevant portions, convert them to some Java representation, and then use these Java objects through the system. While perhaps hard to believe, there are in fact many service implementations in Java which don't even use an XML parser, but in fact examine an incoming HTTPInputStream and use StringTokenizer or some such to extract the data.
On the export side, XML is often an afterthought when a new business requirement arises to export data to other clients. In this case the most common approach is a liberal use of System.out.println(), of if lucky, a templating tool like Velocity.
In addition to the development overhead, handling XML through this kind of approach is error-prone. Even if an XML schema does exist to represent the XML data, the developer often doesn't reap the benefits of type-safe data, because through an import-export approach, the validation can only be applied when XML data enters or leaves the system. So while a developer may choose to use XML schema, XML validation works only on the document; for Java objects, a developer must manually create pre and post conditions in the setter methods to validate the data.
Both the development overhead in handling XML and the difficulty of data validation results in a third difficulty: the representation of the data is unlikely to change. As business requirements change, an implementation using an import-export approach is not agile enough to keep up with the changes. Modifying a schema results in refactoring the parsing code, XML generation code, and validation code which may be scattered throughout many Java objects in the system.
There is a better solution. XMLBeans overcomes these difficulties by treating Java and XML as one. By leveraging the power of XML Schema to provide structure and constrained datatypes, developers access XML documents directly as Java objects. Using XMLBeans, the Java developer does not need to spend time writing import/export and validation code. Instead, XML documents are treated as first class data objects accessed in a JavaBeans-like manner.
In addition to the benefit of eliminating 'glue' code and manual data validation, a great design-time benefit of XMLBeans is that it provides the capability to have an executable specification. That is XMLBeans provides an automatic mapping between a schema and the Java type system. For the developer, this means that the design does not need to be translated to a Java implementation. The design of the data model or objects can be completely done in the specification of a schema; XMLBeans automatically translates the schema types and their relationships to Java objects and their relationships. So when a Java application receives an XML document which conforms to a given schema, XMLBeans creates corresponding Java instances which are built directly on the underlying document without loss of the original. When the Java instances are modified, XMLBeans modifies the document to keep the two in sync. Therefore, for all intents the Java objects and the document are the same.
To emphasize the practicality of XMLBeans, it is useful to look at a few examples where XMLBeans really shines:
- Persistence: Nearly every application stores user or application data in some file, with its contents commonly being XML. XMLBeans lets you work on those files without manually creating Java objects to represent the file contents.
- Communication: A good service-oriented architecture extrudes data from the internals of a system and uses XML documents passed between Web services to represent business state. With XMLBeans and the WebLogic Web service stack, Java developers are able to communicate with services through Java interfaces, the XML documents used by the services becoming XMLBeans instances.
- A Better Data Transfer Object (DTO): The DTO pattern is commonly used in J2EE applications to provide coarse-grained access to entity beans through a Session Façade. A DTO represents a snapshot of the state of a collection of entities. Before XMLBeans, these Java objects and their contents would have to be created by hand with manual checks for validation. Now, with XMLBeans it is possible to create a DTO with inherent validation simply by writing an XML schema.
These examples have shown that XMLBeans are truly the next-generation data object for Java. With a high-performance, open-source implementation, XMLBeans overcomes the traditional difficulties in using XML with Java and additionally provides data validation and the capability for executable specifications. Finally, by keeping the document in lock step with the Java objects, XMLBeans provide the fusion of Java and XML needed for service-oriented development.
Learn more about XMLBeans.
