Dozer 2.0 has been released, to try to help solve the SOA mapping problem between XSD schema types and domain objects. In a "WSDL first" world, where your data types are built from XSD schema objects, there is a mismatch between non-built-in data types and your domain objects. This is just one of the mapping problems Dozer can help with.

Dozer is a powerful yet simple Java Bean to Java Bean mapper that recursively copies data from one object to another. Typically, these Java Beans will be of different complex types. The mapper can be used any time you need to take one type of Java Bean and map it to another type of Java Bean. Most field mapping can be done implicitly by dozer with attribute names that are the same. All other explicit field mapping or custom mapping can be pre-described in XML format. Mapping is bi-directional so only one relationship between classes needs defining. Dozer will make sure that your data transfer objects from the database do not bleed into the presentation or into external consumers. It can also help map your domain objects to external API calls and vice-versa.

Some of the Dozer 2.0 features include:

• Context based mapping
• Collection and Array mapping handling Lists, Sets, Arrays and allowing for class type hints
• Support for custom converters
• Custom bean factories for beans that do not follow the JavaBean specification
• Inheritance mapping including abstract classes and interfaces
• Field exclusion and custom getter() setter() functionality
• Copy-by-reference and 'self' mapping
Null and empty quote source value exclusionBi-directional or one-way mapping
• String to date mapping
• Data type conversion like String to Integer Wrapper or String to primitive
• Class level mapping recursion and deep property mapping
• <buzzword>Spring integration</buzzword>
• Map backed property support
• 8X speed improvement over dozer 1.x

A mapping framework is useful in a layered architecture where you are creating layers of abstraction by encapsulating changes to particular data objects vs. propagating these objects to other layers (i.e. external service data objects, data transfer objects, or internal service data objects).

Seems like this could be a replacement for BeanUtils.copyProperties() in a Struts app. Has anyone used it for such a thing? Seems like the static mapper would do what is needed, but it's not clear from the "getting started" section what happens with attributes in source not in dest or vice versa. Also, it appears that you have to define an XML file for every single mapping? Anyway, looks interesting but I wonder what tasks people are applying it to.

We saw some limitations in BeanUtils.copyProperties() and tried to improve on these. In the dozer framework attributes of the same name do not need to be included in the XML file, regardless of their type. We will implicitly map complex types as well as built-in types. When attribute names are different, they need to be explicitly defined in an XML file.

Thanks for looking.

Franz

Anyway, looks interesting but I wonder what tasks people are applying it to.

Let's imagine... having ValueObject defined from xlm schema, this tool could do the mapping between domain and value objects. Similarily, jaxb would enable value object to/from xml from the same schema so that objects could be gotten from some ajax requests. Overall, xsd would be the authoritative source. Looks attractive. Does it sound reasonnable ?

Anyway, looks interesting but I wonder what tasks people are applying it to.

Let's imagine... having ValueObject defined from xlm schema, this tool could do the mapping between domain and value objects. Similarily, jaxb would enable value object to/from xml from the same schema so that objects could be gotten from some ajax requests. Overall, xsd would be the authoritative source. Looks attractive. Does it sound reasonnable ?

I think spring does it too thru IOC - sml mapped to a object instance.

I used Dozer to transform my domain DTO's into similar beans that were more appropriate for exposing to consumers of web services. My experience was that Dozer was not as intelligent as I'd have hoped on some nested mappings, but I think that may have been fixed in the last few months.

The problem I encountered was if class A was mapped to A-prime, and A has an array of B, and B is mapped to B-prime, a conversion of A to A-prime did not automatically convert the B instances over to B-prime. The solution was easy enough, though -- I explicitly defined the conversion in my dozer mapping file by providing a hint. Such a step should not be necessary, but it wasn't the end of the world either.

We started using Dozer because BeanUtils just didn't cut it for us. What if you want to change the name of your property? In a DTO, you might have a field called something like "myAbbFldNm" -- hardly an easily understandable name. Using BeanUtils, the target bean must have an identically named field. Dozer allowed us to map our fields to beans that used different naming conventions -- in the above case, "myAbbreviatedFieldName", for example.

Dozer also allows you to identify mapping methods. This comes in handy when you try to build interoperable web services. A gotcha about going from the Java world to the .NET world is that in the former, a Date object can be null. In .NET, dates are primitives, and therefore not null. We decided to use a wrapper class that could be null, which in turn holds a Date. A couple lines of code, apply appropriate references in the mapping xml file, and you're done.

I only defined one xml file -- all mappings were contained in a single file.

As for attributes in the source but not in the dest, they aren't copied over.

SOA as a use-case for object-to-object conversion, as mentioned in this post, is exactly what i'm struggling with and maybe you have a different take on this problem:

The task is to convert a set of objects derived by JAXB from WSDLs/XML-schemas to a set of EJB 3 entities which are mapped via Hibernate to a relational database. The EJB 3 entity layer is fronted by a DAO layer of local stateless EJB 3 session beans. Translation is currently done by hand-written code (and not Dozer).

The problem is, that the XML-schema and persistent object model differ quite a lot, so there is quite a lot of business logic required to do these conversions. As an example, say the XML-layer uses a personName as an attribute, then, when transforming to a persistent entity, i know from the context of the conversion that it is actually a findCustomersByApproximateName() that must called on the DAO layer to retrieve the mapped Person object.

In general, when doing this kind of conversions, it is very common to need to convert an enitity/attribute-value in the XML-layer to/from an object-reference in the persistent object model. To do this, you usually need to call some "finders", i.e. access the DAO layer.

There are several issues here:
  - organising the conversion code and finding the correct converter: Dozer can likely help with that.
  - accessing the business logic from the converter: here i would need a mechanism to inject a service object or DAO reference (ideally via EJB 3 dependency injection) into a converter. I can't see how this could be done with Dozer.
  - the general mindboggling redundancy in this approach, where everything is translated back-and-forth from persistent entities to a semi-independent XML-layer. But that's another discussion, i think ;-)

What are your thoughts?!

  cheers,
  gerald

http://www.gerald-loeffler.net

we're doing something similar. Actually we started with the domain model, using hibernate, and made sure to keep everything as flat as possible. The schema in the web service we are exporting is being mapped via castor, so we are only doing one level of conversion. Castor itself was a challenge up until their latest release, but so far everything is working smoothly, except for the complexities of doing anything non-trivial using doc-lit with axis ;-).

  - the general mindboggling redundancy in this approach, where everything is translated back-and-forth from persistent entities to a semi-independent XML-layer. But that's another discussion, i think ;-)

The fact that a tool has been developed to solve this problem means that it is considered an issue, doesn't it?

I have currently faced the same problem of object-to-object conversion in the last two projects I worked in. My question is: why must we translate/copy everything instead of just using the domain object and binding the XML data to it, like we do for the DB schema with Hibernate/JDO?

You’re absolutely correct; this tool was created to solve a real issue. The issue being how to move data from a code generated object model, to a real domain model.

This problem existed in the object-to-relational space until tools like TopLink allowed you to map your own domain objects to a relational database.

The old object-to-relational problems are reappearing in the object-to-XML space, and now the same type of solution is available. New in TopLink 10.1.3 is support for object-to-XML mapping (I lead this project). This allows you to map your domain objects to an existing XML schema. This avoids the need for a bean-to-bean conversion tool.

For an example demonstrating TopLink’s object-to-XML support:
http://www.oracle.com/technology/products/ias/toplink/technical/tips/ox/index.htm

-Blaise

One of our by-products is the ability to map schema generated objects to domain objects. If your objects are not generated from a schema then an object-to-XML tool would be tough to use. We saw some serious shortcomings of Beanutils.copyProperties() and tried to create a feature rich, robust bean-to-bean mapping tool. For people that need context based mapping, custom converters, map-backed property mapping, inheritance mapping, copy-by-reference, and a whole lot of other features I don't see a object-to-XML tool filling this void.

Is mapping back-and-forth a good thing? If you want to protect your interface layer (e.g. WSDL) and vice-versa from domain changes, versioning, etc...it almost seems like a necessary evil.

The main reason behind dozer is that we had a SOA application with hundreds of value objects (VOs). These VOs were used as objects in the SOAP messages as well as throughout the domain. When a domain object changed the contract was broken. After seperating these two things we literally had thousands of lines of mapping code. Implicit mapping (attribute names the same) is where we really saw benefits. At that point we did not even have to create a mapping XML file.

So, back to the initial question :)

Issue 1: yes, we can help with that.
Issue 2: Custom Converters can be injected into Dozer. These converters can themselves be injected with whatever you like since you just implement an Interface and can use them as say a Spring wired bean.
Issue 3: I wish I had a better answer. We (development community) tend to build tools or frameworks that help solve these layering and abstraction problems.

Whew.

Franz

Hi Franz,

I agree with you that for a straight bean-to-bean conversion an object-to-XML conversion tool is the wrong choice.

Dozer 2.0 has been released, to try to help solve the SOA mapping problem between XSD schema types and domain objects.

I was addressing the first sentence of your original post (quoted above). In this case an object-to-XML mapping tool can be used to convert XML directly to a users own domain objects. In the scenario you propose a 3rd party tool must be used to convert XML to generated objects then a bean-to-bean converter is used to convert the generated objects to domain objects.

We agree on the main point, generated objects are difficult to deal with and it's better if the user has access to real domain objects.

See the following example on how an object-to-XML binding tool can be used to convert SOAP messages directly to domain objects:
http://www.oracle.com/technology/products/ias/toplink/technical/tips/jaxRpc11/index.htm

-Blaise

Hi Franz, TSS members:
I am esentially writing a application with layered architecture where we have complex xsd (HIPAA and health care domain. Dont ask.....)

We are using JAXB to get our generated composite VOs, given the nature of our XSDs. We have been writing the data translators by hand for past few weeks and let me tell you that they are painful.

Has anyone here used dozer sucessfully with the JAXB generated VOs? If so, I would like to know what your experiance was (esentially what did NOT work).

Thanks
Anuj

In this case an object-to-XML mapping tool can be used to convert XML directly to a users own domain objects. In the scenario you propose a 3rd party tool must be used to convert XML to generated objects then a bean-to-bean converter is used to convert the generated objects to domain objects.

In my experience (i.e. in an SOA) the domain object-to-XML mapping is much more complex than the object-to-table mapping performed by OR-mapping tools. The reason is that in reality persistent domain objects are rather similar to the tables they map to, while domain objects usually differ quite a lot in granularity and semantics from the XML they are mapped to.

So while a static mapping description works well for OR-mapping tools, i'm fairly sure that it wouldn't take me nearly very far enough in describing the object-to-XML mappings in my SOA.

This is why dozer, with it's provision for custom converters, is interesting.

I'd be interested to learn if in your experience static mapping rules suffice for object-to-XML mapping in an SOA setting.

As an aside, that "3rd party tool" that "must be used to convert XML to generated objects" is usually called JAXB and is an inherent component when implementing your web services with JAX-WS 2.0 ;-)

  cheers,
  gerald

Hi Gerald,

I'm familiar with JAXB, I led the development effort to add a JAXB 1.0 implementation to TopLink and I represent Oracle on the JAXB 2.0 (JSR 222) expert group.

JAXB like most XML binding solutions produces a class model that mirrors the XML schema, which leads to object models that mirror XML documents. The JAXB object model could be considered a "typed DOM".

It has been identified (in this thread) that Dozer (a bean-to-bean mapping tool) through the use of mappings and custom converters can map these typed DOMs (which mirror an XML document) to domain objects. What I'm stating is that a TopLink (a object-to-XML mapping tool) through the use of mappings and custom converters can map the untyped DOM (or SAX events) to domain objects.

In this case an object-to-XML mapping tool can be used to convert XML directly to a users own domain objects. In the scenario you propose a 3rd party tool must be used to convert XML to generated objects then a bean-to-bean converter is used to convert the generated objects to domain objects.

The point I was making (above) is that when converting XML to domain objects using a bean-to-bean mapping tool, two conversions are required (i.e. XML to JAXB objects, then JAXB objects to domain objects). There is a performance hit in doing two conversions, even if one of the conversions is done using an inherent component ;).

For an example using TopLink JAXB:
http://www.oracle.com/technology/products/ias/toplink/technical/tips/jaxb/index.htm

-Blaise

How does Dozer compare to OTOM?

https://otom.dev.java.net

I put down my 2 cents on bean-to-bean transformations in a blog post:

http://www.kleineikenscheidt.de/stefan/archives/2006/02/bean-to-bean-transformations.html

Cheers,
-Stefan