Design Patterns in XML Applications: Part II
by Fabio Arciniegas A. | Pages: 1, 2, 3, 4, 5, 6

Table of Contents

•Introduction •XMLable Pattern •Patterns in DTD Structures •Patterns in Element Definitions •A Little Advice •References

XML application design patterns (abbreviated here as "XADP") are named, reusable solutions for common problems at the application level. They are often refinements of traditional patterns.

Because of their nature, XADPs can be easily and neatly expressed in the same way traditional patterns are usually presented. That is, in sections for the name, synopsis, context, solution, consequences, and related patterns.

The following pattern is a typical XADP, called the "XMLable pattern." It has been successfully used in a number of applications, and tackles one common problem in XML-aware applications: the construction of internal representations of XML data as meaningful objects.

XMLable pattern

Also known as "XML-reader/writer"

Originator: Fabio Arciniegas A.

Synopsis

The XMLable pattern defines a solution to managing information that is persisted as XML data, but must also be managed as meaningful objects (i.e., not as a general data structure such as the DOM) inside an application.

Context

Suppose you are writing an e-mail program that uses XML documents for the persistence of the messages. This is pretty useful since you can do things like apply various stylesheets to these documents and get all sorts of nice presentations for them. But you also need to upload and manage that information into your program: you need objects that represent your messages.

Keeping the DOM representation of every object can be very memory-intensive, especially when you are managing a large number of messages. More importantly, DOM objects contain no semantics whatsoever about being a message. There is no such thing as an interface enabling other objects to interact with it as an e-mail message (no setSender(String), no getDate(), just plain DOM manipulation). Choosing to maintain the DOM representation of hundreds of messages is in most cases a bad design decision; using it would probably lead to a poorly structured, hard to maintain program.

The XMLable pattern addresses the problem of how to create e-mail objects by using the data contained in the XML document without having to keep the DOM representation in memory.

The solution that the pattern suggests is to provide the emailMessage class with a partner class, emailXMLPersistenceManager, whose sole responsibility is to make the object persist in an XML representation. Whether recovering the state of the object or serializing it in XML, it is the PersistenceManager and not the object itself that handles this activity.

Forces

The considerations that lead to the general solution proposed by the XMLable pattern are:

• Multiple objects, whose data is gathered from XML documents, need to be manipulated internally.
• Memory restrictions make DOM prohibitive.
• Design and program quality impose the need to represent the data as something more meaningful to the application domain than the DOM tree.

Solution

This figure shows a class diagram depicting the classes and interfaces participating in the XMLable pattern. The descriptions of the roles played by these classes in the pattern are below:

Client

A container responsible for the creation of the XMLableConcreteClass instances. In the e-mail example, this is the EmailProgram class.

XMLableAbstractClass

Gathers (provides the base class for) different classes that can be made persistent through the use of the correspondent ConcreteXMLPersistenceMgr.

XMLableConcreteClass

The actual class whose instances will be registered with the ConcreteXMLPersistenceMgr and finally saved as XML. In the e-mail example, this is the EmailMessage class.

XMLPersistenceMgr

A simple interface declaring the methods that provide XML persistence to an object. This also declares a method to register the concrete XMLPersistenceMgr object with the XMLable object.

ConcreteXMLPersistenceMgr

This is the core of the pattern. The class implements the XMLPersistenceMgr interface. It is also responsible for construcing the XMLable object from XML documents. To do that, the class implements the DocumentHandler methods (defined by SAX) in order to be able to update the registered class from the XML source.

DocumentHandler (defined in SAX)

The ConcreteXMLPersistenceMgr needs to be informed of basic parsing events. In order to do so, it implements this interface and registers with the SAX parser. The parser uses the instance to report basic document-related events such as the start and end of elements.

Consequences

• All the complexity involved in managing the persistence of the object is shifted to the PersistenceMgr.
• There is a tight coupling between the XMLable class and the PersistanceMgr.
• The size of the XMLable objects is smaller. This is very useful in applications handling many instances of the XMLable class.
• Responsibility for instantiation and update of the XMLable object is well separated, allowing for the creation and manipulation of the object even outside of the XML persistence process.

Related Patterns

• High Cohesion: This pattern encourages putting specialized methods in special-purpose classes. The use of the PersistenceMgr is a good example of a High Cohesion pattern.
• Singleton: The Singleton pattern ensures that only one instance of a class is created. This can be the case for the PersistenceMgr class if, among other reasons, concurrency considerations must be easily minimized.
• Balking: If an object's method is called when the object is not in an appropriate state to execute it, the method returns without doing anything. This pattern is useful for systems implementing PersistenceMgr as a Singleton, but where the client may start concurrent requests to save XMLable objects.

In this section we saw a common example of an XML pattern for XML processing applications. In the next section, we will study XML patterns for DTD structuring.

Pages: 1, 2, 3, 4, 5, 6

Next Page