Your message tunneling problem is covered in the classical systems design theory paper, End-to-end Arguments in System Design by Saltzer et al.

Take care and best regards,
Z-Bo

http://soa.sys-con.com/node/250512

To do that, I’ve had to deal with Anonymous standing on his pedestal throwing belittling remarks.

Standing on a pedestal – yes I do that sometimes …

belittling – they were intended to be fun , sorry if you found them belittling …

Those remarks didn’t achieve much and shows his zealot nature. However, in between those useless remarks

talk about belittling … but I don’t really care … although I would disagree with you calling me a zealot, I wouldn’t care to argue why …

His method of creating an architectural style is a step above systems architecture

style (not his method) is a step above architecture – read the original paper documenting what Style is – garlan and shaw (and those guys were the first to study software architecture )

Next, REST is fundamentally not RPC

You had earlier argued exactly the opposite iirc, so are we zeolots for asking you to just RTFM ?!?

Hypermedia and the web is a fantastic solution for human/browser to computer communications. However, it offers only part of the solution in the area of computer to computer communications.

Thats how fielding intended it. Fielding when he first came out with REST only intended REST to be for information services , which when you think about it are a HUGE part of services and are VERY important – if your information services are hidden/pain in the ass to use – your employees are gonna be strait jacketed. So first please don’t “belittle” information services.

Second, it was only when everyone got us into WS-MESS that saner heads came together and said – look at that REST thing out there it seems to work nice for me , I am going to use it. This is not to say REST is complete and ready to use NOW . But as Martin Fowler/Jim Webber presented at infoQ, it is more like using the Agile method / evolutionary approach to distributed systems rather than the “intelligent design” that WS-* seems to favour.

The whole OSI 7 layer model is to me a pain to understand / use – I much prefer the TCP/IP 4 layer model. I can’t really reply to what you have written as I have long ago forgotten what these Session layer / presentation layers are – and I don’t see much point to the argument if I even find out.

RPC/SOA/ORBS have, without the mature tools to assist the developer.

As far as I can see, the only tools that developers really use (in WS-*) are the WSDL(with SOAP ofcourse) ones . Thats ALL. No one uses the other junk load of WS-* specs/ tools that vendors have come up with and are trying to sell. And as a result, all those most certainly aren’t mature.

communications which involve blocking synchronous request/response semantics?

Barriers ? :)

Seriously, great stuff Steve. I wrote a blog entry about taking into account the human element in software abstractions – i.e. the impact on productivity and development cost by making it easier for people to do things like distributed computing. I would argue that sometimes this is more important than purely technical considerations such as performance or clean code.

But I completely agree about the main point – which as I understand it is being sure to use the right tool for the right job, and not just blindly using RPC because it’s convenient.

I have a couple of other more detailed comments that I thought I’d add to the discussion.

On the definition of RPC – using RFC 707 is a bit like using the SOAP specification to define SOAP. I mean that there’s often a difference between theory and practice, and what we complain about with SOAP (myself included, despite the fact people are getting value from it) is that the spec isn’t implemented correctly. If you read the SOAP and WSDL specifications – the latest versions, especially, you would think they are very RESTful. But no one implements the RESTful bits – they tend to focus on the RPC style (as you have said, IONA has been as guilty of this as anyone despite our efforts to lobby for implementing the document oriented style).

I don’t want to go into a huge digression on this, but to me this is a great example of a kind of innovator’s dilemma, or a side effect of one. When we talk with our customers about SOAP, WSDL, etc. they tend to say something like “if you want me to use that, it has to be just as performant, reliable, secure etc. as what we already have.”

This of course entirely misses the point, since what’s important are the application requirements, not the technology used to develop the application. As you have pointed out many times, a RESTful approach could as easily meet many if not all enterprise application requirements. But (as you have also pointed out) this would require a change in thinking that a lot of people seem unwilling to tackle.

Another minor comment – the inability of the industry to solve the data type mapping problem does not in itself mean that the RPC mechanism is useless. It is true that interoperability decreases in proportion to the complexity and number of data types involved, but that doesn’t mean RPCs aren’t useful.

It is interesting to read about Erlang, REST, and explicit programming for distributed computing as a kind of historical advance. When RPCs first came out, we viewed them as a technological advance over the dominant style of the day, which was P2P (LU6.2 was the leader – and man, no one wanted to program that if they could avoid it).

But I also take the point that you are going to get better results for many types of distributed applications by explicitly programming. And I am also very impressed by what I’ve been reading about your Erlang work.

I don’t really think of RPC = transparent distribution. I think of RPC as a programming model. By definition people know they are doing remote calls because they have to create some kind of interface definition, compile proxies and stubs, link them into their applications, etc.

When I think about the big picture of distributed computing, it seems like there will always be some number of applications for which RPC is a better fit, and some number of applications for which asynchronous messaging is a better fit. One of the big problems I think we all have is that there is so much overlap in what can be done using either approach. I have a rule of thumb for this that depends on the significance of the reply. If the reply to a message needs to indicate whether or not the database update was performed, for example, RPC is a better fit. If the reply simply needs to indicate that the message was received, then asynchronous messaging is a better fit.

I know the above is kind of impressionistic, and not very precise. I suppose the point is to think about the tradeoffs and not just try to use one or the other for everything.