A competitor of ours just announced a new product that (in their words)...
...extends and bridges proprietary message-oriented middleware (MOM) products, like TIBCO Rendezous, IBM WebSphereMQ (formerly MQ Series), SonicMQ and any other JMS-based solution, to support any standards-based Web services endpoint.
The product described above is a gateway (in fact, it has the word "gateway" in its name). Gateways are simplistic -- anyone can write one. Gateways add moving parts to your system that must be deployed, maintained, and managed, and since they're intermediaries, gateways increase overall system complexity while reducing performance, throughput, and scalability. Worst of all, if they're done poorly, gateways can be single points of failure, reducing overall system reliability and availability.
If you were traveling in another country where they spoke a different language, would you prefer to be able to read and speak that language yourself, or would you rather have to rely on translators to allow you to converse with the natives? The preferred approach should be fairly obvious -- the overhead of the translator route is significant, making it hard to get anything done. Gateways are similarly poor solutions for most integration cases.
Disintermediation is where it's at. Adding support for multiple protocols, transports, and wire formats directly into the service and consumer applications themselves allows them to converse directly with each other even though they might be built on totally different platforms or technologies. As I explained in a previous blog entry, service capabilities and business logic should be independent of whatever transports, wire formats, or protocols are used to talk to them.
Supporting disintermediation is precisely why we designed our Artix web services product in a way that allows it to be embedded directly into applications, thus providing them with multi-middleware capabilities. Artix supports MQ, TIBCO, JMS, Tuxedo, CORBA, and SOAP over HTTP/S for C++ and Java applications. And when SOAP or the others eventually get displaced by some newer fancier protocol, which of course is inevitable, your Artix-based application will be able to adopt them quite simply via new dynamically-loaded plug-ins (all Artix transports are implemented that way).
Of course, supporting multiple transports and protocols isn't easy. But even harder than that is supporting security and management across those multiple approaches. Since we know that our solution wouldn't be viable without such support, we provide significant enterprise-quality security support and management solutions.
It all has to perform well too, and Artix performance is outstanding, especially given its high degree of flexibility.
About the only place where it's OK to suffer a gateway is a situation in which the applications involved absolutely can't be touched. For such situations, Artix can also deployed as an intermediary. However, unlike some of our competitors, we give you the choice of using a gateway or taking the disintermediation route, rather than forcing you to adopt a slow, high-maintenance gateway for all cases.
Given all the above, if I had to compete against Artix, I'd personally be embarrassed to issue a press release touting a mere gateway.
Anyway, like I always say, find out for yourself: download Artix and give it a try.
Comments (2)
Steve,
First, I have to apologize for my English. However I have been learning it for quite a few years I'm still not perfect at it. I'm native Czech and I'm product manager of the "weird Gateway" product that you are apparently talking about. I would really love to find some magic way how to learn English and also other languages overnight. Unfortunately, similarly as in IT, such miracles do not happen. So if I need to talk to Chinese once, I prefer to leverage a translator rather than spend years learning this great language. You guys at IONA might have different opinion on this and I'm perfectly fine with it. :
I'm not used to react on such marketing-ish stuff, but in this case I could not help myself.
I appreciate Artix with all its great capabilities including sending SOAP messages over whatever transport you can name. You have architected a nice pluggable transport architecture. This is all nice, but in my opinion, kind of late. I suggest you to go back with http://web.archive.org/web/*/http://www.systinet.com and examine when Systinet introduced the exactly same architecture in our WASP (Web Applications and Services Framework). If I remember correctly it was in early 2001. Both Java and C++ WASP supports all protocols that you have enumerated in your blog--along with others--for more than three years. Our Gateway product inherits this plugin architecture and adds the same capability for other frameworks like .NET.
Comparing Artix to Gateway is like comparing apples to oranges. Reading your article I was really surprised how universally bad the gateway (translator) approach is. You don't speak of the use cases for a gateway, they seem to not matter to you. Gateway is built around usecases that we have learned from using our transport plugins in the field. There are many deficiencies of the transport plugin approach. One of the main issues is that you have to deploy MOM (Tibco RV, MQ etc.) client libraries to every endpoint. Gateway solves this and other issues and enables lightweight, secure and reliable integration of web services with MOM backbones. Gateway is about doing such integration in new, cheaper and more effective way.
Hopefully I explained at least a bit why we are not embarrassed to issue a press release touting a "mere" gateway.
ZD
Posted by Zdenek Svoboda | May 20, 2004 10:04 PM
Posted on May 20, 2004 22:04
Hi Zdenek,
Thanks for your comment. It's nice to see a considered reply that addresses my technical posting, rather than the wholly non-technical content-free invective that one of your colleagues aimed at me just because I correctly pointed out that his new Gateway was technically boring.
I joined IONA in 1996 to build our Adaptive Runtime Technology (ART). ART is a highly-adaptive distributed systems microkernel that employs plug-ins at multiple levels, including at the protocol and transport levels, and yet is blazingly fast, operating at speeds that match or better those of monolithic distributed applications. My ideas for ART were based on earlier work I had done going back over a decade ago on multi-protocol CORBA systems.
Artix is based on ART, as is Orbix 6, as is XMLBus, as was our Application Server Platform (ASP), as was Orbix 2000. This mix of products include enterprise CORBA systems, a full-fledged J2EE system, and two Web Services systems, all based on the same ART infrastructure. The power of ART is therefore quite easy to see. Your introduction of support for multiple protocols in 2001 was many years after we had already built that support into numerous products.
Like I said, Artix can do everything the Gateway can do, and then some. I know full well when gateways are needed and why sometimes there's no alternative. But for cases where there are alternatives -- and there are many -- being stuck with only a gateway is a very limiting choice.
However, WASP cannot do what Artix does. It cannot allow a developer to describe a service in WSDL, and then natively use Tuxedo, MQ, TIBCO, IIOP, JMS, etc. bindings directly from WSDL, using native data formats such as fixed or FML. Your colleague Radovan claims this is not a useful thing, but tell that to our customers. In fact, if it wasn't useful, then you guys wouldn't have created your Gateway in the first place.
You're right that comparing Artix to Gateway is not an apples-to-oranges comparison, but not in the sense that you probably mean. The comparison is not a good one only because Artix can either be embedded directly in the endpoint, or deployed as a gateway/intermediary, whichever the customer prefers. The same is not true of your Gateway.
Posted by Steve Vinoski | May 20, 2004 10:05 PM
Posted on May 20, 2004 22:05