Due to their many practical applications, strong formalisms and distinct vocabulary some authors (see [Strom, 1986,McReynolds et al., 1999], for example) defend that Process Networks and related models can be seen as a sign of a new and underlying paradigm: the Process paradigm. Although the process paradigm is usually seen as a vehicle for the implementation of applications involving parallel or distributed computing it has also been formulated with a broader scope.
In the process paradigm, each process is a center of activity that holds internal state. The program executing that process is the only entity that can modify that state. Other processes may access that process indirectly through a message channel. A message channel is formed by connecting plugs named "input ports" to sockets "output ports"
All variables (and ports) are typed. A process communicates with another issuing a call on two operands: an output port and a parameter list or call-message. The call message is transmitted to a queue associated with the input port connected with the output port. The caller then waits for the call-message to be returned. The process owning the input port issues a receive operation to dequeue the message, it interprets the message and performs some action that may involve modifying the local state and the call message and finally issues a return operation to return the call-message.
Each process is a serial computation which can only schedule one activity at a time, and will only respond to a message after explicitly dequeuing it - this is in contrast to the object-oriented paradigm, in which a method is immediately invoked when a message is sent. There are no shared variables, global state or global time. Processes do not have type, only their ports. Each process may support different interfaces and give different services to different "users". In the process paradigm, a type determines only the interface, not the internal structure. Processes are active and explicitly schedule the receipt of messages.
According to [Strom, 1986] the more important practical difference is that OO puts emphasis in global structure and the process paradigm in that all data is local. In the process-oriented world there is no superuser, that is no-one has to be in charge of managing the overall system.
Furthermore, and related especially to dataflow models, some authors talk about actor-oriented programming as another new and different paradigm (see [Hewit, 1977,Agha, 1986,Liu et al., 2004] or [Hylands et al., 2003]).
In the actor-oriented paradigm, components called actors execute and communicate between them in a model. Actors, like objects, have a well-defined interface that abstracts internal state and behavior and restricts how an actor interacts with its environment. This interface includes ports that represent points of communication and parameters that are used to configure the operation of the actor. Often but not always parameters are part of a priori configuration and do not change upon execution.
In actor-oriented design communication channels are very important. Instead of transferring control by method call like in the OO paradigm, actors interact by sending messages through channels. Actors interact only with channels, not with other actors.
An actor is an encapsulation of parameterized actions performed on input data to produce output data. Actors may be stateless or stateful. Input and output data is communicated through well defined ports. Ports and parameters are the interface of an actor. A port does not follow the call-return semantics of OO.
It is our opinion that neither process orientation nor actor orientation represent a paradigm beyond object orientation but rather a particular subset or instance. As already highlighted in section 1.2.3 object orientation was born from some ideas that were closely related to process orientation and this is documented in the seminal works by Nygaard. Nevertheless, object-orientation grew way beyond these initial ideas becoming valid for describing any kind of software system.