I have a library that defines messages. In my particular instance, it's autogenerated code from an XSD using JAXB (Java). The messages can be very complex, with some members as objects and those objects containing other objects. The objects are both classes and enumerations. The library is a single JAR file with no dependencies, billed as a reusable component for Java applications. The idea is that any Java application that needs to send or receive these messages would use this library to do so. At present, there are 10 messages that are defined, but there are a large number of data types (classes and enumerations) that are also defined in the library that are contained within the messages.
The immediate need is for a graphical application that lets the user construct the messages in the specified format and then publish them appropriately over a network connection. This means that the user would be able to create the 10 messages and populate the various fields that go into them. The result is an XML string that conforms to the schema that can be published to a listening application. The listening application is also generating messages that are also defined in the XSD and the library in accordance with the schema and those must be received.
It is desirable to also be able to create a command-line version of this application that can be scripted. This command-line version is not well-defined, but it could be interactive (with prompts) or simply command-line argument driven to publish the messages.
What would the best approach to building my application around this library?
Two approaches come to mind:
The first approach is a a wrapper around the library that is part of the application build. This wrapper would be almost a duplication of the JAXB library, but it wouldn't invoke the generated data objects until requested. It would be a builder that would also provide validation and perhaps a simplified interface for some of the components of the messages. This could be useful, since the JAXB library doesn't have a concept of validation until the elements are marshalled. Although you can marshall to a default handler as opposed to your output format like a file or stream, but that seems not very useful since the messages you get from validation errors aren't exactly user-friendly. In this approach, the GUI, the text user interface, and the command-line interface would all interact with this application data model.
The second approach would be to organize my user interfaces into different packages. The GUI packages would provide user interface elements that correspond to the fields of each message. The validation rules from the XSD would be applied as validation rules to each field, using things like InputVerifier
s, combo boxes, check boxes, and other things that prevent invalid data before it's even passed off to the data model. The text user interface would essentially provide the same thing, but by reading from and writing to the standard input, output, and error streams. I suspect in these implementations, the input classes would correspond to the data model classes 1-to-1 - each input class would be responsible for gathering and validating the user inputs needed to construct a single data element (one class in the data model provided by the JAXB library). I suspect that the textual UI and GUI can share base classes or interfaces that each of the UI classes can inherit from to allow them to be passed into the same controller to read from and produce the appropriate object from the data model. A command-line interface would likely use a command-line argument parser to gather the input, ensure everything is there, validate all of the fields, and then carry out the transmissions or receptions. It would be implemented very differently than the interactive user interfaces.
I'm personally leaning toward the second approach, but I suspect that there may be another, better strategy out there.