Generic Collection Interfaces

Safe & Portable Relational Database Interfaces

Safe & Portable TCP Interface

Safe & Portable Web Server Construction Toolkit

The Tools

ShowThread

ShowHeap and ShowNew

Stubgen

Stablegen

Cbind

An Open Infrastructure For Building Distributed Applications

Network IO Framework

The network io framework currently supports the tcp/ip protocol. However, adding support for protocols such as IPX/SPX or NetBEUI is relatively straightforward.

Here is a short example for sending a "Hello World" message to the process listening on the IP port dest_port:

VAR
  conn := TCP.Connect(dest_port);
  msgWr := ConnMsgRW.NewWr(conn);
BEGIN
  Wr.PutText(msgWr, "Hello World\n");
  Wr.Flush(msgWr);
END

Network Objects

Network Objects allows a Modula-3 object to be handed to another process in such a way that the process receiving the object can operate on it as if it were local. The holder of a remote object can freely invoke operations on that object just as if it had created that object locally. Further, it can pass the object to other processes. Thus, the Network Objects system allows the development of not just simple client-server applications, but more general multi-tiered distributed applications.

In CORBA terms, Network Objects provides the equivalent of ORB functionality; however, Network Objects is much more tightly integrated with the Modula-3 language. Most CORBA implementations are layered on top of C++, a language which was not designed to host distributed programming. In contrast, the Modula-3 language designers made the easy and natural design of distributed applications one of their primary goals. Modula-3 programs are much easier to make distributed than their C++ counterparts.

The current implementation of Network Objects is built on the TCP framework described above. In addition, it is designed to make adoption to specialized network protocols easy. For instance, it is relatively straightforward to add a new transport for Network Objects for CORBA IIOP or DCE RPC.

Putting It All Together: A Network Objects Example

INTERFACE Bank;
IMPORT NetObj;

TYPE
  T = NetObj.T OBJECT METHODS
    deposit (acct: AcctNum; amount: REAL) RAISES {BadAmount};
    withdraw (acct: AcctNum; amount: REAL) RAISES {BadAmount, InsufficientFunds};
    get_balance (acct: AcctNum): REAL;
  END;
  
TYPE
  AcctNum = [1..100];
  
EXCEPTION
  BadAmount;
  InsufficientFunds;
  
END Bank.

The Bank interface defines an object type Bank.T which inherits from the type NetObj.T; inheriting from NetObj.T makes an object eligible for distribution. The Bank.T type defines three operations: deposit, withdraw, and get_balance. The deposit and withdraw operations will raise BadAmount if the amount is less than zero. The withdraw operation also raises the InsufficientFunds exception if there isn't sufficient funds in the account to meet the requested withdrawal amount.

Continuing our example, we show how the bank server can be implemented. To save space, we show only the implementation of the deposit operation; the other operations can be implemented in a similar fashion.

MODULE Server;
IMPORT Bank, NetObj;


TYPE
  BankImpl = Bank.T OBJECT
    accounts : ARRAY Bank.AcctNum OF Account;
    lock     : MUTEX;
  OVERRIDES
      deposit     := Deposit;
      withdraw    := Withdraw; (* not included *)
      get_balance := Balance; (* not included *)
  END;


  Account = RECORD
      balance : REAL := 0.0;
  END;


PROCEDURE Deposit (self: BankImpl; acct: Bank.AcctNum; amount: REAL)
                   RAISES {Bank.BadAmount} =


  BEGIN
    IF amount < 0.0 THEN RAISE Bank.BadAmount; END;
    LOCK self.lock DO
      WITH bal = self.accounts[acct].balance DO
        bal := bal + amount;
      END;
    END;
  END Deposit;


(* The implementations of "Withdraw" and "Balance" would go here. *)


VAR bank := NEW (BankImpl, lock := NEW(MUTEX));
BEGIN
  NetObj.Export ("LastNationalBank", bank);


(* Here would might start other threads to audit or manage the bank.

Finally, the program must wait until the bank is closed. *)
END Server.

The above example demonstrates that coding a simple server in Reactor is indeed simple. The code resembles quite closely the code that you would write if you were building a non-distributed version of the Bank interface. The primary difference is the need to make the bank object visible via the NetObj.Export operation. This operation binds a name ("LastNationalBank") in the global namespace to a local object (bank), allowing clients running on other machines to access it. The Network Objects run-time creates threads to handle incoming connections as they are needed. When incoming calls arrive for the object named "LastNationalBank", they are dispatched to our implementation.

Next we outline a simple client of the bank. This client receives the object representing the "LastNationalBank", deposits some money in an account via the deposit command and prints the final balance. Despite its simplicity, this client will work properly regardless of whether the bank is located in the same room, down the street, or across the county.

MODULE Client;
IMPORT Bank, NetObj;
IMPORT IO, Fmt;


CONST
  MyBank : TEXT = "LastNationalBank";
  MyAcct : Bank.AcctNum = 99;


VAR
  bank: Bank.T;
BEGIN
  TRY
    bank := NetObj.Import (MyBank);
    bank.deposit (MyAcct, 125.00);
    WITH balance = bank.get_balance(MyAcct) DO
      IO.Put ("My account balance is " & Fmt.Real(balance) &"\n");
    END;
  EXCEPT
  | NetObj.Error => IO.Put ("A network error occured\n");
  | Bank.BadAmount => <* ASSERT FALSE *>
  (* BadAmount will not be raised for positive deposits. *)
  END;
END Client.

A Slightly More Realistic Example

INTERFACE Bank;
IMPORT NetObj;


TYPE
  T = NetObj.T OBJECT METHODS
    findAccount (acct: AcctNum): Account;
  END;


TYPE
  Account = NetObj.T OBJECT METHODS
    deposit (amount: REAL) RAISES {BadAmount};
    withdraw (amount: REAL) RAISES {BadAmount, InsufficientFunds};
    get_balance (): REAL;
  END;


TYPE
  AcctNum = [1..100];


EXCEPTION
  BadAmount;
  InsufficientFunds;


END Bank.

We now sketch the implementation of a bank server that manages both banks and accounts:

MODULE Server;


IMPORT Bank, NetObj;


TYPE
    BankImpl = Bank.T OBJECT
    accounts : ARRAY Bank.AcctNum OF Account;
  OVERRIDES
    findAccount := FindAccount;
  END;


TYPE
  Account = Bank.Account OBJECT
    lock    : MUTEX;
    balance : REAL := 0.0;
  OVERRIDES
    deposit := Deposit;
    withdraw := Withdraw; (* not included *)
    get_balance := Balance; (* not included *)
  END;


PROCEDURE FindAccount (self: BankImpl; acct: Bank.AcctNum): Bank.Account =
  BEGIN
    RETURN self.accounts[acct];
  END FindAccount;


PROCEDURE Deposit (self: Account; amount: REAL) RAISES {Bank.BadAmount} =
(* Deposit the money,
   making sure to serialize access with others trying to operate on this account.*)
  BEGIN
    IF amount < 0.0 THEN RAISE Bank.BadAmount; END;
      LOCK self.lock DO
        self.balance := self.balance + amount;
      END;
  END Deposit;


(* The implementations of "Withdraw" and "Balance" would go here. *)


PROCEDURE NewBank () : BankImpl =
  VAR b := NEW (BankImpl);
  BEGIN
    FOR i := FIRST (b.accounts) TO LAST (b.accounts) DO
      b.accounts[i] := NEW (Account, lock := NEW (MUTEX));
    END;
    RETURN b;
  END NewBank;


BEGIN
  NetObj.Export ("LastNationalBank", NewBank ());


  (* Here would might start other threads to audit or manage the bank.
     Finally, the program must wait until the bank is closed. *)
END Server.

In this version, the client gets an account object (of type Bank.Account) from the bank and then makes deposits, withdrawals, and checks balances on that account object. When the client finishes using that account object, it does not need to clean up after itself, unlike what would be required in most client/server or corba systems today. Instead, the garbage collector on the client will determine that the account object is no longer being used. Then, it will inform the garbage collector at the server that the account object has one less client. When the garbage collector on the server determines there are no more clients using this account object, it will reclaim the storage used by the Network Objects run-time.

Distributed garbage collection is key in creating robust client/server programs. Manually managing memory within a single program is hard enough; manual memory management across clients and servers when hardware failures are possible is nearly impossible. Without distributed garbage collection, the application designer would need to invent and follow conventions that allow a client to inform the server when it finishes using the account object. What would happen if the client crashed unexpectedly or failed to make that call? Slowly, the server would accumulate more and more objects that it couldn't free; eventually it would crash. By providing a robust distributed garbage collection protocol, Reactor dramatically eases the development of long-running client-server and distributed applications. Distributed garbage collection also simplifies the development of the middle layers in multi-tiered systems.

Future Directions

Network OLE/Distributed COM

Microsoft IIS & Netscape Communications Server

Advanced Distributed Services: Distributed Transactions

Many Other Libraries

The Reactor Architecture: Reactorıs robust core is the basis for its tight integration with industry standards on the front-end and the back-end, making Reactor into an ideal choice for serious systems architects and programmers. Full size image, 35K.

Conclusions