Editing Message passing (section)

==Distributed objects==
{{Main|Distributed object}}
Message-passing systems use either distributed or local objects. With distributed objects the sender and receiver may be on different computers, running different operating systems, using different programming languages, etc. In this case the bus layer takes care of details about converting data from one system to another, sending and receiving data across the network, etc. The [[Remote Procedure Call]] (RPC) protocol in [[Unix]] was an early example of this. With this type of message passing it is not a requirement that sender nor receiver use object-oriented programming. Procedural language systems can be wrapped and treated as large grained objects capable of sending and receiving messages.<ref>{{cite book|last=Orfali|first=Robert|title=The Essential Client/Server Survival Guide|year=1996|publisher=Wiley Computer Publishing|location=New York|isbn=0-471-15325-7|pages=[https://archive.org/details/essentialclients00orfa/page/375 375–397]|url=https://archive.org/details/essentialclients00orfa/page/375}}</ref>

Examples of systems that support distributed objects are: [[Emerald (programming language)|Emerald]], [[ONC RPC]], [[CORBA]], [[Java RMI]], [[Distributed Component Object Model|DCOM]], [[SOAP (protocol)|SOAP]], [[.NET Remoting]], [[CTOS]], [[QNX|QNX Neutrino RTOS]], [[OpenBinder]] and [[D-Bus]]. Distributed object systems have been called "shared nothing" systems because the message passing abstraction hides underlying state changes that may be used in the implementation of sending messages.

{{unreferenced section|date=February 2015}}
{{Expert needed|computer science|section|reason=Section mixes between local and distributed message-passing, eg. to imply that ''local'' message passing cannot be performed with pass-by-reference and has to include entire objects, which is actually only partially correct for ''distributed'' systems|date=April 2015}}

Distributed, or asynchronous, message-passing has additional overhead compared to calling a procedure. In message-passing, arguments must be copied to the new message. Some arguments can contain megabytes of data, all of which must be copied and transmitted to the receiving object.

Traditional [[Calling convention|procedure call]]s differ from message-passing in terms of memory usage, [[Bit rate|transfer time]] and locality. Arguments are passed to the receiver typically by [[general-purpose register]]s requiring no additional storage nor transfer time, or in a [[Parameter (computer science)|parameter]] list containing the arguments' addresses (a few bits). Address-passing is not possible for distributed systems since the systems use separate address spaces.

Web [[web browsing|browsers]] and [[web server]]s are examples of processes that communicate by message-passing. A [[URL]] is an example of referencing a resource without exposing process internals.

A [[subroutine]] call or [[method (computer programming)|method]] invocation will not exit until the invoked computation has terminated. Asynchronous message-passing, by contrast, can result in a response arriving a significant time after the request message was sent.

A message-handler will, in general, process messages from more than one sender. This means its state can change for reasons unrelated to the behavior of a single sender or client process. This is in contrast to the typical behavior of an object upon which methods are being invoked: the latter is expected to remain in the same state between method invocations. In other words, the message-handler behaves analogously to a [[volatile variable|volatile object]].