FMP Tutorial: Messenger API
We introduced a new visual element (see figure 1) that can be used to represent active objects in your mind and/or on a diagram along with other visual elements of classes, objects, human actors, etc. They are very appropriate for expressing high-level designs or conceptual models.
Figure 1: Visual Element Representing Active Object
Figure 2: FMP Architecture
When you finally get into coding phase, you need switch your context to be in the FMP architecture (see figure 2). In order to invoke a service (aka port) on an active object, a user program needs to get a couple of things in hand.
- The user program needs to know a messenger object that contains the active object to be invoked (see note 1).
- The user program needs to know text-based names of the active object and the service to be invoked (see note 2).
- The user program needs to know parameter signature from somewhere other than source code (see note 3).
Note 1: A user program may obtain a messenger object by creating a new one or accessing one that is created somewhere else.
Note 2: In general, a user program specifies names of target active object and service. There is publishMessage () method in the Messenger API that requires the user program to provide names of the sending active object and service.
Note 3: FMP uses a text-based name to identify a service so that it is almost impossible to perform static type checking. For example, the user program uses a variable to store a name, thus a compiler has no way to know what the value would be at compiling time. No need to say the variable may change its value over time.
With above information in hand, the user program is ready to invoke the target active object through Messenger API on the messenger object. The API contains a number of methods each of which is able to invoke a service on an active object. These API methods are designed to fit user programs variant styles. For example, callService () is mainly for user programs running in sequential; and sendMessage () is for event-driven architecture, etc. We will introduce each of them in detail in the future tutorials.
Generally speaking, Messenger API is decoupled from active object. All API methods will end up with placing a new request in the inbox of the target active object. The target active object cannot tell for a placed request which method has been used. And in the future, Messenger API could be expanded with new methods to support new user program styles.