Design, Implementation & Assembly
The development of a Jsasb application has three phases: design, implementation, and assembly.

The first phase is design. The people who work in this phase are called designers or architects if the application is very large and distributed. The main task is to design the specifications of the actors and events and to ensure that these actors and events can be assembled to form a Jsasb application that meets the requirements.

Each event has a specification that includes tag (either topic or service) names, formats, and meanings (both physical and logical.) Tag names should be unique since actors use them to identify and interpret events. The specification may also include a description of the protocol when events are stateful and the order has special meaning.

Each actor has a specification to specify what kind of events it will send and/or receive, and what it's supposed to do with them.

Besides the Jsasb EDP design described above, the Java OOP design for events and actors also need to be done in this phase.

Compared with object-oriented methodology, event-driven analysis and design is a less studied field. Ted Faison's new book Event-Based Programming: Taking Events to the Limit is a very good resource that describes the nature of event-driven programming, design tools and patterns. Jsasb will continuously collect EDP related books and articles for EDP designers. Please check the Jsasb homepage (see https://jsasb.dev.java.net/) and blog (see http://weblogs.java.net/blog/rexyoung/) from time to time for updates.

The second phase is implementation. People who work in this phase are called developers. The main task is to implement event classes and actor classes according to the specification. This is a pure development of Java OOP. It uses the Jsasb API though.

The third phase is assembly. People who work in this phase are called assemblers. The main task is to load actors in a container and route events according to the design specification.

The Jsasb API consists of seven classes in the org.jsasb package. The actor class is designed to be the root class of all actor classes. The reason is that the actor class defines basic behaviors like how an actor class interacts with container. Here are the guidelines for developing actor classes.

Declare interested topics and services
  •   An actor has four possible roles: 1) Publisher for sending events; 2) Subscriber for receiving events; 3) Requester for sending requests; and 4) Implementer for responding requests.
  •   An actor class should declare roles by calling the protected constructor with specific parameters.
 •   A none-empty upstreamTopics indicates that the actor is a subscriber.
  •   A none-empty downstreamTopics indicates that the actor is a publisher.
  •   A none-empty supportedServices indicates that the actor is an implementer.
  •   A none-empty requiredServices indicates that the actor is a requester.
  •   The declared topics and services will be used later for an eligibility check by the container when routing events.

Send events
  •   All events are sent to the container first then dispatched to user-specified actors by the container.
  •   getJsasbContext().getSystemPublisher().publish(topic, event);
  •   There is no need to check null pointer.

Send requests
  •   All requests are sent to the container first then dispatched to user-specified actors by the container.
  •   reply = getJsasbContext().getSystemRequester().perform(service, request);
  •   There is no need to check null pointer.

Receive events
  •   The actor class already implements the TopicSubscriber interface with an empty method. An actor class only need to override the onEvent(topic, event) method with its own implementation.
  •   This method is expected to be the main body of the actor.

Receive requests
  •   The actor class already implements the ServiceImplementer interface with an empty method. An actor class only has to override the onRequest(service, request) method with its own implementation.
  •   This method is also expected to be the main body of the actor.

Run/stop actors
  •   When an actor is instantiated in a container, it's not running by default for two reasons. One is that it takes time for an assembler to provide configuration to the actor via the console. The other is that an actor may be stopped and removed from the container by an assembler at any time. These require actors to have both running and non-running states for resource allocation and release.
  •   The implementations of start() and stop() methods must let calling threads return as soon as possible because onEvent() and onRequest() methods are expected to be the main body of the actor, not the start() and stop() methods, which are just controls. This is why it's called event-driven programming.

Configure actors
  •   There are two scenarios. One case is to provide the first time configuration to a newly created actor. The other case is that the configuration is retrieved from the actor for backup when the container shuts down. The configuration is passed in for restoration when the container restarted.
  •   Plus additional conditions that the running status may be different between the backup and restoration. All combinations should take into account.
  •   Implementations of getState() and setState() methods must handle all scenarios.

Multithreading
  •   A container is a single thread environment except onEvent() and onRequest() methods. There only a single thread is calling a method on an actor through the entire container. This design is to simplify implementations of both the container and actor classes.
  •   Besides the single thread, the container has a thread pool for giving an individual actor its own runtime environment.
  •   The calling thread of onEvent() method is one of the threads in the pool. It's not from the event publisher.
  •   The calling thread of the onRequest() method isn't from the pool but directly from the calling actor, or a local thread on its behavior when the calling actor is a remote actor.
  •   Because Jsasb is based on Java OOP, it can't completely eliminate multithreading. However, the scope is limited. Actually designers have another option to reduce multithreading conflicts by designing more, but smaller, actors.

As assembly is a brand new phase to Java developers, here are some screenshots of a GUI console that demonstrate the process of gluing actors to a Jsasb application without coding (see Figure 1, Figure 2, Figure 3 and Figure 4).

Jsasb Future Development
Jsasb future development takes place on two directions. The first is to develop distributed containers that are not implemented in the current version. The other is to develop specifications to standardize consoles and containers to a certain degree. Once these specifications are established, consoles and containers may be provided by independent vendors even using different languages. For example, an actor written in Java in a Java container may exchange events with another actor written in C++ in a C++ container. A standardized console also brings advantages to Jsasb designers who can focus on application analysis and design without knowing too many details of consoles and containers. (See Source Listings)

References
  •   Peter Van Roy and Seif Haridi. Concepts, Techniques, and Models of Computer Programming. The MIT Press, 2004.
  •   Ted Faison. Event-Based Programming: Taking Events to the Limit. Apress, 2006.