7 ms·

What about e.g. HTTP? The dynamics of server to server communication are all about message passing (REST is just a message conveying state, if you ignore the ot

What about e.g. HTTP? The dynamics of server to server communication are all about message passing (REST is just a message conveying state, if you ignore the other rules). Look at things like Erlang and Elixir processes. Akka and the actor model. Map/Reduce to a certain extent. These are all founded on the idea of giving a task out with enough information that the worker can reasonably go and work on the task without having to look around for state. Also look at things like FRP and more event driven architectures. While not ThingA sends message to ThingB, ThingA still broadcasts a message, possibly containing the relevant state. Also almost forgot. Look at the wealth of message queues that exist (RabbitMQ, ActiveMQ, SQS, Kafka, ... the list goes on).

ivan_gammel 10y ago
HTTP is closer to RPC. You always know the address of the routine to call, so it's not actually a message (except in HATEOAS, in which you first need to learn the next address from last API call). Closest analogy is the message queue (e.g. ESB) like Active MQ or Rabbit MQ (and the whole JMS tech), in which you do actually send a message and infrastructure does actually figure out who will receive and process it.
- specialist 10y ago
  HTTP(S) is the opposite of RPC (meaning: message-based). Both SOAP and XML-RPC tried to remedy that.
  - ivan_gammel 10y ago
    How exactly it is opposite?
    - specialist 10y ago
      Difference between document (message-passing) and RPC styles: http://stackoverflow.com/questions/9062475/what-is-the-difference-between-document-style-and-rpc-style-communication http://stackoverflow.com/questions/9062475/what-is-the-diffe... Replace SOAP with HTTP, since SOAP is just an ill-advised, unnecessary, redundant obfuscation layer on top of HTTP, and so contrast still applies.
kmiroslav 10y ago
I was talking about programming languages. Obviously, message passing is alive and well for network protocols.
pacala 10y ago
Message passing implies one way broadcast. Think GOTO. HTTP is a request / reply protocol, i.e. a function call. Map / Reduce is an implementation device for SQL-like collection-based processing, modern Map / Reduce systems [Google's Flume / Dataflow] offer directly the collection API, using Map / Reduce as an implementation detail. FRP is a device for adding a collection API on top of streams of events. Collection APIs are conceptually function calls over collections [duh]. Just because your compiler uses GOTO / messaging behind the scenes to implement function calls, it doesn't follow that GOTO / messaging is the right API level for designing applications. We know this since 1968.
- protomyth 10y ago
  > Message passing implies one way broadcast. Can you explain that since its contrary to my experience. PDO and normal Objective-C methods had a return and are not one way.
  - ivan_gammel 10y ago
    In modern enterprise programming message is very different concept (probably more widespread, if we'll look at popularity of Java and .Net, compared to Objective-C), which is not related to OOP. It's a pattern of integration, in which systems exchange with messages through a message broker, that abstracts them from each other. By their nature such messages are asynchronous and unidirectional.
    - infinite8s 10y ago
      That was also the original model of messaging in Smalltalk (well, without the necessity of a broker).
      - coldtea 10y ago
        Smalltalk receivers returned values to the senders of the message. Plus, they were synchronous. So, while indeed still messaging, I'm not sure about the similarity to message queues/brokers in modern enterprise, where, as the parent said "By their nature such messages are asynchronous and unidirectional".

ivan_gammel 10y ago

HTTP is closer to RPC. You always know the address of the routine to call, so it's not actually a message (except in HATEOAS, in which you first need to learn the next address from last API call). Closest analogy is the message queue (e.g. ESB) like Active MQ or Rabbit MQ (and the whole JMS tech), in which you do actually send a message and infrastructure does actually figure out who will receive and process it.

specialist 10y ago
HTTP(S) is the opposite of RPC (meaning: message-based). Both SOAP and XML-RPC tried to remedy that.
- ivan_gammel 10y ago
  How exactly it is opposite?
  - specialist 10y ago
    Difference between document (message-passing) and RPC styles: http://stackoverflow.com/questions/9062475/what-is-the-difference-between-document-style-and-rpc-style-communication http://stackoverflow.com/questions/9062475/what-is-the-diffe... Replace SOAP with HTTP, since SOAP is just an ill-advised, unnecessary, redundant obfuscation layer on top of HTTP, and so contrast still applies.

kmiroslav 10y ago

I was talking about programming languages. Obviously, message passing is alive and well for network protocols.

pacala 10y ago

Message passing implies one way broadcast. Think GOTO. HTTP is a request / reply protocol, i.e. a function call. Map / Reduce is an implementation device for SQL-like collection-based processing, modern Map / Reduce systems [Google's Flume / Dataflow] offer directly the collection API, using Map / Reduce as an implementation detail. FRP is a device for adding a collection API on top of streams of events. Collection APIs are conceptually function calls over collections [duh]. Just because your compiler uses GOTO / messaging behind the scenes to implement function calls, it doesn't follow that GOTO / messaging is the right API level for designing applications. We know this since 1968.

protomyth 10y ago
> Message passing implies one way broadcast. Can you explain that since its contrary to my experience. PDO and normal Objective-C methods had a return and are not one way.
- ivan_gammel 10y ago
  In modern enterprise programming message is very different concept (probably more widespread, if we'll look at popularity of Java and .Net, compared to Objective-C), which is not related to OOP. It's a pattern of integration, in which systems exchange with messages through a message broker, that abstracts them from each other. By their nature such messages are asynchronous and unidirectional.
  - infinite8s 10y ago
    That was also the original model of messaging in Smalltalk (well, without the necessity of a broker).
    - coldtea 10y ago
      Smalltalk receivers returned values to the senders of the message. Plus, they were synchronous. So, while indeed still messaging, I'm not sure about the similarity to message queues/brokers in modern enterprise, where, as the parent said "By their nature such messages are asynchronous and unidirectional".