This post originated from an RSS feed registered with Java Buzz
by Russell Beattie.
Original Post: XAOism Continued
Feed Title: Russell Beattie Notebook
Feed URL: http://www.russellbeattie.com/notebook/rss.jsp?q=java,code,mobile
Feed Description: My online notebook with thoughts, comments, links and more.
I've modified my original XML Access Objects (XAO) interface that I proposed a few weeks ago to be a bit more practical. After starting to implement some back end web pages using the basic XAO Interface which only read and wrote XML Strings, I decided that I needed to stretch the original rules a bit because it was just impractical on the server side. What was happening was that I was basically serializing parameters to XML in my Struts Action, then immediately deserializing them in my XAO into a HashMap so that I could use them within SQL queries and I decided this was just an unnecessary waste of processing.
Basically, in the first rev of my current app, I usually just access a DB from my XAOs, so I need to usually pass a couple of parameters, the "action" which tells the XAO which query to return, and the parameters for that query. The most simple example of this is a weblog query which looks for just one post, identified by an ID number. Thus the action is called "getEntryById" and the id number could be something like "1003904". I was wrapping this into an XML string, then immediately unwrapping it in the XAO which was just ridiculous for two parameters. If you think about scaling this app at all, it's just unnecessary XML processing.
I went through *a lot* of permutations and bugged Erik every day for a few weeks looking for a solution. I wanted something that would be quick to process, yet fit within my XML theme I was developing. One answer is to just loosen up the idea a bit and - like a normal DAO - just use any sort of method. Thus instead of needing to pass an "action" parameter, I'd simply just call public String getEntryById(Map params) like any DAO normally does. This is a real solution, but there's so much to be gained by sticking to a Interface. Another option was to go back to my original idea of using URI's in the parameter String instead of full-on XML. I actually developed this and realized that processing the query string (both building and reading) was nearly as bad as the XML. Not horribly, as I was in control of the String processing instead of handing it off to an XML parser, but it was still pretty convoluted.
So after some more hemming and hawing I decided to just use a Map. But after some consideration, I decided that it shouldn't just be *any* Map, but a XAOMap! In otherwords, an XML-aware Map implementation. This, it seems, is not a new idea as I was just going over the M$ stuff and sure enough you can serialize out their Hashtable as XML quite easily, but I came up with the XAOMap solution on my own. This is pretty dumb, however, so to avoid future recreations of the wheel, I'm taking a good look at what they're doing. :-)
Anyways, Here's the new XAO interface and new XAOMap interface:
public interface XAO {
public String getXML() throws XAOException;
public String getXML(String xml) throws XAOException;
public String getXML(XAOMap xaoMap) throws XAOException;
public void setXML(String xml) throws XAOException;
public String getSchema() throws XAOException;
public String getParamSchema() throws XAOException;
}
---------
import java.util.Map;
public interface XAOMap extends XAO, Map {
public String get(String key);
}
To implement the XAOMap I extended the HashMap class and added the XAO methods which read the internal Map and produced XML. (This was a lot simpler than trying to implement all the Map methods on my own). I'm already discovering this is quite useful in a variety of situations, and worth breaking my original XAO rules about only reading and writing XML. Now instead of serializing and deserializing parameters just for a simple method call, I just fill up a XAOMap implementation and pass that instead. If I need to have XML at any instance - say I want use the XAO as an interface for some Internet-based resource, I can serialize the data as XML with a simple method call and send it on its way via a standard HTTP POST.
The one problem I still have is what to do with the "extra" XAO methods that aren't used in my XAO or XAOMap. For example, I don't need getXML(String xml) in my implementation of the XAOMap and some XAOs won't need to use a XAOMap in their params. I decided to just throw an XAOException in these cases which give the error "Unsupported method." But I'm not sure if this is a valid solution or *insanely ugly*. Any thoughts?
So once again to recap. The XAO is a way of using XML as a data transport mechanism within your Java application. You can create new XAOs which access data from a variety of sources (db, files, URIs, etc.) and always presents them as XML to be consumed by other parts of your application in the way that JavaBeans are normally used now, but in a richer, more descriptive and networked way. The neat thing about using XAOs is that it's simply an Interface that you can lay on top of current business objects to XMLize them, thus you don't have to switch wholesale from one methodology to another. If you have normal PoJos, Javabeans, Stateless Session Beans, etc. you can expand them using XAO and then integrate them with other XML tools and queries, etc. You have to buy into the idea that "XML is good" but if you do, then I think this way of working has a lot of advantages.
Again, once I get some more code written that uses all this stuff (there'll be more tweaks in the future, I'm sure), I'll publish some code.
Previous Topic
