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 Tue, 23 Aug 2005 20:02:50 GMT
On 8/21/05, robert burrell donkin <robertburrelldonkin@gmail.com> wrote:
> On 8/18/05, Dennis Sosnoski <dms@sosnoski.com> wrote:
> > I've been having some off-list email exchanges on the issues of better
> > tools for going between Java and XML. This is relevant to both
> > start-from-Java approaches to web services, and handling schema
> > versioning. Since these issues are important for Axis2 I'll get this
> > thread going here, assuming nobody objects to us using the Axis2 list
> > for this purpose. I'm copying the jibx-devs list on my own emails on
> > this topic just so that people monitoring that list are also aware of
> > the discussion.
> >
> > 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.
> >
> > 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.
> >
> > 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.).
> 
> +1
> 
> a tool makes sense and would be useful relatively quickly (even when
> not fully featured).
> 
> probably going to need to think about managing IDE integration. this
> is something that i know nothing about. do we start with one target
> and then try to add support?
> 
> > What do people think of this? Anyone want to jump right in and start
> > putting this together? ;-)
> 
> on the basis that it's easier to argue about bad code than no code,
> i'll put together a very basic protoype using betwixt (which will do
> most of the stuff required already) just using basic swing. i'm very
> interested in dan's ideas and have a list of additional features that
> IMO are needed to make it useful but a least it'd be a start.

i've been playing around with some code for a day or two
(http://people.apache.org/~rdonkin/tool.html). it's just hacked
together but hopefully it'll serve as an illustration and act as a
lightning rod for ideas. (it'll try to explain where i see it fitting
into the bigger picture later.) so please criticise the concepts not
the coding :)

java classes and primitives have a natural correspondence to types.
primitives naturally correspond to simple types whereas classes may
correspond to simple or complex types. being able to perform multiple
mappings of the same primitive or class is important (think about the
different semantic meanings that java.util.Date may have).

java developers naturally reuse classes. they need to be able to reuse
mappings either precisely or as the basis for tuning against a
particular schema. i see users being able to import mappings into the
tool (in a pluggable fashion), tuning them (by dynamic viewing schema
and example generation) and then saving the mappings into a library. i
see this import process being extensible so that import pluggings can
be created for existing ways of describing bindings.

the mappings in the library would then be available for use in other
tool sections for example, the mapping section (which is the named
i've just coined for dan's cool ideas but feel free to jump in with a
better one). it could also be used for a simple document tool (pure
start-from-java, with no target schema for initial prototyping).

i see this design element as having advantages for the project as
well. mappings for common objects would be something that would be
easy to contribute. in addition, the numerous standard mappings which
it would be very good to ship with could be developed using the tool.

comments welcomed and cool new ideas even more so :)

dan has posted some very interesting ideas and i'd like to come back
to them later (maybe when i've played about with some visualisation
code).

i also have some ideas about the tuning process (arising out of the
prototype) but i'd prefer to hear comments first before elaborating.

- robert

Mime
View raw message