common object models in webmethods and java webservices

What all the ranting and soap tedium of the previous post was leading to, was that we want to have some common object models shared across multiple java/.Net webservices, as well as webmethods business processes.

So, we made a few nice schemas, all in one namespace, and made a few test webservices and clients, and made sure that the objects could be happily passed from one to the other without needing to do any field by field level copying.

To repeat, the object model of customers and products, is multiple schema files, all in one namespace. This makes it easier to work on one part at a time, and means less people have to get their heads around 20 different namespaces.

Each service then has it’s own separate namespace, to allow later deployment of different versions side by side, but uses the same common object model.

Because this leads to having wsdl documents that reference multiple schemas, that may reference further schemas, you need to be very fucking sure that your webservices library is doing the right thing&tm; so that everyone actually gets the types they were expecting.

JAX-WS Commons doesn’t do a very good job of this. You can _make_ it do the right thing, but it takes a lot of work. And when you want to generate code from the wsdls, and include niceties like toString and equals and hashcode and the other tasty xjc plugins, you get a world of hurt with overlapping maven plugins and snapshot dependencies. Again, you can make it work, but it’s more difficult than it should be.

CXF seems to just work so far.

And that means that webmethods can actually import wsdls from CXF, and we can be confident that those are the same ones that we wrote, and that the objects will be portable.

WebMethods gives us a nice big warningwebmethods warning about duplicate types but it works. As best I can tell, as long as your “duplicate” types really are the same, you can safely ignore this warning.

  1. Jonathan Heywood

    Hi Karl,
    This limitation has been removed in Integration Server 8.2. Each WSD is created with the doc types each in its own schema domain, so you will no longer get warnings about duplicate types when importing WSDLs and you won’t have problems, even with multiple versions coexisting.
    Jonathan Heywood
    Software AG Product Management

  2. But I will still be able to pass an object received from one service into another one right? This “own schema domain” won’t make webmethods think they’re now somehow “different” will it?

Leave a Comment

NOTE - You can use these HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>