Category Archives: webmethods

WebMethods Designer 8 – take 2

Posted by KarlP on 4 January, 2011 None comments

Well, it’s still pretty crap. Here’s some more things that are just wrong/stupid.

  • The navigation tree on the left helpfully scrolls to the current flow. Except that it actually scrolls so that the top of the folder containing the current flow is at the top of the tree view. So for a folder with (too) many flows, the current flow is actually off the bottom of the screen.
  • To see your currently locked elements, you need to scroll to the very top, right click the server and choose properties.
    Fine, except that you can’t double click on an entry to go to that flow, and the dialog is modal, so you have to keep opening and closing it to have a list of what’s locked. Or, take a damn screenshot.

Doesn’t matter whether I’m using the stock version, based on eclipse 3.4, or installed into a working eclipse 3.6.

common object models in webmethods and java webservices

Posted by KarlP on 7 October, 2010 2 comments

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.