SOA Best Practice: Start with the schemas

We've been doing some deep-dive evaluations on SOA tool suites at work, so I've had some recent exposure to a variety of toolsets. We've been investigating both proprietary and open source suites and components, so I've been able to work with a variety of SOA IDEs.

One thing I've noticed: In many cases, your life is much easier if you start with your schemas that represent the messages being shuffled from component to component.

A short while back, this would've caused me a little distress. I've had bad feelings about XML, based on memories of pain filled hours spent hand-editing XML files. Namespaces, the order things have to appear in XML files (Mule 1.4 config, anyone?), and others tripped me up time and again. I imagine this is common, else bottom-up web service development wouldn't be so popular.

Well, I'm pleased to announce that XML tooling has matured to the point where I found myself not dreading working in a top-down (XML schema first) manner. I've recently worked with both proprietary and open source tools that effectively hid the underlying complexity of the XML from me.

Most of the tools have nifty 'Design View' panels that let you visualize (drag and drop) the XML document you want to write. They'll have property tabs that allow you to add the syntactic elements, and a way to change views to see the underlying XML document if you want to. After a short while, I started really liking this way of working with XML.

So back to the SOA storyline-- because of these nifty visual editors, I found it totally natural to work in a top-down (contract first) manner. The SOA toolkits liked this much better, as they are able to provide meaningful dialogues that let me choose which data bits should be marshalled, transformed, whatever. I got to see the other side of the coin, too. Most of the tools let you design in a schema-less way (dragging components onto a BPEL canvas without specifying the schema, for example), but these efforts turned out to be much more difficult than starting with the schemas. (Or so it seems to me.)

So I'd have to call this one a triumph for technology. What used to be hard is now easier, and it leads to one of my personal best practices for SOA: Start with the schemas.