SOA Using

Pat Helland, formerly of Microsoft, has a great acronym he likes to use
when talking about interoperability: HST, or “Hooking Stuff Together.”
(Actually, he uses an altogether different word there in the middle, but I’m
told this is a family book, so I paraphrased.) No matter how much you dress
it up in fancy words and complex flowcharts, interoperability simply means
“Hooking Stuff Together”—something Web Services are all about.
Ever since the second computer came online, True Interoperability
remains the goal that still eludes us. IT environments are home to a wide array
of different technologies, all of which serve some useful purpose (or so I’m
told). Despite various vendors’ attempts to establish their tool of choice as the
sole/dominant tool for building (and porting) applications, the IT world has
only become more—not less—diverse. Numerous solutions have been posited
as “the answer” to the thorny problem of getting program “A” to be able to talk
to program “B,” regardless of what language, platform, operating system, or
hardware the two programs are written in or running on. None had proven to
be entirely successful, either requiring an “all-or-nothing” mentality, or offering
only solutions to handle the simplest situations and nothing more.
In 1998, Don Box and Dave Winer, along with a couple of guys from
Microsoft, IBM, and Lotus, sat down and wrote a short document
describing an idea for replicating a remote procedure call stack into an
XML message. The idea was simple: If all of the various distributed object
toolkits available at the time—DCOM, Java RMI, and CORBA being the
principal concerns—shared a common wire format, it would be a simple
matter to achieve the Holy Grail of enterprise IT programming: True
Interoperability.