• WebFlow Applet
  • Module Manager
  • Connection Manager
  • Session Manager
  • Internal Communication
  • I/O modules in the prototype
  • User part
  • WebFlow Applet Image

    WebFlow Applet

    The WebFlow Applet is the front end of the system. Through it, the users can request new modules to be initialized, their ports connected, the whole application ran, and finally destroyed. The WebFlow Applet is a client of the Session Manager. Every action requested by the user, that involves the creation, running or destruction of a module, as well as the creation of a connection, is sent to the Session Manager. The only activities performed locally inside the Web Flow Applet are activities connected with the graphical presentation of the system - moving modules around, drawing of the modules and connections, interpreting the user mouse clicks, etc.

    Module Manager

    The Module Manager is the simplest of the three system components. It is in charge of running modules on demand.

    When creation of a module is requested, that request is sent to the Module Manager residing on the particular machine on which the module should be run. The Module Manager creates a separate thread for the module (thus enabling concurrent execution of multiple modules), and loads the module code, making the module ready for execution.

    Upon receipt of a request for running a module, the Module Manager simply calls a special run method which each module is required to have. That method is written by the module developer, and implements the module's functionality.

    Upon receipt of a request for destroying a module, the Module Manager first stops the thread of execution of the module, then calls the special destroy method. The destroy method is again written by the module developer, and it performs all the clean-up operations deemed necessary by the developer.

    Notice that the Module Manager acts only as a server. Its client is the Session Manager which makes the requests for module creation, running, and destruction. Also notice that the Module Manager has no notion of a session built into it. It can support any number of modules, and requests coming from any number of Session Managers.

    Connection Manager

    The Connection Manager is in charge of establishing connections between modules. To be precise, it establishes connections between individual ports, regardless of the module on which they reside, and regardless of the machine on which the module is run.

    As each module is initialized, its ports register with the Connection Manager. This enables the Connection Manager to later connect the port to another port.

    Since the ports register with the Connection Manager by directly invoking a method from it, a copy of the Connection Manager must reside on the same host with each Module Manager. In our view, this additional requirement is justified, since the Connection Manager and Module Manager are one logical entity. The only reason why they are implemented as two separate servers is to make their implementation and maintainance easier.

    When connection of two ports is requested, the Connection Manager that has the first port registered with it is contacted, and a request to connect the two ports is made. Notice that this is a symmetrical process, and the Connection Manager that has the second port registered with it could have been contacted.

    The figure below shows the steps involved in making the connection between the two ports. The two ports whose connection is requested are denoted port 1 and port 2 in the figure. The more general case is the one in which each port is registered in a separate Connection Manager. Of course, the two ports may be registered at the same Connection Manager, in which case the whole connection procedure is much simplifies, as steps two and three are not needed. In the figure, Port 1 is registered at Connection Manager 1, and Port 2 is registered at Connection Manager 2.

    In the first step, a request to connect Port 1 is received. This request is generally sent by the Session Manager, but there are no restrictions for having a module send such requests to a Connection Manager.

    The Connection Manager checks for local errors, such as: does such port exist, is the port already connected, etc. If no errors are present, an Establish request is sent to Connection Manager 2. Connection Manager 2 then checks whether Port 2 is available (i.e. exists and is not connected yet), and if so, sends an OK message back to the first Connection Manager. In the same time, Connection Manager 2 sends a Connection to the first Connection Manager. In the prototype, this Connection is a socket connection being sent to a server socket in the first Connection Manager. After the connection has been established, the first Connection Manager sends a reply signifying the success of the operation. If the operation had failed at any point, the last message would have been a failure message, with a description of why the operation failed.

    Notice that the Connection Manager is not just a simple server. The complex protocol shown in the figure shows the Connection Manager in two roles: as a server to both the Session Manager and another Connection Manager, but also as a client to another Connection Manager.

    As with the Module Manager, the Connection Manager has no notion of a session built into it. It can support any number of ports, and requests coming from any number of Session Managers.

    d) Session Manager

    The Session Manager is the part of the system in charge of accepting user commands from the front end, and executing them by sending requests to the rest of the system. The user requests that the Session Manager honors are creating a new module, connecting two ports, running the application, and destroying the application.

    Since the Session Manager and the front end generally reside on separate machines, the Session Manager keeps a representation of the application that the user is building, much like the representation stored in the front end. The difference between these two representations is that the Session Manager needs to worry about the machines on which each of the modules has been started, while the front end worries about the position of the representation of the module on the screen.

    The Session Manager acts like a server for the front end, but uses the services of the Module and Connection Managers. All of the requests received from the user are satisfied by a series of requests to the Module and Connection Managers which store the actual modules and ports.

    In the WebFlow prototype, the Session Manager can only work with one user at a time. In other words, there is only one session active at any one point in time.

    Internal communication in the prototype

    In the WebFlow prototype there are two types of communications provided:

    via URL
    via socket connections

    The former - via URL - is used when a component's socket address is unknown. This feature allows the whole system to be accessed over the web. However, the current implementation of the URL addressing scheme does not provide for a way to send whole objects as parameters (except for the inelegant way of making a whole language to express the types and values of parameters expected). The socket connection scheme, however, provides for a very elegant way of sending any object, provided it knows how to serialize itself, over the socket. This is very useful, as all the requests and replies can easily be expressed as objects whose internal state holds the type and parameters of the request or reply.

    At the time being, each of the three servers in the WebFlow system listen to both the URL and socket connections at all times. Although the internal requests and replies for creation, running, and destruction of modules, as well as connecting ports all go through the socket connection, the URL communication is far from being useless. It not only provides the socket address of the server, it is also the perfect place to perform system-wide operations, such as give usage statistics, reset the system, add new resources to the system, etc.

    I/O modules in the prototype

    The previous discussion took for granted the input and output modules in an application. However, current web browser restrictions make input and output modules a non-trivial task.

    Since the front end can be invoked from any arbitrary machine connected to the web, the input and output modules should be able to receive their input and send their output to the same, arbitrarily chosen, machine. The only way of doing so in the current state of affairs is to provide applets that will be able to receive user inputs, and show the application's outputs. However, the applets suffer from the restriction that they cannot communicate with any host - only the host from which they arrived.

    Therefore, the input/output modules are made in two parts: a WebFlow part - that works under the WebFlow model, and an applet part - that provides I/O capabilities. Upon initialization, the I/O modules inform the system that they require an applet to be spawned for them. That request is forwarded all the way to the system's front end, which has the capability to open a new frame on the screen, and load an HTML page in it. That HTML page can contain a the invocation of the I/O module's applet.

    However, there is a further complication. The only way known to us of dynamically spawning a frame and loading it with a HTML document, is to have a URL towards the page. Since all the servers involved in the system are servlets, they have the capability of receiving a URL request, dynamically creating an HTML page, and returning it as a reply to the request.

    The current solution to this problem is to make the Session Manager double as a server for creating HTML documents with the I/O module's applets. However, this solution necessitates that the I/O modules reside on the same host as the Session Manager, which is clearly in violation of the distributed spirit of WebFlow.

    The long term solution is the existence of a separate manager - a Viewer Manager.

    User part

    The user either writes or reuses the applications in the system. All the applications in the WebFlow system consist of modules who talk among themselves through ports. Ports can both send and receive one particular type of data items. Ports for sending and receiving primitive data types (such as integers, strings and the like) are provided with the prototype. It is fairly simple to add new types of ports to the implementation.

    Modules are ran in separate threads by the system. The user is not prohibited from starting yet more threads in the modules, but is responsible for disposal of the same threads upon its termination. The system provides facilities for initializing, running, and destroying the modules. Upon initialization, the modules initialize the ports they will be using, and provide the system with a description of itself, mainly in terms of the ports it uses. The system provides means for disseminating this information.