【正文】 e ModelViewController (MVC) pattern to their Web applications. In a traditional Web application, the view ponent is posed of JSPs, or perhaps another presentation technology such as Velocity templates. These presentation ponents update the user interface by dynamically producing a whole new page of HTML to replace what the user was previously looking at. In the case of a Java Web application with an Ajax UI, however, the JavaScript client code has ultimate responsibility for updating what the user sees, based on data received in response to an XMLHttpRequest. From the perspective of the server, the view bees the data representation it sends in response to client requests.Producing XML from Java classesThere are plenty of reasons to deliver Ajax responses as XML: every Ajaxcapable browser has methods for navigating XML documents, and there are many serverside technologies for working with XML data. It39。s easy to define the contract between your Ajax client and server by producing a schema to describe the types of documents that will be exchanged, and if you take a serviceoriented approach to your serverside architecture, using XML allows nonAjax clients to consume your data feeds as well.I39。ll consider three of the ways you can produce XML data from your Java objects and discuss the pros and cons of each.Rollyourown serializationFirst of all, you could generate XML programatically from your object graph. This approach can be as simple as implementing a toXml() method in each of your JavaBean classes. You would then pick a suitable XML API and have each bean emit elements to represent its state and recursively call down the object graph to its members. Clearly, this approach doesn39。t scale well to a large number of classes because each one needs to have its own XMLgenerating code specially written. On the upside, it39。s a simple approach to implement, there39。s no overhead in terms of extra configuration or a moreplex build process, and any graph posed of your JavaBeans can be turned into an XML document with a couple of calls.XML binding frameworksIn recent years, several Java APIs have been developed to simplify the process of binding XML documents to Java object graph representations. Most provide both XML marshaling and unmarshaling。 that is, they perform twoway conversions between Java object graphs and XML. These frameworks encapsulate all the work of handling XML, meaning that application code only has to deal with plain Java objects. They tend to provide useful ancillary functions as well, such as document validation. Broadly, these frameworks take two different approaches: code generation and objecttoXML mapping. I39。ll explain both.The codegeneration approachBinding frameworks that employ code generation include XMLBeans, JAXB, Zeus, and JBind. Castor can also employ this technique. The starting point for any of these frameworks is an XML schema that describes the data types of your documents. Using tools provided by the framework, you then generate Java classes that represent these schemadefined types. Finally, you write your application using these generated classes to represent your model data and serialize them to XML through some convenient mechanism provided by the framework.The code generation approach is a good one if your application employs a large XML grammar. The scaling problem of writing custom XMLserialization methods across tens of classes vanishes. On the other hand, you no longer get to define your own JavaBeans. The frameworkgenerated Java classes typically follow the XML39。s structures very closely, which can result in them being rather unwieldy to code against. Also, the generated classes bee dumb data containers because you can39。t generally add behavior to them. Broadly speaking, you need to make promises in your application code to play nicely with the schemagenerated types. Another pitfall is that a change in the schema causes changes to the generated classes, which in turn has a knockon effect to any code you39。ve written around them.XML binding frameworks of this type are most useful in data unmarshaling (., consuming XML documents and converting them into Java objects). Unless you have a huge data model and would benefit from having classes generated for you, codegenerationbased frameworks are probably overkill for an Ajax application.The mapping approachFrameworks that employ mapping include Castor and Apache Commons Betwixt. Mapping is generally a more flexible and lightweight solution than code generation. First, you code your JavaBeans as you usually would, including any behavior and whatever convenience methods you like. Then, at run time, you call on the framework39。s introspectionbased marshaler, and it produces an XML document based on the types, names, and values of your objects39。 members. By defining mapping files for your classes, you can override the default binding strategy and advise the marshaler how you39。d like your classes to be represented in XML.This approach is a good promise between scalability and flexibility. You get to write your Java classes the way you like them, and the marshaler saves you from dealing with XML. However, although the mapping definition files are simple to write and scale reasonably well, the mapping rules can only change the standard binding behavior so much, and some degree of coupling between the structure of your objects and their XML representation will always remain. Ultimately, you may have to promise either your Java representations or your XML format for the mapping approach to work.Data binding summaryDennis Sosnoski has written in depth on the subject of XML data binding APIs of both the codegeneration and codemapping flavors. I39。d remend his excellent articles on Castor and on the codegeneration frameworks if you want to investigate this area further On the whole, the codegeneration approach trades off too much flexibility and conven