Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The S stands for Simple

72.249.21.88

Post reply on HN
Print view View original

31–40 of 54 posts

Re: The S stands for Simple

#31

Post by 10ren »

iamaleksey wrote: post #6
10ren wrote: post #4

Interoperability is a vitally important but hard problem. CORBA and then SOAP have been thoroughly adopted, then widely condemned. What's next?

REST, Thrift, AMQP + protobuffs.

http://incubator.apache.org/thrift/ http://en.wikipedia.org/wiki/Advanced_Message_Queuing_Protoc... http://code.google.com/p/protobuf/

Sounds intriguing - can you elaborate on why this combination is favoured in particular? Or point to an article that discusses it? It's hard to get widespread adoption if it's not accessible...

incidentally, google protocol buffers seems similar to http://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One (ASN.1), which predates XML, but didn't take off.

Re: The S stands for Simple

#32

Post by jrnkntl »

csytan wrote: post #17

Using the Q & A style to introduce a topic works really well. I hope more people start writing like this.

This method clearly made me understand (and a lot of my fellow Media studies students) the whole Actor-Network theory of Bruno Latour and writing for academic papers in general.

"A prologue in form of a dialog between a Student and his (somewhat) Socratic Professor" http://www.bruno-latour.fr/articles/article/090.html

Re: The S stands for Simple

#34

Post by flatline »

steve_g wrote: post #26
three14 wrote: post #15

If you know that you're only going to be using the Microsoft stack, and you actually do get to use the tools that cover all this up, do you still end up regretting that there's SOAP under all of it? I've just found myself working on a project like that for the first time, and saw this, and started wondering.

If both ends of the communication are on the Microsoft stack, setting up SOAP webservices is straightforward. The tools basically take care of everything. In our case, we have a customer who exposed an ASP.NET webservice that we consume (data flows in both directions). Our production apps use VB.NET to hit the webservice, but I was able to easily write a python client for testing (by handrolling the SOAP messages). M…

Well, yeah, except you used to be able to throw up an endpoint as an asmx file and it just sort of worked. Now you are guided to create a separate WCF application. So you get a book on WCF and start reading. You create a "hello, world" app but it takes three days of playing with the config file and reading half of MSDN to get it to work. Now that you know all kinds of stuff about message and service contracts, you can't do things like pull the raw HTTP headers because it's not necessarily bound to HTTP (who's using those other protocols, again?) And, you can't latch on to just any point in the request handling because it may be any sort of request. Another week with MSDN and you've finally gotten something kind of close to what you want, which involves running with aspNetCompatibility and might as well just have been an asmx endpoint, and which would have taken about half a day's work with the old toolkit.

Not that I would know from personal experience.

Re: The S stands for Simple

#35

Post by joss82 »

10ren wrote: post #4

Interoperability is a vitally important but hard problem. CORBA and then SOAP have been thoroughly adopted, then widely condemned. What's next?

XMLRPC. Very easy to use. There is a solid xmlrpc client in python > 2.2

http://www.python.org/doc/2.6/library/xmlrpclib.html

A small criticism : some network overhead (it's XML's fault).

Re: The S stands for Simple

#36

Post by iamaleksey »

10ren wrote: post #31
iamaleksey wrote: post #6

Earlier quoted context omitted.

REST, Thrift, AMQP + protobuffs.

http://incubator.apache.org/thrift/ http://en.wikipedia.org/wiki/Advanced_Message_Queuing_Protoc... http://code.google.com/p/protobuf/ Sounds intriguing - can you elaborate on why this combination is favoured in particular? Or point to an article that discusses it? It's hard to get widespread adoption if it's not accessible... incidentally, google protocol buffers seems similar to http://en.wikipedia.org/wiki/Abstrac…

ASN.1 actually did take off, somewhat, at least in telco. And after comparing thrift to protobuffs to ASN.1 for our internal protocol I ended up chosing ASN.1, mostly because of the great ASN.1 support in the OTP (I'm using Erlang). Erlang protobuffs library, on the other hand, is somewhat lacking and is terrible at encoding/decoding huge messages with big lists.

And AMQP was chosen for the transport layer because it handles persistent messages, transactions, all the routing, buffers messages, etc., etc. I'd have to implement all of these myself, had I chosen thrift.

This is how I ended up with RabbitMQ and ASN.1.

Re: The S stands for Simple

#37

Post by panic »

steve_g wrote: post #26
three14 wrote: post #15

If you know that you're only going to be using the Microsoft stack, and you actually do get to use the tools that cover all this up, do you still end up regretting that there's SOAP under all of it? I've just found myself working on a project like that for the first time, and saw this, and started wondering.

If both ends of the communication are on the Microsoft stack, setting up SOAP webservices is straightforward. The tools basically take care of everything. In our case, we have a customer who exposed an ASP.NET webservice that we consume (data flows in both directions). Our production apps use VB.NET to hit the webservice, but I was able to easily write a python client for testing (by handrolling the SOAP messages). M…

Part of me wonders whether this difficulty of interoperation is intentional on the part of Microsoft.

Re: The S stands for Simple

#38

Post by garnet7 »

InclinedPlane wrote: post #19
JulianMorrison wrote: post #13

Earlier quoted context omitted.

JSON in HTTP GET/POST. It's more of a nuisance, but it forces you to face the network issues head-on, and code that reads JSON can't afford to make assumptions, so it ends up less brittle.

Not just JSON and HTTP but specifically REST w/ JSON. There's a lot to be said for such a model.

What's the difference between "JSON in GET/POST" and "REST with JSON"?

Re: The S stands for Simple

#39

Post by antonovka2 »

blasdel wrote: post #27
antonovka2 wrote: post #12

Earlier quoted context omitted.

I hope not. Between Protobuf and Thrift, I don't see the point of adopting a less efficient, even more niche NIH serialization format and RPC protocol.

Both protobuf and Thrift are designed exclusively around simple static type-checking with type-erasure. Neither support heterogeneous collections, much less discriminated unions or GADTs. There are plenty of untaken vertices in the serialization-format hypercube.

Heterogeneous collections, discriminated unions, and GADTs can be implemented easily in either thrift or protobuf by leveraging inclusion of custom type-tagged messages/data.

However, while the encodings are absolutely sufficient to represent these data structures -- if you so choose -- my experience dictates that keeping serialized messages typed and as simple as possible is advantageous from the perspective of long-term maintenance and interoperability.

Re: The S stands for Simple

#40

Post by dabent »

iamaleksey wrote: post #6
10ren wrote: post #4

Interoperability is a vitally important but hard problem. CORBA and then SOAP have been thoroughly adopted, then widely condemned. What's next?

REST, Thrift, AMQP + protobuffs.

I actually coded one of Facebook's coding puzzles (Battleship) using Thrift and was pleasantly surprised. It provides support for many languages and getting up and running was a snap. I hope it catches on.
Post reply on HN