Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services [Paperback]

My father runs a placer mine, far North in a remote part of the Yukon wilderness. Foralmost half a century, he's made his living plowing through mountains with his bulldozers,looking for gold. Due to the climate, he gets only a limited amount of time duringwhich he can actually mine. His priority, therefore, is to keep his business fullyoperational throughout this period. Any disruption results in lost revenue. Despite hisbest efforts, though, he is constantly faced with obstacles.He's had to contend with volatile, sometimes even violent environmental conditions.He's had to confront bears that roamed into his camp, looking for food. He's evenchased thieves off his land in the middle of the night. Once, the hydraulic pump on hisfront-end loader collapsed, crushing his hand. Instead of "wasting" two days to get tothe nearest hospital, he simply wrapped a diesel soaked rag around his broken fingersand kept on going.

The worst kind of problem he's ever had to face, though, is mechanical failure. If a keypiece of equipment breaks, if an engine slows or stops, or if any other part of his infrastructureseizes, his business comes to a (literally) grinding halt. It can take weeks to getnew equipment or spare parts -- a delay that can be devastating to his bottom line.When faced with these challenges in the past, he's had only himself to rely on. I askedhim once how he deals with these situations. He told me that there are very few problemsin life that can't be solved with a blowtorch and a welding rod.

I think about that "life philosophy" sometimes, when staring at the cursor, blinkinghypnotically amidst some problem displayed on my computer screen. I've always beeninvolved with new technology. It has the mystery of the unknown and the attraction ofpotential. It's also put me in more "impossible" situations than I care to remember.Although I have respect for the expertise required to produce product documentationand tutorials, I generally classify this information as "option A." It is surprising howoften option A does not work in integrated environments. But, that's what option B isfor. Option B is when I roll up my sleeves and light my own blowtorch.

This attitude is important when working on integration projects. Some integrationtasks are easy. Making two compatible pieces of software talk to each other can bestraightforward, involving a predictable development and deployment effort. Others,though, can be a nightmare. Sometimes two pieces of software aren't just "not compatible,"they seem violently opposed to each other's very existence.

The goal of this guide is to help you define your own options for whatever integrationchallenges you might be facing. I am fortunate to be writing a book about integrationstrategy at a time when the IT community has at its disposal a platform that fostersintegration and interoperability like never before.

I hope that you will find this guide not only useful, but that it will lead you to viewXML, Web services, and service-oriented principles as problem-solving tools. So that nomatter what obstacles cross your path, you will be able to use your own blowtorch tocarve out that perfect solution.