From the client's perspective, the IDL definition of a bank's interface, together with some documentation, fully determines its functionality. This means that in writing the client we need only rely on the information in the documented IDL to be able to interact with a bank object. Knowing the IDL description, we can implement the client before our bank object implementation is available.
The Bank-Protocol library, which was produced by the IDL compiler, Scepter, merely specifies the protocol for interacting with CORBA objects satisfying the interfaces in the IDL file bank.idl. The client-side implementation of this protocol resides the Bank-Stubs library. Any application that wants to act as a client with respect to some CORBA object matching an interface in the bank.idl file should use the Bank-Stubs library.
The Bank-Stubs library defines the following concrete classes:
BankingDemo/<account-reference> BankingDemo/<checkingAccount-reference> BankingDemo/<bank-reference>
These classes subclass the following abstract classes:
BankingDemo/<account> BankingDemo/<checkingAccount> BankingDemo/<bank>
The class BankingDemo/<checkingAccount-reference> is defined to inherit from BankingDemo/<account-reference>, matching the inheritance relationship in the IDL. Instances of these classes act as proxies for CORBA objects running on the server.
The Bank-Stubs library also defines a concrete stub method, specialized on the appropriate proxy class, for each protocol function stemming from an IDL attribute or operation. When the client applies the generic function to a particular target proxy, the stub method communicates with the ORB to invoke the corresponding operation on the actual target object in the server. If the request succeeds, the stub method returns the result to the client. If the request fails, raising a CORBA user or system exception, the stub method raises the corresponding Dylan condition of the appropriate class. This condition can then be handled by the client code using standard Dylan constructs.