JavaFBP

Java Implementation of FlowBasedProgramming

For more information, see:

• http://www.jpaulmorrison.com/fbp/jsyntax.htm

• FbpApi (2nd section)

• http://www.jpaulmorrison.com/fbp

The latest version of this (http://www.jpaulmorrison.com/fbp/JavaFBP-2.4.jar) is available on my web site, and also on SourceForge. Its features are shown below:

The following is definitely the major change in version 2.1, and means that every "verb" (component) must be enhanced with metadata, as well as subnets. However, this information is now used (as of version 2.3) to provide descriptive information to the Diagramming tool (DrawFBP), and for possible future checks.

• Input and output port names will be coded on components using Java 5.x "attribute" notation. This is metadata that can be used to do analysis of networks without having to actually execute the components involved. Here is an example of the attributes for the "Collate" component:

    @OutPort("OUT") 
    @InPorts({
      @InPort("CTLFIELDS"), 
      @InPort(value = "IN", arrayPort = true)
      })  

    public class Collate extends Component {

• Note that, as Java metadata does not (as far as I know) support multiple entries with the same name, we have provided the additional metadata terms @InPorts and @OutPorts. When only one is needed (as for @Outport in this example) the "plural" term can be omitted.

• Input ports do not necessarily have to be connected, even though attributes are specified for them; output ports, however, must be.

• MustRun is also specified as metadata, rather than as an interface, as it was in version 1.5.3.

Other changes:

• Dropping a packet is now done by a method of class Component (as opposed to a method of class Packet), e.g.:

      drop(p);

where "p" is the packet.

• We are adding a "long wait" state to components, specifying a timeout value in seconds. This is coded as follows:

      double _timeout = 2;   // 2 secs

          ....

      longWaitStart(_timeout);    
                                           
    //   activity taking time goes here

      longWaitEnd(); 

• Typically, the timeout value is given a default value in the code, and overridden (if desired) by an IIP.

• While the component in question is executing the activity taking time, its state will be set to "long wait". If one or more components are in "long wait" state while all other components are suspended or not started, this situation is not treated as a deadlock. However, if one of the components exceeds its timeout value, an error will be reported (Complain).

• I have become persuaded by DavidBennett that a components' responsibility for an IP is discharged once it issues a Send - see UndeliveredMail. This suggests that Send should not return a "success/fail" indicator, but should simply crash the program (FlowError.complain) if a data packet cannot be delivered - either because the receiving input port is closed, or no connection was specified. This means that the network designer should connect any output ports sending unneeded data to a Discard or Log component.

• However, as of version 2.3, there is now a boolean isConnected() method, which can be used on an output port to find out if that port is connected to a downstream component, so a component can be written so it optionally outputs packets to a particular port. This suggestion is due to DuncanChild.

• DavidBennett has suggested a simpler "connect" notation:

    connect("componentA.portname", "componentB.portname");

• This assumes that the component names have been associated with a type in an earlier statement of the form

    component("xxxxx", yyyyy.class));

• This convention will be supported in addition to the older convention.

• If one of the ports involved is an array port, the port array name and index can be entered as "portname[index]" where "index" is an absolute number - either in a "connect" or an "initialize" statement.

• Again, this convention will be supported in addition to the older convention.

• The input ports to which IIPs are connected should be closed by the component code after the receive has been done - this ensures that, if fed by an upstream component rather than an IIP, only one IP can be sent successfully. Once the port is closed, an additional send will cause the sending component to abort. When making a component available for general use, all IIP ports should be tested using a data stream connection, as well as an IIP.

• Unlike the 1.5.3 and earlier versions of JavaFBP, an IIP will only be received once per invocation, rather than once per activation - additional receives just return null.

For a complete description of the API, see http://www.jpaulmorrison.com/fbp/jsyntax.htm .