Cisco To Open-Source New Messaging Protocol 118
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.'"
Distributed computing. (Score:2, Interesting)
SOAP could be easily integrated over current HTML based networks without need to make hole in firewall. But it was pig slow and designing stateful services was painful.
CORBA offered more technical challenges viz, complexity, version control, fault tolerance (not that a SOAP HA services is piece of cake, but I don't want anybody to go through torture of designing a HA CORBA server)
ZeroC's ICE (Score:5, Interesting)
CORBA was shit. SOAP not much better. (Score:3, Interesting)
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.
If this catches on then how long would it be (Score:0, Interesting)
They will no doubt trumpet loudly their 'innovation' at the same time.
I hope Cicso license this in such a way that they could stop this sort of trick that M$ has played before on an 'open standard'
Cisco, Please use the LGPLv3 license. (Score:4, Interesting)
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.
Ice? (Score:4, Interesting)
Imagination (Score:3, Interesting)
There's absolutely no ethical reason to choose a less restrictive license over the GPL. The only thing the GPL restricts is the ability to restrict others. THAT is possibly a reason to avoid it, since, for example, I would like to prevent military types from using things I worked on, but avoiding the GPL because you want corporations to have the ability to use public works it in works they then keep from the public is a VERY strange notion.
Re:Microsoft's Kerberos (Score:3, Interesting)
Re:Imagination (Score:4, Interesting)
Re:GPL (Score:5, Interesting)
Re:GPL (Score:2, Interesting)
The company I work for sells closed source software. We also use some open source software (not GPL) in the product.
We contribute back to the open source we use because it's more sensible. Adding the same features back in again and again would be counterproductive. We'd rather they get added to the open source project permanently.
We have a blanket ban on using GPL'd source, though. We can't afford to GPL our entire 20 million line software stack, which would be the result of using even a tiny bit of GPL code.
Try to understand that not everyone loves the GPL and not everyone that doesn't love the GPL is a troll.
Now it's my turn to get modded into oblivion for not being fond of the GPL. Sigh.
Re:CORBA was shit. SOAP not much better. (Score:3, Interesting)
Taking SOAP as an example, because that's the one I know best. What you need is some way to communicate data to another party. What you get is something that does that, but in about the most verbose and latency-sensitive way imaginable. Yes, it's standards-based, which is a Good Thing, and it's human-readable, which is also advantageous.
On the other hand, the standard is apparently complex enough that various implementations implement distinct subsets...meaning interoperability is hit and miss. And seriously...HTTP and XML? Horribly inefficient.
All I know about Java RMI is that it was a horrible pain to get everything set up right so that it would work...and even then, of course, it's _Java_ RMI, so I'm not sure it's the best choice if you don't want to prescribe a particular platform or object model.
What I think all these have in common is that they try to automagically solve a problem that can hardly be solved automagically. The premise, as far as I understand, of protocols like this is that they will let you exchange objects from your program with programs on remote machines, without you having to do any work on it. But, in practice, it's hard to decide how to go about that without specific knowledge of how these objects will be used. Specifically, objects tend to be part of a graph...which parts of the graph do you send over the wire? And then there's all the actually hard problems related to distributed programming...
As for the protocols, I've always thought it shouldn't be that hard. Lisp has this thing where you can read and write Lisp objects. Write it out and read it back in and you'll get an equal object. This is incredibly useful for many things, including debugging, but also makes it easy to envision a protocol for distributed computing - especially when you consider that Lisp programs also consist of Lisp objects.
On the other hand, Lisp's read-write protocol isn't the most efficient as far as parsing and transmission are concerned. So something could be gained there. And not all objects can be read back in - for some it would even be a Bad Thing if they could. And none of the harder problems (like which parts of the graph to send) have been addressed yet. On the gripping hand, I honestly feel it's already better than SOAP.
For the rest, I think the trick is to keep things simple. Think of what you want to send. Encode that using some simple, efficient encoding, and send it. Don't shoot for automagic, Just Works exchange of arbitrary program objects. Think about what you really need to send and send only that.
Oh, and don't draw in layers and layers of frameworks, please.