Just What We Need: Another RPC Package
May 22nd, 2008 | Published in commentary, distributed systems, IDL, integration, RPC, SOAP, WSDL | 16 Comments | Bookmark on Pinboard.in
I see from this CIO Magazine article that 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:
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.
I was unaware that SOAP had become “traditional.”
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.
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.
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.
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?
The Etch integration into Visual Studio and Eclipse will be very familiar to anyone who has used SOAP integration tools. After authoring the IDL definition, the developer tells the IDE to generate either a client stub or a server skeleton. The client stub is usable immediately; the developer needs only to configure the transport and endpoint, and to code the message calls.
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!
Projects implementing their communications using Etch aren’t out of luck if they need to interoperate with SOAP, JSON, REST or other existing protocols. Cisco has already demonstrated the capability to easily create bridges between Etch and SOAP, according to Marascio. He said that turnkey bridges to SOAP and REST should be available six to nine months after the release of Etch.
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.
Cisco also is examining the possibility of establishing Etch as a standard. Marascio pointed out that Cisco is well represented in the IETF, the main standards body for Internet protocols. Alternatively, Cisco might attempt to promote Etch as an industry standard, an effort that would be aided by Etch’s open source nature.
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.
May 22nd, 2008 at 6:27 pm (#)
Steve, you write:
> I find it hard to believe that in 2008 people are
> still inventing stuff like this.
So what are the language independent alternatives we
have out there? SOAP and Corba both suck bigtime because
they are too big and too hard to understand. Especially
SOAP which is like a nightmare. I don’t like corba either.
SUN RPC I actually like, but it is usually a bit too simplistic.
I haven’t looked at this Etch (How on earth could they choose that name???) Wasn’t there a recent discussion on the erlang-questions list about some new light-weight marshalling stuff?
/klacke
May 22nd, 2008 at 8:58 pm (#)
@Klacke: I hope all is well. I personally always try to avoid RPC these days, so I may not be the best person to ask, but I can try to answer your question in a couple different ways:
BTW, since you don’t like SOAP, can we take it out of Yaws, or at least push it off to the side and make it optional? ;-)
May 22nd, 2008 at 9:01 pm (#)
for another language independent alternative with robust support, check out apache’s thrift project: http://wiki.apache.org/incubator/ThriftProposal
May 22nd, 2008 at 9:04 pm (#)
@Claes: You might want to take a look at Thrift. Thrift is a lightweight, open source, multi-language RPC system.
http://developers.facebook.com/thrift/
May 22nd, 2008 at 9:38 pm (#)
Don’t forget recentish Thrift (http://developers.facebook.com/thrift/) and ZeroC ICE. The 21st century isn’t nearly as awesome as I wished it to be.
May 22nd, 2008 at 9:51 pm (#)
Well, I see I wasn’t the only one with those two in mind. I leave a page open for less than an hour, and that’s what happens…
May 23rd, 2008 at 8:50 am (#)
+1 to ZeroC ICE
May 23rd, 2008 at 12:01 pm (#)
I agree, there are plenty of RPC mechanisms already. I find it hard to believe that we need another. The “cross platform” aspect does take a few protocols off the table, but there’s already Thrift, and Sun RPC.
DCE is open-source now as well, IIRC and can presumably be ported to various platforms. What I’m not sure of is what platforms it’s already been ported too.
There’s XML-RPC as well. And I think somebody was implementing an “RPC over XMPP” protocol, but not sure what the latest on that is.
As for SOAP… I think a lot of the opposition to SOAP is just groupthink in effect. You don’t need to read and understand the entire SOAP spec to use SOAP based web-services, so the argument that it’s a big complicated spec doesn’t do much for me. It works, it’s cross-platform, so keep it on the table as an option where it makes sense.
Also agree that the bigger question is “should we be using RPC at all, instead of messaging?”
May 23rd, 2008 at 12:08 pm (#)
> So what are the language independent
> alternatives we have out there?
@Claes Wikstrom: JSON. Lightweight, totally cross-language, and VERY low overhead. Combined with REST, it has all the power of RPC without all the XML-RPC or SOAP overhead. And, if you cryptographically sign all your payloads (to guard against tampering), you can even run the payload through Python’s eval() since all the valid JSON strings I’ve played with are also valid Python syntax. :)
May 23rd, 2008 at 2:30 pm (#)
The problem with JSON and XML-RPC is that they do not define
protocols only RPCs. In the protocols are statefull (which most protocols are) then, for example, the order of the permissable RPCs is undefined.
I have an alternative (UBF – see http://www.sics.se/~joe/ubf)
this *is* very lightweight – it was designed for fast parsing
and legibility) there is also a protocol specification language (in the form of RPCs with pre and post conditions) – this
is very lightweight, langauge neutral and actually describes
stateful protocols :-)
May 23rd, 2008 at 3:24 pm (#)
@Joe
“The problem with JSON and XML-RPC is that they do not define
protocols only RPCs. In the protocols are statefull (which most protocols are) then, for example, the order of the permissable RPCs is undefined.”
Exactly. As Steve has stated repeatedly on his blog and elsewhere, the wsdl/jax-rpc etc… proponents often act as though an IDL is all that is needed, and that humans don’t need to read the protocol spec. They can just generate the code for the RPCs. But this doesn’t take into account message/RPC ordering constraints. The reality is that you cannot hide protocol semantics.
BTW, Your UBF looks interesting. I just skimmed the paper and it appears that you do no code generation. This is good, as it removes the restriction on uniform code upgrade/compilation and removes versioning brittleness implied by this. The checker on each side can then be upgraded dynamically, while the protocols can either stay the same or change over time on each system independent of the other. The negotiation process can work this out. Thus versioning can be built in trivially. Also, since the types must be interpreted by the application, the developer must think clearly about how to implement his protocol. He cannot pass understanding of the underlying network layer off to some code generation tool and expect it to work. This is a far cry from almost all other RPC systems, and in fact I would hesitate to even call it an RPC system. It is more like a marshaling framework that enforces pseudo type safety and ordering constraints using semantic information, which as you state in the paper enhances introspection. Very nice indeed.
Just my 2 cents.
-Andrew
May 23rd, 2008 at 4:44 pm (#)
Another alternative is AMF3 by Adobe.
AMF3 Benchmarks
http://www.jamesward.org/census/
May 23rd, 2008 at 9:09 pm (#)
[…] Vinoski has come out very vocally against RPC in the last few days: see this blog entry and this mailing list post. The blog entry (which I read first) made him sound like someone who […]
May 23rd, 2008 at 9:54 pm (#)
Too many ‘RPC’s. Not enough time. :)
I’ve been learning Q/Kdb+ (http://kx.com/q/d/kdb+.htm) recently by Andrew Whitney from Kx Systems. Q is an RDBMS, a SQL, a general purpose data-parallel implicitly concurrent and a parallel/grid programming system
The following Q program defines a ‘trade’ table, and random data generation recipe to
populate 1 million tuples in the table… in 3 lines of code.
n:1000000
stocks:`goog`iona`ibm`msft`ebay`intel
trade:([]symbol:n?stocks; price:n?100.0;amount:100*10+n?20; time:n?24:00:00.000)
When run it can be accessed RESTfully over HTTP and resources returned in csv, xml, html, and/or can be queried and updated dynamically via HTTP, ODBC or JDBC.
Q is an interesting departure from other languages, however, it lacks what is in my opinion UBFs most interesting contribution: its introspective nature and the ability of a UBF distributed system component to describe itself. The fact that the protocol state is explicit and not implied (like in most/all traditional RPCs) is wonderful. That the protocol state can be asserted is a very powerful idea. Nice!
May 23rd, 2008 at 11:36 pm (#)
I had my fair share of frustrations with SOAP (RPC style), EJB and also CORBA to a certain extent. Given a choice I will always use messaging over RPC. If you have to use SOAP/WSDL then of course document style is always less painful than the terrible RPC crap. I don’t think anybody is using the dreaded rpc-encoded style anymore.
If HTTP doesn’t work for you and If you need to write message oriented distributed systems in multiple languages then “AMQP may be a good alternative. It already has support with clients in C, C++, C#, Java, Python, Ruby and of course Erlang.
May 31st, 2008 at 3:45 am (#)
I’m a bit late to this thread, but I’ll throw my 2c worth anyway. I think what this thread proves is that none of the standards have really stuck and got the long term continued adoption required. Even Mr CORBA himself is off with Erlang. Another Mr CORBA(Michi Henning) is off rebuilding CORBA, making Ice. A lot of people think SOAP (the saviour of the world) is fat and ugly. Apache is incubating Thrift. Now Cicso is throwing in Etch.
To me, the fact that we don’t have a really good solid answer to distributed computing means that more ideas are needed. I haven’t seen Etch yet, but I do hope it innovates and builds on the concepts of CORBA, SOAP and REST concepts. Each have great concepts that should be built upon. If they standardise it or not doesn’t concern me.
i built Argot(www.einet.com.au) to address what I think the real problem is. To me the real problem is in presentation and serialisation of data. If you get that right the transaction mechanism can be restful, or RPC, or Agent or whatever else. Atleast the data presentation is agreed. And in my book the presentation should be binary; it is afterall what computers are best at moving around. We just need better tools for designing structures, reading, debugging and versioning it.
Now if I could only find a Cisco or Google to support Argot, I could make it a standard too. :)