Patterns : Java class conversion from axis objects.

I use a axis to auto-generate webservice artifacts which I then convert into objects used within our application. Is there a sensible pattern for doing this ? We have written transform methods to output our objects from the axis created objects, at other times we have written an intermediate set of transformer classes that transform the axis objects to our application objects? Is there a common way of approaching this?

From stackoverflow

• We have run into similar issues in the past. Recently, for a complex web service that we had Axis generate artifacts for, we wound up with 157 Java classes with names like "MaintainOffersRequestTypeReqReqDataMaintEnhancementCancellationReason".

  We wound up writing classes that transform these Axis-generated objects into business objects, similar to your last idea. I don't know if it's the best way, but it's certainly a workable solution.

• If I understand correctly, you want to use Axis WSDL2Java feature to generate code from a WSDL and then map that to your existing application object model. In that case, you might want to consider to use Axis with JiBX binding.

• If you're using Axis 1, your business classes have the same qualified name as the Axis data class, and some other conditions apply, you can just use your business classes in place of the Axis ones with no setup needed. We've done that many times.

  For Axis 2, we've had trouble with data bindings other than ADB (the default), so we use Apache Commons Beanutils extensively to copy data back and forth between Axis classes and our business classes.

• If the goal is to translate the "axis generated" to your business objects you can try a tool like dozer (http://dozer.sourceforge.net/) that is a "mapper" to copy from an object implementation to another implementation. It don't know how to use it (I think you have to explain the translation in xml files) and then it should work (I didn't used myself but some colleagues used it for a similar purpose and it seemed to work)

• Hi!

  I guess there is a common sense way of doing that. Abstract a bit your mind and imagine layers.

  1. You get a library with the basic IO and perhaps basic session functionality and/or credentials.
  2. Create a convert layer. Here you will place all the code needed to build your application dependent objects. Finish this layer with a nice interface for your application.

  The convertion layer can be done in multiple ways.

  • If the conversion is simple, you can merge the first and second layer almost in one. Extend the POJOS to provide transformation functionality. This will give you, at least two pieces of code, the automatically generated and the extensions + functionality

  • If we're talking about huge XMLs that need to be converted to multiple small application objects. Ok, leave the first layer as it is and in the second use:

    • Command pattern: to encapsulate the transformations.
    • If the transformation also gets messy: Chain of responsibility will help you to generate a tree of transformations.

  I hope this helps