axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@gmail.com>
Subject Re: [Axis2] Better Java-XML mapping
Date Sun, 21 Aug 2005 13:19:07 GMT
On 8/19/05, Dennis Sosnoski <dms@sosnoski.com> wrote:
> Dan Diephouse wrote:
> 
> > 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.
> >> ...
> >
> >
> > 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.
> 
> JiBX can actually handle both these cases directly (direct binding to
> business model objects without the use of DTOs, and multiple schemas to
> a single set of objects). The binding definitions effectively serve the
> same purpose as transfer code or XSLT transformations (within limits).
> Of course, this creates the need to maintain the binding definitions -
> hence my interest in a tool of the type we're discussing.

IMHO it's about choice. there are lots of options available when it
makes sense to have a separate set of generated objects. many fewer
with start-from-java and no really comprehensive solutions (as yet ;)

> >> ... 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).
> >> ...
> >
> >
> > To clarify the use cases:
> > 1. Schema exists, but no java code

IMHO it's very difficult to support all schema without generation. i'm
not sure it's worth competing with dedicate start-from-schema tools. i
would agree that binding towards a given schema would worth doing. due
to the fact that the same logical categorization can be represented by
different schema may make full support very difficult.

> > 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)".

+1

definitely a fourth generation feature :)

this is similar to the achitecture used by the second (refactored)
betwixt engine. i suspect that JIBX also uses something similar
(though probably uses different terms).  with beans, you reach a stage
where scripting becomes important. (betwixt doesn't do any of that but
the structure's there.) the problem is that for this to be useful
requires good tools.

i didn't see the connection before but this needs to be a core
feature. IMHO this power would need to be pluggable so that a useful
core toolset (probably bean and field centric if we start from what
JIBX and betwixt have now) could be created quickly.

> > 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.
> 
> I like that idea a lot!

+1

(on automated bean mappings)

betwixt maps beans adequately (except for fields which is where JIBX
is strong). it also has lots of automatic mapping strategies developed
over a number of years in response to user requirements. it's clear to
me that one universal automatic mapping strategy isn't expressive
enough. it's important that the tool not only supports pluggable
strategies but ships with a good palette. users need to be able to
import their own strategies. i'd like to be able to bind a bean by
grabbing some strategies from a palette, applying them to generate a
basic mapping. this can then be tuned.

it's also important to ship enough standard mappings for common objects. 

(on events)

the basic idea sounds good but i really think that users are going to
need to be able to plug in more specific builders on top. we need to
be able to make it easy for a java developer faced with a POJO to be
able to ignore the details of the events. IMHO fast prototyping by
java developers who are not strong in cool stuff like xml, groovy and
so on is crucial.

but i agree that it seems better to build this in a pluggable fashion
on top of something that exposes more powerful and more basic
features.

> > ...
> >
> >>
> >> 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.
> 
> That's true, but JAXB could still use a tool like this within its single
> schema limit, while frameworks that support multiple mappings could go
> further.

+1

IMHO this is a JAXB specific limitation

annotations can be easily used within a multiple mapping framework.
the idea is that annotations become just one way of describing a
mapping. the same objects could be mapped by annotations in one
context and use different bindings specified by files in another. you
could also use multiple forms of annotation.

being able to hook into a JAXB implementation would allow
non-compliant mappings (for example, the JiBX ones) to interoperate.

> >> 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...

+1

i'm pretty enthusiastic to code but there have already been many cool
ideas emerged.

if we are going to play about with some bits and pieces codewise, it
might make sense to indicate to everyone else the bits in question.
i'll probably take a look at seeing if i can pull some useful stuff
from betwixt for the automated bean binding. any opinions on ui
technologies?

i am wondering about meta-data. it seems to me that in order to tied
this all together, the meta data describing the bindings is going to
be important. getting this object model right will probably take some
doing...

> > 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.
> 
> That's an interesting possibility, especially for making a
> schema-centric framework like XMLBeans more Java-friendly.

interesting :)

- robert

Mime
View raw message