Slashdot Mirror
Cisco To Open-Source New Messaging Protocol
Esther Schindler writes "Do you use SOAP, CORBA or EJBs? You might want to take a look at Etch, writes James Turner for CIO.com. It's language-, platform- and transport-agnostic, and Cisco is planning to release it as open source. Certainly, it offers some technical benefits: 'In addition to a simplified configuration, Etch also promises less overhead over the wire, compared to SOAP. In a testbed environment where SOAP was managing around 900 calls a second, Etch generated more than 50,000 messages in a one-way mode, and 15,000 transactions with a full round-trip, company officials stated.' And the open source part? Cisco is in the process of deciding what license to use. 'The intent is to use a less restrictive license than GPL, perhaps Apache or Mozilla. This is to allow commercial developers to incorporate Etch into products without licensing issues. A final announcement on the licensing decision will be available in the next month.'"
Someone please add the tag 'suddenoutbreakofcommonsense' to cover the licensing decision.
Invenio via vel creo
Glad to see more and more companies moving away from GPL, understanding that it will only limit the potential adoption. As a highly respected registered member of the Slashdot community, I'm posting as AC as this post will very likely be modded troll.
It'll be interesting to compare Etch to ICE, which is a GPL'd open-source, cross-language RPC toolkit (you can buy commerical licenses too). It's quite widely used by banks and is generally reckoned to be speedy.
Go somewhere random
looking at the width
of the column in the
article, and cio.com
wonders why nobody
visits their site
and so they have to
pimp their ad-laden
site on Slashdot in
a sure sign of des-
peration. Click next
to continue.
You open-source a protocol by providing a specification with no attached IP rights, such as patents covering the protocol. A reference implementation kind of helps, too.
"Software is too expensive to build cheaply"
All of these distributed technologies have been shit. CORBA was absolutely hell to develop with. Besides the runtime performance problems, development was always a huge hassle. It rarely just worked. J
Java's RMI was slightly better. But again, the development overhead was huge. Generating proxy and stub classes becomes a chore really quickly, and debugging becomes a real challenge.
SOAP was a little bit better than CORBA and Java RMI. At least writing the object layer code is a far more reasonable task. The performance, though, was complete shit compared to Java RMI and Corba. Whatever development time you saved initially in writing the SOAP interfacing code was instead spent trying to optimize what you had so that it wouldn't perform so fucking horribly.
In some ways, I hope that Cisco can do better. But I really don't know if that's possible. It may just be the nature of the beast that these sort of technologies perform poorly, are slow to develop, and are often nothing more than a huge hassle.
Wouldn't that be "open spec" instead of "open source", with the open source reference implementation being a separate issue?
The LGPL is the only license that will insure that at least that Cisco's implementation of the protocol can not be easily extended in an inoperative manner.
Given the timespan that Cisco expects the protocol to be in use, version 3 of the LGPL is the best option.
Other than license, how does this compare to ZeroCs Iceï¼Y Does anybody know? I've played with Ice before and it's very well done, although I remain to be convinced of the value of remote object references in a distributed system.
A test suite wouldn't have helped. Win2k worked just fine with normal kerberos as a client and as a server. The problem was that if you wanted to deal with domain based groups you needed an extension, something that MSFT wasn't intrested in letting people have for free.
Both those protocols suffer from 1 problem: bloat. The reason they're bloated and inefficient is because a committee decided how and what to add to the protocol once it was initiated, and we all know how well that works out.
:) ) transfer COM calls over a http tunnel instead of the usual DCE-RPC tunnel, and it worked well when you only wanted to send a request to an object. Obviously, it has to have a webserver on the other end which slows it down tremendously, and then they added support for all kinds of complex types and a large schema as well. I'm surprised it works at all after seeing the raw WSDL code!
SOAP was a 'quick and dirty solution (by Don Box IIRC) to (apart from getting a job at MS
CORBA... designed by committee to do everything including transport kitchen sinks.
Since I've been working in the industry there is a tendency for supposedly bright people to take something simple and 'make it a general purpose solution' or 'implement some framework features' which nearly always breaks it into a bloated POS far removed from the original, simple, easy to use, and effective solution.
I welcome Cisco's new protocol, I don't care if it doesn't do everything I might possibly ever want to do, as long as it does the majority of my work quickly and simply. I can work around the edge cases myself, possibly even (gosh!) redesigning the way those edge cases work.
Flaming the GP isn't correct in this case, the summary is ambiguous. There is a difference between managing calls and generating messages, as a single call can generate multiple messages.
A correct summary would have been to compare the amount of calls a second both SOAP and Etch can handle, or the amount of messages/transactions required for a fixed number of calls. But I think the PR-drone that wrote up the article did so knowingly to put SOAP in a bad light.
Or are you simply being sarcastic? If so: WOOOOOSH!
This sig is intentionally left blank