|
Preface
|
Service-Oriented Architecture:
A Field Guide to Integrating XML and Web Services
|
My father runs a placer mine, far North in a remote part of the Yukon wilderness. For almost 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 during which he can actually mine. His priority, therefore, is to keep his business fully operational throughout this period. Any disruption results in lost revenue. Despite his best 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 even chased thieves off his land in the middle of the night. Once, the hydraulic pump on his front-end loader collapsed, crushing his hand. Instead of “wasting” two days to get to the nearest hospital, he simply wrapped a diesel soaked rag around his broken fingers and kept on going.
|
|
The worst kind of problem he’s ever had to face, though, is mechanical failure. If a key piece of equipment breaks, if an engine slows or stops, or if any other part of his infrastructure seizes, his business comes to a (literally) grinding halt. It can take weeks to get new 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 asked him once how he deals with these situations. He told me that there are very few problems in 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, blinking hypnotically amidst some problem displayed on my computer screen. I've always been involved with new technology. It has the mystery of the unknown and the attraction of potential. 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 documentation and tutorials, I generally classify this information as “option A.” It is surprising how often option A does not work in integrated environments. But, that’s what option B is for. Option B is when I roll up my sleeves and light my own blowtorch.
|
This attitude is important when working on integration projects. Some integration tasks are easy. Making two compatible pieces of software talk to each other can be straightforward, 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 integration challenges you might be facing. I am fortunate to be writing a book about integration strategy at a time when the IT community has at its disposal a platform that fosters integration and interoperability like never before.
|
|
I hope that you will find this guide not only useful, but that it will lead you to view XML, Web services, and service-oriented principles as problem-solving tools. So that no matter what obstacles cross your path, you will be able to use your own blowtorch to carve out that perfect solution.
|
|
|
