A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
I'm working on a workflow framework similar in Java and have a requirement to save and load workflow definitions and instances to XML and back. My requirements are as follows:
a. XML should be as human readable as possible;
b. Workflows are extensible as other folks can create new activities, variable types and expressions. These extensions need to participate in the serialization process
c. The saving and loading needs to be able to handle moderate versioning as processes can be long running and it's quite possible an upgrade may occur while instances are workflow passivated to the database. Major changes to definitions and instances would likely have to be handled by some sort of upgrade process.
I'm currently handling this by defining an XMLSerializable interface that objects implement that enable them to serialize and deserialize themselves from a DOM tree. Essentially the serialize and deserialize methods take a DOM element and can can persist themselves to XML as they see fit. For versioning, objects would be expected to take logical defaults for new fields.
This works OK, but it doesn't scale particularly well from the point of view that everytime you create a new object you end up having to implement this interface. Also, it pollutes the domain model by having a lot of XML processing in the actual object itself.
I looked at XStream which supports serializing a Java object automatically, but it doesn't handle A and C of my requirements very well. No surprise because XStream needs to handle a lot of things that are difficult from an automated perspective but simple when you understand the object model (for example, circular references, references to external entities, etc).
One alternative I've thought about is changing to the visitor pattern and having a secondary class registered for each serializable class that actually performs the XML manipulation on behalf of the domain object. Another idea is to simplify the process in the class itself by passing in some sort of reader/writer wrapper that eliminates the need for direct XML usage.
I'm sure some folks here have dealt with a similar issue and I'd appreciate hearing ideas on alternative ways to solve this problem in a more elegant fashion.
I'm not an XML expert but I know we've done the similar things as you are trying with JAXB. My memories of it were that it was a pain in the ass.
a) JAXB looks how you want it to
b) You can do whole object data structures using it.
c) We handled versioning by having objects have their own field IIRC.
I have to say that JAXB did not seem like an elegant solution to me.
Good luck if you find that it fits your needs.
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz