A programming paradigm is a fundamental style of programming that defines the basic programming units to represent problems and how these units work together to solve problems. This field is continuously developing to face up-to-date challenges.

The first challenge to having a general-purpose programming paradigm is answered by structured programming that has data structures and statements as basic programming units. The statements are organized in the form of sequencing, selection, and iteration to satisfy any computable problems. This model matches how a programmer abstracts problems.

The execution of structured programs is considered sequential since one statement gets to run only when the previous one finished in spite of their form of selection or iteration. This is exactly how a CPU executes a program.

As structured programming meets both the expectations of the programmer and the machine, it becomes a well-accepted programming paradigm that applies to everything from assembly to high-level languages.

Object-Oriented Programming
The second challenge comes when a computer is widely used. Structured programming encounters difficulties in building and maintaining large and complex systems. Object-oriented programming addresses this challenge by strongly emphasizing modularity using encapsulation and reusability using inheritance and polymorphism.

OOP may be built on top of structured programming. Data is encapsulated in the objects. Statements are organized as methods and encapsulated in the objects as well. Objects as basic programming units may repeatedly use the inheritance and composition of other objects to represent large and complex problems.

However, the execution of OO programs that run statements one-by-one across methods and objects is still sequential. OOP also introduces some dynamic features to make OO programs flexible at runtime. For example, polymorphism lets programs choose a proper method in a class hierarchy to run, and objects of a class may come from its subclasses. But these dynamic features don't change the sequential execution. They just add some extra statements of selection so proper methods and objects get selected to execute from the CPU's point-of-view.

The recent challenge has been the demand for application flexibility, concurrency, and distribution as the Internet becomes the basic platform for many business applications. Application flexibility refers to the ability of an application to change its functions and structure to respond to business and organization changes with minimal effort in a short period of time. At the same time, applications are also facing a massive number of requests from the Internet environment like never before. Concurrency and distribution are the right technologies for the situation.

OOP programmers may use inheritance and polymorphism to give alternative implementations to an existing application. This technique can provide application flexibility for function changes to a certain degree, but none for workflow changes. As for concurrency and distribution, OOP lacks definition and it's left to particular OOP languages.

Java
Java is almost a pure OOP language and is very popular. It has more support for application flexibility outside of OOP using enterprise technologies like ESB and SOA.

Java has built-in threads for concurrency. A Java program allows multiple executions at the same time. Each of them is sequential though. When executions access a single object, Java uses a lock mechanism to prevent conflicts. This is called a shared-state concurrent model. We can imagine the difficulties of writing such an application and the possibility of deadlocking when the numbers of shared objects and sequential executions grow. This is very likely to happen in today's Internet-based business environments, e.g., user interactive applications (GUI, RIA) and large scalable server applications.

Java uses RMI to connect remote objects. RMI enables a programmer to code distributed applications without significant differences between handling local and remote objects. This way RMI builds a sequential execution across processes or machines. That means the calling node must wait until the called node finishes, which is less efficient for distribution.

The Actor Model
Actor model is the first message-passing concurrent model that consists of independent actors that interact by sending messages to each other asynchronously. The nature of the actor model makes it the best candidate for application flexibility, concurrency, and distribution. Actors can be replaced to reflect function changes, and messages can be re-routed to reflect workflow changes. The actor model even supports hot-swapping these changes. Actors run independently and share nothing but the meaning of the messages. This means maximum concurrency. Asynchronous communication and location transparency are also key to the efficiency of distributed applications.

The actor model focuses on high-end features like concurrency and distribution. It lacks the basic programming units that are necessary to represent complex data and problems. And using asynchronous message passing exclusively is sometimes almost impossible to solve some problems. These might be the reasons we cannot find a pure actor model language in the real world.

Jsasb
Jsasb, pronounced J-Saab, is an open source project (see https://jsasb.dev.java.net/). Jsasb doesn't take an approach that is either a pure actor model language or a new language following the actor model like Erlang. Jsasb combines the best parts of Java OOP and the actor model and, as a result, adds the concurrency and distribution features of the actor model, called event-driven programming (EDP), to Java. A message is called an event in Jsasb. This approach immediately brings Jsasb all existing Java developers and gives Jsasb applications compatibility with Java applications.

Two techniques are the key to the combination of Java OOP and Jsasb EDP. One is the actor class that's provided as a core part of Jsasb and sits between Java OOP and Jsasb EDP. On the one hand, the actor class is the root class of all user actor classes. It's like the object class in Java. All actor classes are pure Java classes implemented by Java OOP. On the other hand, actors, namely instances of actor classes, can only run in a container and interact with the container as the Jsasb EDP defines. The other technique is the Jsasb container that collects and dispatches events among actors according to the user's instructions. This ensures unawareness among actors and independence of individual actors. Containers can work together to provide location independence to actors too.

Since Jsasb EDP isn't a pure actor model, the structure and behavior of the actor and many others are different. Here are the outlines.

Actor
  •   Actor is the only programming unit of Jsasb EDP.
  •   An actor is an instance of an actor class in a container. An actor class is a subclass of the actor class. All of these classes are pure Java classes.
  •   An actor can send and receive events. But an actor is unaware of other actors.

Event
  •   The actor sends and receives asynchronous events. Jsasb also allows synchronous events, usually called requests since a request asks for a reply.
  •   An event, including request and reply, is a Java object that should be serializable if it's expected to travel across JVM.
  •   Every event has a string tag called topic. The topic is used to identify the specification of the event. The specification refers to the physical and logical formats and the meanings of the event.
  •   Every request also has a string tag called service that's the equivalent of topic.

Container
  •   A container is an instance of the container class. It's the only place where actor classes are instantiated and actors are running.
  •   A container can be operated either programmatically or via a GUI console. This allows the co-existence and communications of Java OOP and Jsasb EDP applications in one JVM.
  •   When the actor sends events, it sends them to the container. The container then dispatches events to other proper actors according to the user's event-routing instructions.
  •   Containers may work together to pass events from one container to another across the JVM and computer.

Assembly
  •   Assembly is the process in which users use the console to tell the container to add, remove, start, stop, and configure actors. It also tells container instructions how to route events from one actor to another in a container or across containers.
  •   Assembly is not a one-time process, but can be done anytime the container is running.