http://www.cio.com/article/365513 wrote:
Cisco Systems' New Client/Server Messaging Protocol Announced
[...]This week Cisco Systems announced a new messaging protocol intended to allow developers to integrate client/server applications without the overhead of traditional protocols such as SOAP. [...]

For project managers starting new work, Etch may offer an attractive alternative to SOAP, CORBA, EJB and other established messaging protocols. Etch promises a distributed application development without the cross-platform headaches that SOAP entails, and with a degree of performance that makes it practical for real-time applications that are chattier than traditional SOA infrastructures are set up for.

[...]as [...]Cisco explained, when you whittle it down to the intersection of features that are compatibly implemented by the available SOAP platforms, the feature set shrinks considerably. [...] Cisco is committed to having 100 percent functional compatibility of all features on all supported languages and platforms.

[...] One of its design goals was to create an inter-application communications technology without SOAP's complexity and overhead, explained Marascio. While SOAP relies on a very complicated WSDL file to define the interface between the client and server, Etch uses a file in Cisco's own interface definition language that shares many similarities to a Java interface file.

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.

Etch is also language- platform- and transport-agnostic. The initial release will support C# and Java, said the presenters, including integration into Visual Studio and Eclipse. Implementations for Ruby, Python and C are planned for the near future.

Cisco intends to release Etch as open source, and 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, said Cisco staff.

http://steve.vinoski.net/blog/2008/05/22/just-what-we-need-another-rpc-package/ wrote:
Just What We Need: Another RPC Package

[...] Cisco is releasing a new client/server messaging system called Etch. Sigh ? those who don?t know history are indeed doomed to repeat it. Some choice quotes from the article:
[...]
I was unaware that SOAP had become ?traditional.?
[...]
I bet this new IDL is not only simpler than WSDL, but it probably also avoids all the impedance mismatch problems that invariably occur when mapping IDL to programming languages.
[...]
Oh good, the ?performance presumption.? So now we?re back to where we were a decade ago, at least as far as message transfer rates go. I wonder if Etch also solves the problem that the bottlenecks usually lie elsewhere?
[...]
"On the server, the developer takes the skeleton and implements the business logic that lives inside the message handlers."

Now that?s what I call innovation!
[...]
Or, to put it another way: Etch is really just adding more stuff to be developed, tested, deployed, managed, maintained, and integrated, yet it doesn?t actually solve any new problems or solve any old problems better than what already exists.
[...]
Well of course you want to standardize it ? where would any new NIH RPC protocol be without an accompanying standards effort? Rather than the IETF, though, perhaps you ought to get those ISO OOXML guys to rubber-stamp it?

I find it hard to believe that in 2008 people are still inventing stuff like this. Sheesh. Color me underwhelmed.

http://blog.reverberate.org/2008/05/23/defending-rpc/ wrote:
Steve Vinoski has come out very vocally against RPC in the last few days[...]. The blog entry [...] made him sound like someone who just hasn?t been around large systems much, but then I was surprised to see that he?s a senior fellow or architect or something along those lines at a company that does distributed systems.

His blog entry basically makes fun of Cisco for inventing/releasing another RPC system. It?s not clear exactly what he thinks they should have done instead. What is strange about this criticism is that tons of technology companies have developed their own RPC system ? Facebook and Cisco publicly, and other technology companies I am familiar with in a not-so-public way. Guess what: large commercial distributed systems are built largely on RPC. Is he arguing that all of the engineers at these companies simultaneously got the bad idea of investing in something they don?t need? If RPC is such a bad idea, then why is everybody doing it?
[...]
But then again, I don?t know of any RPC system that tries to hide this [network problems] from you except possibly CORBA. Maybe there?s a horrible history here I don?t know about, but no RPC system I have ever encountered tries to hide from you the fact that on a network, shit happens.
[...]
RPC systems that make you do an ?all at once? upgrade are a bad idea. But again, no RPC system I have encountered makes you do this. Does this mean that the RPC system guarantees for you that the old and new protocols are compatible? Of course not ? you don?t want your framework to be some big ?I know what?s best for you? mommy that does really expensive things to solve this problem, like loading both versions of your code at the same time. But any RPC framework worth its salt makes it possible to have different interface versions interoperate. Adding a new parameter? No problem, old servers simply won?t see it. Completely changing the semantics of your call? No problem ? just give the new call a new name.

Steve?s criticism amounts to ?sucky RPC systems suck.? Yes Steve, yes they do. But a lot of the technology world is running on non-sucky RPC systems, and from time to time you get a glimpse of that when a company like Facebook or Cisco releases their internal RPC system to the outside world. Did Steve check to see if Cisco?s new RPC system is subject to any of his critiques? I haven?t, but I would suspect it isn?t.

http://steve.vinoski.net/blog/2008/05/24/defending-something-other-than-rpc/ wrote:
Defending Something Other Than RPC
Josh Haberman takes me to task for my previous posting:

Steve Vinoski has come out very vocally against RPC in the last few days?

Actually, I?ve been saying similar things for years now, Josh, not just the last few days. For example, I noted problems with RPC in[ lots of articles written by him]
[...]
I think my posting pretty clearly implies that Cisco should have avoided writing their own and instead should have reused something that already exists.
[...]
Is everybody really doing [their own rpc system]? Are large commercial distributed systems really built largely on RPC? I?ve seen some non-trivial CORBA-based deployments over the years, but in my experience large systems are built using approaches other than RPC. Like the Web, which isn?t RPC. Like email, which isn?t RPC. Like pub/sub enterprise messaging systems, which aren?t RPC.

Let?s consider the definition of what an RPC actually is. The term is often misused to mean ?a synchronous call to another system over the network.? This is not what an RPC is. For example, an HTTP request is synchronous, but it is not an RPC. RPC, rather, is a specific approach for developing networked applications where local calls wrap and hide operations that happen to be carried out on another system across the network. [...]

Next, let?s check RFC 707, where RPC comes from, in which James E. White specifically proposed a procedure call model for networked applications designed to hide the network, and thereby allow developers to use familiar approaches to developing applications that happened to perform network operations. [...]

As you can see from the original definition of RPC, something called an RPC that doesn?t hide the network is, by definition, not an RPC. As I said above, unfortunately the term is often misused as meaning ?synchronous messaging,? and that incorrect usage seems to be what Josh is defending. Josh then says:

But then again, I don?t know of any RPC system that tries to hide this from you except possibly CORBA.

That?s not correct either. What CORBA actually does is make everything appear remote, even local objects, but does so in a way that allows object request broker (ORB) implementations to bypass much of the overhead of remote invocations when the ORB knows that a target object is local. Still, not all the overhead can be eliminated due to object lifecycle and method dispatching requirements, meaning that such local calls are typically never as fast as true local calls. DCE also treats services as always being remote, but last I checked it included no local bypass optimizations (though a variant called OODCE once did this, IIRC). But either way, what?s important with these systems is that calls within your code look just like any other calls within your code, whether they?re calling remote operations or not. And that?s RPC.

Regarding versioning problems, Josh says:

But any RPC framework worth its salt makes it possible to have different interface versions interoperate. Adding a new parameter? No problem, old servers simply won?t see it. Completely changing the semantics of your call? No problem ? just give the new call a new name.

Yes, Josh, there are generally ways to do versioning in such systems, but they?re not very good. CORBA includes some facilities to help with versioning, but in practice they don?t actually help that much. Both COM and CORBA promoted interface inheritance and runtime interface negotiation (called ?narrowing? in CORBA) as a way to do versioning, which works, but only for a restricted set of changes. Add a parameter to an existing call? [...]
Middleware and distributed systems veterans are well aware of the arguments like the ones I?ve made in my blog and other places recently and in various publications over the years; such arguments are generally common knowledge among us, and have been for years.

Cisco?s system is not available yet, but when it comes out, I?m quite certain you?ll find, Josh, that it?s the same old thing, just repackaged in a new box.