My colleagues Peter Cousins and Ivan Casanova like to use audio/video connectors as an analogy for service-oriented architectures (SOAs). Audio has been a long-time hobby of mine, ever since I was 14 or so. A few years ago I built my own home theater. Consider the rear panel of my Denon 4802 receiver:
Wow! Look at all those connectors! Ignoring the speaker and power connectors, there are RCA audio connectors, digital coax connectors, optical cable connectors, RCA video connectors, S-video connectors, and component video connectors. Why so many?
Today, video sources such as DVD players tend to support multiple connection choices: RCA, S-video, and component video. Depending on the quality of service I desire, I pick whichever one I want. Component video gives me the best video quality, S-video next, and the lowest common denominator RCA after that. For audio, I can do Dolby decoding either within the DVD player or within the receiver, whichever I think sounds best. Basically, whatever the DVD player supports, the Denon receiver can handle, and since the DVD player offers multiple connection choices, I can choose the one that best suits my system.
These connection types change over time. But I shouldn't have to replace all the components of my home theater every time someone devises a new approach! Having a receiver like the Denon 4802 capable of accepting and delivering so many different connection types and formats means that I can use my components for many years, without needing to entirely replace the system every time a new connector approach is devised.
In the land of middleware, this is precisely how SOAs are supposed to work. A service is defined not by the protocol or the transfer syntax used to communicate with it, but by its semantics and what it does for the service consumer. A consumer should be able to connect to a service via any reasonable means and use it.
Unfortunately, the middleware industry is largely blind to this revelation. Instead, it remains hung up on protocol and transfer syntax, failing to separate them from the services themselves. SOAP (over HTTP) is of course the darling protocol and transfer syntax of the day, but that will change. It will eventually fall out of favor. Numerous protocols and transfer syntaxes came before SOAP, and numerous others will follow. Do you rewrite your services every time something new comes along?
Our web services Artix product is a lot like that Denon 4802 receiver, in that you can connect to it in a lot of different ways. Your services are likely written in multiple programming languages and are likely hosted over multiple middleware systems running on multiple operating systems. Every other middleware vendor wants you to rewrite your services to use their platform every time they come up with a new idea -- they promote homogeneity despite the fact that computing systems are naturally hetergeneous. With Artix, you can leave your service in MQ, or TIBCO, or Tuxedo, or CORBA, or whatever. Artix can get to it, transparently and with extreme efficiency, even if your service consumer sits on top of a totally different technology. You worry about your service, and let us worry about the connectors and infrastructure required to future-proof both your service and its consumers.