Message passing paradigm

Message passing in computer science is a form of communication used in parallel

computing, object-oriented programming, and interprocess communication. In this model, processes
or objects can send and receive messages (comprising zero or more bytes, complex data structures, or even segments of code) to other processes. By waiting for messages, processes can also synchronize.

Overview
Message passing is the paradigm of communication where messages are sent from a sender to one or more recipients. Forms of messages include (remote) method invocation, signals, and data packets. When designing a message passing system several choices are made:
y y y y

Whether messages are transferred reliably Whether messages are guaranteed to be delivered in order Whether messages are passed one-to-one, one-to-many (unicasting or multicast), or many-toone (client server). Whether communication is synchronous or asynchronous.

Prominent theoretical foundations of concurrent computation, such as the Actor model and the process calculi are based on message passing. Implementations of concurrent systems that use message passing can either have message passing as an integral part of the language, or as a series of library calls from the language. Examples of the former include many distributed object systems. Examples of the latter include Microkernel operating systems pass messages between one kernel and one or more server blocks, and the Message Passing Interface used in highperformance computing.

Message passing systems and models:

Distributed object and remote method invocation systems like ONC RPC, Corba, Java RMI, DCOM, SOAP, .NET Remoting, CTOS, QNX Neutrino RTOS, OpenBinder, D-Bus and similar are message passing systems. Message passing 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. Message passing model based programming languages typically define messaging as the (usually asynchronous) sending (usually by copy) of a data item to a communication endpoint (Actor, process, thread, socket, etc.). Such messaging is used in Web Services by SOAP. This concept is the higher-level version of a datagram except that messages can be larger than a packet and can optionally be made reliable, durable, secure, and/or transacted.

Messages are also commonly used in the same sense as a means of interprocess communication; the other common technique being streams or pipes, in which data are sent as a sequence of elementary data items instead (the higher-level version of a virtual circuit).

Synchronous versus asynchronous message passing:

Synchronous message passing systems require the sender and receiver to wait for each other to transfer the message. That is, the sender will not continue until the receiver has received the message. Synchronous communication has two advantages. The first advantage is that reasoning about the program can be simplified in that there is a synchronisation point between sender and receiver on message transfer. The second advantage is that no buffering is required. The message can always be stored on the receiving side, because the sender will not continue until the receiver is ready. Asynchronous message passing systems deliver a message from sender to receiver, without waiting for the receiver to be ready. The advantage of asynchronous communication is that the sender and receiver can overlap their computation because they do not wait for each other. Synchronous communication can be built on top of asynchronous communication by ensuring that the sender always wait for an acknowledgement message from the receiver before continuing. The buffer required in asynchronous communication can cause problems when it is full. A decision has to be made whether to block the sender or whether to discard future messages. If the sender is blocked, it may lead to an unexpected deadlock. If messages are dropped, then communication is no longer reliable.

Message passing versus calling:

Message passing should be contrasted with the alternative communication method for passing information between programs the Call. In a traditional Call, arguments are passed to the "callee" (the receiver) typically by one or more general purpose registers or in a parameter list containing the addresses of each of the arguments. This form of communication differs from message passing in at least three crucial areas:
y y y

total memory usage transfer time locality

In message passing, each of the arguments has to have sufficient available extra memory for copying the existing argument into a portion of the new message. This applies irrespective of the size of the original arguments so if one of the arguments is (say) an HTML string of 31,000 octets describing a web page (similar to the size of this article), it has to be copied in its entirety (and perhaps even transmitted) to the receiving program (if not a local program).

By contrast, for the call method, only an address of say 4 or 8 bytes needs to be passed for each argument and may even be passed in a general purpose register requiring zero additional storage and zero "transfer time". This of course is not possible for distributed systems since an (absolute) address in the callers address space is normally meaningless to the remote program (however, a relative address might in fact be usable if the callee had an exact copy of, at least some of, the callers memory in advance). Web browsers and web servers are examples of processes that communicate by message passing. A URL is an example of a way of referencing resources that does depend on exposing the internals of a process. A subroutine call or 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 behaviour of a single sender or client process. This is in contrast to the typical behaviour 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 object).

Message passing and locks:

Message passing can be used as a way of controlling access to resources in a concurrent or asynchronous system. One of the main alternatives is mutual exclusion or locking. Examples of resources include shared memory, a disk file or region thereof, a database table or set of rows. In locking, a resource is essentially shared, and processes wishing to access it (or a sector of it) must first obtain a lock. Once the lock is acquired, other processes are blocked out, ensuring that corruption from simultaneous writes does not occur. The lock is then released. With the message-passing solution, it is assumed that the resource is not exposed, and all changes to it are made by an associated process, so that the resource is encapsulated. Processes wishing to access the resource send a request message to the handler. If the resource (or subsection) is available, the handler makes the requested change as an atomic event, that is conflicting requests are not acted on until the first request has been completed. If the resource is not available, the request is generally queued. The sending programme may or may not wait until the request has been completed.

Examples of message passing style:

y y y y y

Actor model implementation Amorphous computing Flow-based programming SOAP (protocol)

Actor model implementation:

Cosmic Cube:
The Cosmic Cube was developed by Chuck Seitz et al. at Caltech providing architectural support for Actor systems. A significant difference between the Cosmic Cube and most other parallel processors is that this multiple instruction multiple-data machine uses message passing instead of shared variables for communication between concurrent processes. This computational model is reflected in the hardware structure and operating system, and is also the explicit message passing communication seen by the programmer. According to Seitz [1985]: It was a premise of the Cosmic Cube experiment that the internode communication should scale well to very large numbers of nodes. A direct network like the hypercube satisfies this requirement, with respect to both the aggregate bandwidth achieved across the many concurrent communication channels and the feasibility of the implementation. The hypercube is actually a distributed variant of an indirect logarithmic switching network like the Omega or banyan networks: the kind that might be used in sharedstorage organizations. With the hypercube, however, communication paths traverse different numbers of channels and so exhibit different latencies. It is possible, therefore, to take advantage of communication locality in placing processes in nodes.

J Machine
The JMachine was developed by Bill Dally et al. at MIT providing architectural support suitable for Actors. This included the following:
y y y

Asynchronous messaging A uniform space of Actor addresses to which messages could be sent concurrently regardless of whether the recipient Actor was local or nonlocal A form of Actor pipelining (see Actor model)

Concurrent Smalltalk (which can be modeled using Actors) was developed to program the J Machine.

Prototype Actor Programming Language:

Hewitt [2006] presented a prototype Actor programming language in the sense that it directly expresses important aspects of the behavior of Actors. Messages are expressed in XML using the notation <tag>[<element>1 <element>] for <<tag>> <element>1 <element>n </<tag>>

The semantics of the programming language are defined by defining each program construct as an Actor with its own behavior. Execution is modeled by having Eval messages passed among program constructs during execution.

Environment Actors
Each Eval message has the address of an Actor that acts as an environment with the bindings of program identifiers. Environment Actors are immutable, i.e., they do not change. When Request[Bind[identifier value] customer] is received by an Actor Environment, a new environment Actor is created such that when the new environment Actor receives Request[Lookup[identifier] customer] then if identifier is the same as identifier send customer Returned[value], else send Environment Request[Lookup[identifier] customer]. The above builds on an Actor EmptyEnvironment which when it receives Request[Lookup[identifier] customer], sends customer Thrown[NotFound[identifier] ]. When it receives a Bind request EmptyEnvironment acts like Environment above.

Expressions:
The prototype programming language has expressions of the following kinds: <identifier> When Request[Eval[environment] customer] is received, send environment Request[Lookup[<identifier>] customer] send <recipient> <communication> When Request[Eval[environment] customer] is received, send <recipient> Request[Eval[environment] evalCustomer1] where evalCustomer1 is a new Actor such that when evalCustomer1 receives the communication Returned[theRecipient], then send <communication> Request[Eval[environment] evalCustomer2] where evalCustomer2 is a new actor such that when evalCustomer2 receives the communication Returned[theCommunication], then send theRecipient theCommunication. <recipient>.<message> When Request[Eval[environment] customer] is received, send <recipient> Request[Eval[environment] evalCustomer1] such that when evalCustomer1 receives the communication Returned[theRecipient], then send <message> Request[Eval[environment] evalCustomer1] such that when evalCustomer2 receives the communication Returned[theMessage], then send theRecipient Request[theMessage customer] receiver <pattern>i <expression>i

When Request[Eval[environment] customer] is received, send customer a new actor theReceiver such that when theReceiver receives a communication com, then create a new bindingCustomer and send environment Request[Bind[<pattern>i com] bindingCustomer] and
1 if bindingCustomer receives Returned[environment ]. send <expression>i Request[Eval[environment ] ] 2 otherwise if bindingCustomer receives Thrown[ ],.try <pattern>i+1

behavior <pattern>i <expression>i When Request[Eval[environment] customer] is received, send customer a new actor theReceiver such that when theReceiver receives Request[message customer], then create a new bindingCustomer and send environment Request[bind[<pattern>i message] customer] and
1 if bindingCustomer receives Returned[environment ], send <expression>i Request[Eval[environment ] customer ] 2 otherwise if bindingCustomer receives Thrown[ ],.try <pattern>i+1

{<expression>1, <expression>2} When Request[Eval[environment] customer] is received, send <expression>1 Request[Eval[environment] ] and concurrently send <expression>2 Request[Eval[environment] ] customer]. let <identifier> = <expression>value in <expression>body When message[Eval[environment] customer] is received, then create a new evalCustomer and send <expression>value Request[Eval[environment] evalCustomer1. When evalCustomer receives Returned[theValue], create a new bindingCustomer and send environment Request[bind[<identifier> theValue] bindingCustomer] When bindingCustomer receives Returned[environment], send <expression>body Request[Eval[environment] customer] serializer <expression> When Request[Eval[environment] customer] is received, then send customer Returned[theSerializer] where theSerializer is a new actor such that communications sent to theSerializer are processed in FIFO order with a behavior Actor that is initially <expression>.Eval[environment] and When communication com is received by theSerializer, then send the behavior Actor Request[com customer] where customer is a new actor such that when customer receives Returned[theNextBehavior] then theNextBehavior is used as the behavior Actor for the next communication received by theSerializer.

Example program:
An example program for a simple storage cell that can contain any Actor address is as follows: Cell
receiver Request[Create[initial] customer] send customer Returned[serializer ReadWrite(initial)]

The above program which creates a storage cell makes use of the behavior ReadWrite which is defined as follows: ReadWrite(contents)
behavior Request[read[] customer] {send customer Returned[contents], ReadWrite(contents)} Request[write[x] customer] {send customer Returned[], ReadWrite(x)}

Note that the above behavior is pipelined, i.e., the behavior might still be processing a previous read or write message while it is processing a subsequent read or write message.. For example the following expression creates a cell x with initial contents 5 and then concurrently writes to it with the values 7 and 9. let x = Cell.Create[5] in {x.write[7], x.write[9], x.read[]} The value of the above expression is 5, 7 or 9.

Amorphous computing:
Amorphous computing refers to computational systems that use very large numbers of identical, parallel processors each having limited computational ability and local interactions. The term Amorphous Computing was coined at MIT in 1996 in a paper entitled "Amorphous Computing Manifesto" by Abelson, Knight, Sussman, et al. Examples of naturally occurring amorphous computations can be found in many fields, such as: developmental biology (the development of multicellular organisms from a single cell), molecular biology (the organization of sub-cellular compartments and intra-cell signaling),

neural networks, and chemical engineering (non-equilibrium systems) to name a few. The study of amorphous computation is hardware agnostic -- it is not concerned with the physical substrate (biological, electronic, nanotech, etc.) but rather with the characterization of amorphous algorithms as abstractions with the goal of both understanding existing natural examples and engineering novel systems. Amorphous computers tend to have many of the following properties:
y y y y y y y y

Implemented by redundant, potentially faulty, massively parallel devices. Devices having limited memory and computational abilities. Devices being asynchronous. Devices having no a priori knowledge of their location. Devices communicating only locally. Exhibit emergent or self-organizational behavior (patterns or states larger than an individual device). Fault-tolerant, especially to the occasional malformed device or state perturbation.

Algorithms, tools, and patterns:

y

"Fickian communication". Devices communicate by generating messages which diffuse through the medium in which the devices dwell. Message strength will follow the inverse square law as described by Fick's law of diffusion. Examples of such communication are common in biological and chemical systems. "Link diffusive communication". Devices communicate by propagating messages down links wired from device to device. Unlike "Fickian communication", there is not necessarily a diffusive medium in which the devices dwell and thus the spatial dimension is irrelevant and Fick's Law is not applicable. Examples are found in Internet routing algorithms such as the Diffusing Update Algorithm. Most algorithms described in the amorphous computing literature assume this kind of communication. "Wave Propagation". (Ref 1) A device emits a message with an encoded hop-count. Devices which have not seen the message previously, increment the hop count, and rebroadcast. A wave propagates through the medium and the hop-count across the medium will effectively encode a distance gradient from the source. "Random ID". Each device gives itself a random id, the random space being sufficiently large to preclude duplicates. "Growing-point program". (Coore). Processes that move among devices according to 'tropism' (movement of an organism due to external stimuli). "Wave coordinates". (from the DARPA PPT slide, to be referenced). To be written.

"Neighborhood query". (Nagpal) A device samples the state of its neighbors by either a push or pull mechanism. "Peer-pressure". Each device maintains a state and communicates this state to its neighbors. Each device uses some voting scheme to determine whether or not to change state to its neighbor's state. The algorithm partitions space according to the initial distributions and is an example of a clustering algorithm. (Illustration, citation needed) "Self maintaining line". (Lauren, Clement). A gradient is created from one end-point on a plane covered with devices via Link Diffusive Communication. Each device is aware of its value in the gradient and the id of its neighbor that is closer to the origin of the gradient. The opposite end-point detects the gradient and informs its closer neighbor that it is part of a line. This propagates up the gradient forming a line which is robust against disruptions in the field. (Illustration needed). "Club Formation". (Coore ,Nagpal, Weiss). Local clusters of processors elect a leader to serve as a local communication hub.
"Coordinate formation" Multiple gradients are formed and used to form a coordinate system via triangulation.

y y y

Flow-based programming:
In computer science, flow-based programming (FBP) is a programming paradigm that defines applications as networks of "black box" processes, which exchange data across predefined connections by message passing, where the connections are specified externally to the processes. These black box processes can be reconnected endlessly to form different applications without having to be changed internally. FBP is thus naturally component-oriented.

Introduction:
The FBP development approach views an application not as a single, sequential, process, which starts at a point in time, and then does one thing at a time until it is finished, but as a network of asynchronous processes communicating by means of streams of structured data chunks, called "information packets" (IPs). In this view, the focus is on the application data and the transformations applied to it to produce the desired outputs. The network is defined externally to the processes, as a list of connections which is interpreted by a piece of software, usually called the "scheduler".
The processes communicate by means of fixed-capacity connections. A connection is attached to a process by means of a port, which has a name agreed upon between the process code and the network definition. More than one process can execute the same piece of code. At any point in time, a given IP can only be "owned" by a single process, or be in transit between two processes. Ports may either be simple, or array-type, as used e.g. for the input port of the Collate component described below. It is the combination of ports with asynchronous processes that allows many long-running primitive functions of data processing, such as Sort, Merge, Summarize, etc., to be supported in the form of software black boxes. Because FBP processes can continue executing as long they have data to work on and somewhere to put their output, FBP applications generally run in less elapsed time than conventional programs, and make optimal use of all the processors on a machine, with no special programming required to achieve this. The network definition is usually diagrammatic, and is converted into a connection list in some lower-level language or notation. FBP is thus a visual programming language at this level. More complex network definitions have a hierarchical structure, being built up from subnets with "sticky" connections. FBP has much in common with the Linda[2] language in that it is, in Gelernter and Carriero's terminology, a "coordination language"[3]: it is essentially language-independent. Indeed, given a scheduler written in a sufficiently low-level language, components written in different languages can be linked together in a single network. FBP thus lends itself to the concept of domainspecific languages or "mini-languages". FBP exhibits "data coupling", described in the article on coupling as the loosest type of coupling between components. The concept of loose coupling is in turn related to that of Service-oriented architectures, and FBP fits a number of the criteria for such an architecture, albeit at a more finegrained level than most examples of this architecture. FBP promotes high-level, functional style of specifications that simplify reasoning about system behavior. An example of this is the distributed data flow model for constructively specifying and analyzing the semantics of distributed multi-party protocols.

Concepts: The following diagram shows the major entities of an FBP diagram (apart from
the Information Packets). Such a diagram can be converted directly into a list of connections, which can then be executed by an appropriate engine (software or hardware).

Simple FBP diagram A, B and C are processes executing code components. O1, O2, and the two INs are ports connecting the connections M and N to their respective processes. It is permitted for processes B and C to be executing the same code, so each process must have its own set of working storage, control blocks, etc. Whether or not they do share code, B and C are free to use the same port names, as port names only have meaning within the components referencing them (and at the network level, of course). M and N are what are often referred to as "bounded buffers", and have a fixed capacity in terms of the number of IPs that they can hold at any point in time. The concept of ports is what allows the same component to be used at more than one place in the network. In combination with a parametrization capability, called Initial Information Packets (IIPs), ports provide FBP with a component reuse capability, making FBP a component-based architecture. FBP thus exhibits what Nate Edwards of IBM Research has termed configurable modularity. Information Packets or IPs are allocated in what might be called "IP space" (just as Linda's tuples are allocated in "tuple space"), and have a well-defined lifetime until they are disposed of and their space is reclaimed - in FBP this must be an explicit action on the part of an owning process. IPs traveling across a given connection (actually it is their "handles" that travel) constitute a "stream", which is generated and consumed asynchronously - this concept thus has similarities to the lazy cons concept described in the 1976 article by Friedman and Wise.[17] IPs are usually structured chunks of data - some IPs, however, may not contain any real data, but are used simply as signals. An example of this is "bracket IPs", which can be used to group data IPs into sequential patterns within a stream, called "substreams". Substreams may in turn be nested. IPs may also be chained together to form "IP trees", which travel through the network as single objects.

The system of connections and processes described above can be "ramified" to any size. During the development of an application, monitoring processes may be added between pairs of processes, processes may be "exploded" to subnets, or simulations of processes may be replaced by the real process logic. FBP therefore lends itself to rapid prototyping. This is really an assembly line image of data processing: the IPs travelling through a network of processes may be thought of as widgets travelling from station to station in an assembly line. "Machines" may easily be reconnected, taken off line for repair, replaced, and so on. Oddly enough, this image is very similar to that of unit record equipment that was used to process data before the days of computers, except that decks of cards had to be hand-carried from one machine to another. Implementations of FBP may be non-preemptive or preemptive - the earlier implementations tended to be non-preemptive (mainframe and C language), whereas the latest Java implementation (see below) uses Java Thread class and is preemptive.

Examples: "Telegram Problem": FBP components often form complementary pairs. This example
uses two such pairs. The problem described seems very simple as described in words, but in fact is surprisingly hard to do using conventional procedural logic. The task, called the "Telegram Problem", originally described by Peter Naur, is to write a program which accepts lines of text and generates output lines of a different length, without splitting any of the words in the text (we assume no word is longer than the size of the output lines). In conventional logic, the programmer rapidly discovers that neither the input nor the output structures can be used to drive the call hierarchy of control flow. In FBP, on the other hand, the problem description itself suggests a solution:
y y

"words" are mentioned explicitly in the description of the problem, so it is reasonable for the designer to treat words as information packets (IPs) in FBP there is no single call hierarchy, so the programmer is not tempted to force a subpattern of the solution to be the top level.

Here is the most natural solution in FBP (there is no single "correct" solution in FBP, but this seems like a natural fit):

"Telegram problem"

As mentioned above, Initial Information Packets (IIPs) can be used to specify parametric information such as the desired output record length (required by the rightmost two components), or file names. IIPs are data chunks associated with a port in the network definition which become "normal" IPs when a "receive" is issued for the relevant port.

Batch update:
This type of program involves passing a file of "details" (changes, adds and deletes) against a "master file", and producing (at least) an updated master file, and one or more reports. Update programs are generally quite hard to code using synchronous, procedural code, as two (sometimes more) input streams have to be kept synchronized, even though there may be masters without corresponding details, or vice versa.

Update In FBP, a reusable component (Collate), based on the unit record idea of a Collator, makes writing this type of application much easier as Collate merges the two streams and inserts bracket IPs to indicate grouping levels, significantly simplifying the downstream logic. Suppose that one stream ("masters" in this case) consists of IPs with key values of 1, 2 and 3, and the second stream IPs ("details") have key values of 11, 12, 21, 31, 32, 33 and 41, where the first digit corresponds to the master key values. Using bracket characters to represent "bracket" IPs, the collated output stream will be as follows:
( m1 d11 d12 ) ( m2 d21 ) ( m3 d31 d32 d33 ) (d41)

As there was no master with a value of 4, the last group consists of a single detail (plus brackets). The structure of the above stream can be described succinctly using a BNF-like notation such as
{ ( [m] d* ) }*

Collate is a reusable black box which only needs to know where the control fields are in its incoming IPs (even this is not strictly necessary as transformer processes can be inserted upstream to place the control fields in standard locations), and can in fact be generalized to any number of input streams, and any depth of bracket nesting. Collate uses an array-type port for input, allowing a variable number of input streams.

Simple interactive network:

Schematic of general interactive application

In this general schematic, requests (transactions) coming from users enter the diagram at the upper left, and responses are returned at the lower left. The "back ends" (on the right side) communicate with systems at other sites, e.g. using CORBA, MQSeries, etc. The crossconnections represent requests that do not need to go to the back ends, or requests that have to cycle through the network more than once before being returned to the user. As different requests may use different back-ends, and may require differing amounts of time for the back-ends (if used) to process them, provision must be made to relate returned data to the appropriate requesting transactions, e.g. hash tables or caches. The above diagram is schematic in the sense that the final application may contain many more processes: processes may be inserted between other processes to manage caches, display connection traffic, monitor throughput, etc. Also the blocks in the diagram may represent "subnets" - small networks with one or more open connections.

Comparison with other paradigms and methodologies

Jackson Structured Programming

This methodology assumes that a program must be structured as a single procedural hierarchy of subroutines. Its starting point is to describe the application as a set of "main lines", based on the input and output data structures. One of these "main lines" is then chosen to drive the whole program, and the others are required to be "inverted" to turn them into subroutines (hence the name "Jackson inversion"). This sometimes results in what is called a "clash", requiring the program to be split into multiple programs or coroutines. When using FBP, this inversion process is not required, as every FBP component can be considered a separate "main line". FBP and JSP share the concept of treating a program (or some components) as a parser of an input stream. The FBP book contains a discussion of how the concept of push-down automata

may be used to design components (Chapter 23). It describes how a stack of controlling IPs may be used to control nested substreams in an FBP data stream.
Applicative programming

W.B. Ackerman defines an applicative language as one which does all of its processing by means of operators applied to values. The earliest known applicative language was LISP. An FBP component can be regarded as a function transforming its input stream(s) into its output stream(s). These functions are then combined to make more complex transformations, as shown here:

Two functions feeding one

If we label streams, as shown, with lower case letters, then the above diagram can be represented succinctly as follows:
c = G(F(a),F(b));

Just as in functional notation F can be used twice because it only works with values, and therefore has no side effects, in FBP two instances of a given component may be running concurrently with each other, and therefore FBP components must not have side-effects either. Functional notation could clearly be used to represent at least a part of an FBP network. The question then arises whether FBP components can themselves be expressed using functional notation. W.H. Burge showed how stream expressions can be developed using a recursive, applicative style of programming, but this work was in terms of (streams of) atomic values. In FBP, it is necessary to be able to describe and process structured data chunks (FBP IPs). In the FBP book, a notation is added for accessing the fields of an IP, and an operator, called the "miniconstructor" ( ), based on a similar function in the Vienna Definition Language, for creating an IP from a set of (perhaps modified) field values and identifiers. Furthermore, most applicative systems assume that all the data is available in memory at the same time, whereas FBP applications need to be able to process long-running streams of data while still using finite resources. Friedman and Wise suggested a way to do this by adding the

concept of "lazy cons" to Burge's work. This removed the requirement that both of the arguments of "cons" be available at the same instant of time. "Lazy cons" does not actually build a stream until both of its arguments are realized - before that it simply records a "promise" to do this. This allows a stream to be dynamically realized from the front, but with an unrealized back end. The end of the stream stays unrealized until the very end of the process, while the beginning is an ever-lengthening sequence of items. In the FBP book (Chapter 24), these ideas are combined to allow the expression of some quite complex component logic using applicative notation.

Many of the concepts in FBP seem to have been discovered independently in different systems over the years. Linda, mentioned above, is one such. Chapter 26 of the FBP book goes into some detail about similarities and differences, but probably the major difference is that, in Linda, data is accessed associatively, whereas in FBP, IPs arriving at a particular input port are retrieved sequentially. FBP's IPs are very similar to Linda's tuples. The difference between the two techniques is illustrated by the Linda "school of piranhas" load balancing technique - in FBP, this requires an extra "load balancer" component which routes requests to the component in a list which has the smallest number of IPs waiting to be processed. Clearly FBP and Linda are closely related, and one could easily be used to simulate the other.

Object-oriented programming:
An object in OOP can be described as a semi-autonomous unit comprising both information and behaviour. Objects communicate by means of "method calls", which are essentially subroutine calls, done indirectly via the class to which the receiving object belongs. The object's internal data can only be accessed by means of method calls, so this is a form of information hiding or "encapsulation". Encapsulation, however, predates OOP - David Parnas wrote one of the seminal articles on it in the early 70s [22] - and is a basic concept in computing. Encapsulation is the very essence of an FBP component, which may be thought of as a black box, performing some conversion of its input data into its output data. In FBP, part of the specification of a component is the data formats and stream structures that it can accept, and those it will generate. This constitutes a form of design by contract. In addition, the data in an IP can only be accessed directly by the currently owning process. Encapsulation can also be implemented at the network level, by having outer processes protect inner ones. A paper by C. Ellis and S. Gibbs distinguishes between active objects and passive objects.[23] Passive objects comprise information and behaviour, as stated above, but they cannot determine the timing of this behaviour. Active objects on the other hand can do this. In their article Ellis and Gibbs state that active objects have much more potential for the development of maintainable systems than do passive objects. An FBP application can be viewed as a combination of these two types of object, where FBP processes would correspond to active objects, while IPs would correspond to passive objects.

SOAP:
SOAP, originally defined as Simple Object Access Protocol, is a protocol specification for exchanging structured information in the implementation of Web Services in computer networks. It relies on Extensible Markup Language (XML) for its message format, and usually relies on other Application Layer protocols, most notably Remote Procedure Call (RPC) and Hypertext Transfer Protocol (HTTP), for message negotiation and transmission. SOAP can form the foundation layer of a web services protocol stack, providing a basic messaging framework upon which web services can be built. This XML based protocol consists of three parts: an envelope, which defines what is in the message and how to process it, a set of encoding rules for expressing instances of application-defined datatypes, and a convention for representing procedure calls and responses. As an example of how SOAP procedures can be used, a SOAP message could be sent to a webservice-enabled web site such as a real-estate price database, with the parameters needed for a search. The site would then return an XML-formatted document with the resulting data, e.g., prices, location, features. With the data being returned in a standardized machine-parseable format, it can then be integrated directly into a third-party web site or application. The SOAP architecture consists of several layers of specifications: for message format, Message Exchange Patterns (MEP), underlying transport protocol bindings, message processing models, and protocol extensibility. SOAP is the successor of XML-RPC, though it borrows its transport and interaction neutrality and the envelope/header/body from elsewhere (probably from WDDX).

Specification
The SOAP specification defines the messaging framework which consists of:
y y y y y

The SOAP processing model defining the rules for processing a SOAP message The SOAP extensibility model defining the concepts of SOAP features and SOAP modules The SOAP underlying protocol binding framework describing the rules for defining a binding to an underlying protocol that can be used for exchanging SOAP messages between SOAP nodes The SOAP message construct defining the structure of a SOAP message.

Processing model:
The SOAP processing model describes a distributed processing model, its participants, the SOAP nodes and how a SOAP receiver processes a SOAP message. The following SOAP nodes are defined:
y

SOAP sender

A SOAP node that transmits a SOAP message.

SOAP receiver

A SOAP node that accepts a SOAP message.

y

SOAP message path

The set of SOAP nodes through which a single SOAP message passes.
y

Initial SOAP sender (Originator)

The SOAP sender that originates a SOAP message at the starting point of a SOAP message path.
y

SOAP intermediary

A SOAP intermediary is both a SOAP receiver and a SOAP sender and is targetable from within a SOAP message. It processes the SOAP header blocks targeted at it and acts to forward a SOAP message towards an ultimate SOAP receiver.
y

Ultimate SOAP receiver

The SOAP receiver that is a final destination of a SOAP message. It is responsible for processing the contents of the SOAP body and any SOAP header blocks targeted at it. In some circumstances, a SOAP message might not reach an ultimate SOAP receiver, for example because of a problem at a SOAP intermediary. An ultimate SOAP receiver cannot also be a SOAP intermediary for the same SOAP message.

Message format:
XML was chosen as the standard message format because of its widespread use by major corporations and open source development efforts. Additionally, a wide variety of freely available tools significantly eases the transition to a SOAP-based implementation. The somewhat lengthy syntax of XML can be both a benefit and a drawback. While it promotes readability for humans, facilitates error detection, and avoids interoperability problems such as byte-order (Endianness), it can slow processing speed and can be cumbersome. For example, CORBA, GIOP, ICE, and DCOM use much shorter, binary message formats. On the other hand, hardware appliances are available to accelerate processing of XML messages.[3][4] Binary XML is also being explored as a means for streamlining the throughput requirements of XML.

Example message
POST /InStock HTTP/1.1 Host: www.example.org Content-Type: application/soap+xml; charset=utf-8 Content-Length: 299 SOAPAction: "http://www.w3.org/2003/05/soap-envelope" <?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">

<soap:Header> </soap:Header> <soap:Body> <m:GetStockPrice xmlns:m="http://www.example.org/stock"> <m:StockName>IBM</m:StockName> </m:GetStockPrice> </soap:Body> </soap:Envelope>

Advantages
y

SOAP is versatile enough to allow for the use of different transport protocols. The standard stacks use HTTP as a transport protocol, but other protocols such as JMS[5] and SMTP[6] are also usable. Since the SOAP model tunnels fine in the HTTP get/response model, it can tunnel easily over existing firewalls and proxies, without modifications to the SOAP protocol, and can use the existing infrastructure.

Disadvantages
y

Because of the verbose XML format, SOAP can be considerably slower than competing middleware technologies such as CORBA. This may not be an issue when only small messages are sent.[7] To improve performance for the special case of XML with embedded binary objects, the Message Transmission Optimization Mechanism was introduced. When relying on HTTP as a transport protocol and not using WS-Addressing or an ESB, the roles of the interacting parties are fixed. Only one party (the client) can use the services of the other. Developers must use polling instead of notification in these common cases.

Influences on other programming models

In the terminology of some object-oriented programming languages, a message is the single means to pass control to an object. If the object "responds" to the message, it has a method for that message. In pure object-oriented programming, message passing is performed exclusively through a dynamic dispatch strategy.[citation needed] Objects can send messages to other objects from within their method bodies. Message passing enables extreme late binding in systems. Sending the same message to an object twice will usually result in the object applying the method twice. Two messages are considered to be the same message type, if the name and the arguments of the message are identical. Some languages support the forwarding or delegation of method invocations from one object to another if the former has no method to handle the message, but "knows" another object that may have one. See also Inversion of Control. Alan Kay has argued that message passing is more important than objects in OOP, and that objects themselves are often over-emphasized. The live distributed objects programming model builds upon this observation; it uses the concept of a distributed data flow to characterize the behavior of a complex distributed system in terms of message patterns, using high-level, functional-style specifications .