From the client's perspective, the IDL definition of a bank's interface fully determines its functionality. This means that we need only rely on the information in the IDL to interact with a bank object. In particular, knowing the IDL description, we can implement the client before an implementation of a bank object is available.
The bank fasl file, produced by the IDL compiler
bank.idl, and
This fasl should be used by any application that wants to act as a client with respect to some CORBA object matching an interface in the bank.idl file. The bank fasl file defines classes BankingDemo:account, BankingDemo:checkingAccount, and BankingDemo:bank.
The class BankingDemo:checkingAccount is defined to inherit from BankingDemo:account, matching the inheritance relationship in the IDL. Instances of these classes act as proxies for CORBA objects on the server.
The bank fasl also defines a 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 Common Lisp condition of the appropriate class. This condition can then be handled by the client code using standard Common Lisp constructs.
Developing Component Software with CORBA - 14 Feb 2015