Dennis Sosnoski wrote:
While we have a number of tools for generating Java object models to
(more or less) match a schema, most of these tools either cannot work
with pre-existing Java classes or can only work with existing classes
using their own built-in correspondences. This limitation makes it
very difficult for users to take a start-from-Java approach to
developing web services, since the users then have little or no
control over the schemas used by the web service (as seen with the
JAX-RPC 1.0-style doc/lit mapping). It also makes it very difficult
for users to work with evolving schemas, since their data model will
need to be regenerated every time the schema changes. Because of this,
users often end up writing a translation layer into their applications
to take the data from the schema-centric model and convert it into
structures actually used by their main application code.
Agreed. I would add that I see that this is a problem with nearly all
approaches. Even when parsing the XML by hand, you need to have seperate
code for each version unless you're doing transformations. DTOs are
generally the same way.
I don't view the DTO layer as necessarily a bad thing. If you're schema
and internal API are a lot different (which they often are), it can make
translation a lot easier. And it'd still be nice to map multiple schemas
to one set of DTOs.
There are some libraries which provide more flexible conversions
between Java and XML, including Betwixt as well as my own JiBX
framework. JAXB 2.0 is also taking steps in this direction. The
subject of the email exchanges has been the desirability of better GUI
tools for working with frameworks which support such flexible
conversions.
Betwixt seems to offer very good support for starting from basics and
refining the mapping as you go. It basically offers defaults for
everything, then lets you override the defaults. JiBX takes almost the
opposite approach, requiring the user to specify everything (though
there is a tool which will generate a default binding automatically,
with a variety of overrides). I can certainly see the benefits to
providing a tool that allows an interactive approach to building a
JiBX binding, basically starting with Betwixt-like defaults and
allowing overrides at every step of the way down to a detailed JiBX
binding. The way I envision it this should show sample XML output (or
the current schema, for those developers able to understand schemas)
at every step of the way - when you change the binding, you
immediately get the change reflected in the schema/sample XML. Ideally
you should even be able to go the other way - modify the schema, and
have the binding automatically reflect the change (or replace the
schema with a new version, and have the binding adjust as best it can
and then flag the mismatches). I've been adding hooks to JiBX for some
time with the intent of moving it in this direction.
To clarify the use cases:
1. Schema exists, but no java code
2. Java code exists, but no schema
3. Both schema and java exist.
How do we map between them, even when there is very little correlation
betwen java and schema. Each one is pretty important I think.
I see something a bit different then Dennis. (now where is my virtual
white board....) On the left pane I would see a structural
representation of the schema portions. In the middle is a place to apply
"actions" to a chunk of schema. On the right I would see a list of
actions. Actions would be "create object," "set property," or even "run
this piece of java code (via janino, groovy or the like)".
Say I have a schema like so:
<xsd:complexType name="book">
<xsd:sequence>
<xsd:element name="author" type="xsd:string"/>
<xsd:element name="title" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
I'd see this on the left (with the option to view the schema source)
+ book
|- author
|- title
When I selected book I would see the middle pane pop up with different
events like "on start of tag", "on end of tag", or on body. I'd be able
to drag in different actions from the right to certain events and
customize them. So on book I'd drag in "create object" and specify the
"Book" object. On the author element I'd want to do a set property. It
would also be intelligent enough create a mapping for a POJO
automatically if it can.
The left pane could be a schema editor as well of sorts. In addition to
or alternatively, the left pane could show a sample of the XML like
Dennis mentioned. And if you're missing the java code there could be a
button which generates a standard mapping.
You could do a ton of cool things if you make this IDE specific. For
instance if you could tie into the refactoring capabilities of Eclipse
or IDEA and have it update schema/java mapping automatically.
Much of the off-list discussion has revolved around the possibility of
building a generic tool of this type, one able to work with different
frameworks. On thinking it over, it seems to me that at least the
general framework of the tool should be reusable - say the IDE
integration and XML/schema display and manipulation. That would leave
the need to write plugins for each binding framework to handle XML
instance and schema generation from a binding and set of classes, and
to handle editing the actual binding definition (in whatever form that
takes - an XML file for Betwixt and JiBX, annotations for JAXB, etc.).
The version I described above is probably pretty binding toolkit
specific :-), but I'm open to anything really.
I'm confused aobut how JAXB can be used to handle multiple versions. You
can't really annotate a java class for multiple versions afterall.
What do people think of this? Anyone want to jump right in and start
putting this together? ;-)
I definitely would like to spend some time working on this next week.
Although I want to hear more ideas as there are many bright people
hanging around...
One other possible solution I just thought of is Dozer (maybe this
should go in a seperate thread). Dozer (http://dozer.sf.net) could be
used to map multiple sets of DTOs which are generated from a schema to a
single set of objects. This seems like a lot of work though.
- Dan
--
Dan Diephouse
Envoi Solutions LLC
http://netzooid.com
