4.1 Designing the IDL

4.1.3 IDL for the bank interface

We can now design the interface of abank object. The intention is that a bank associates customer names with accounts, with each name identifying at most one account. A client is able to open accounts for new customers and to retrieve both accounts and checking accounts for existing customers from the persistent store. If the client attempts to open a second account under the same name, the bank should refuse the request by raising an exception. Similarly, if the client attempts to retrieve an account for an unknown customer, the bank should reject the request by raising an exception.

The IDL definition of the bank interface captures some of these requirements:

// in module BankingDemo 
interface bank { 

  readonly attribute string name; 

  exception duplicateAccount{}; 

  account openAccount (in string name) 
    raises (duplicateAccount); 

  checkingAccount openCheckingAccount(in string name, 
                                      in long limit) 
    raises (duplicateAccount); 

  exception nonExistentAccount{}; 

  account retrieveAccount(in string name) 
    raises (nonExistentAccount); 

  void closeAccount (in account account); 
};

The name of a bank is recorded in itsname attribute.

The operationopenAccount is declared to take a CORBAstring and return anaccount. Becauseaccount is defined as an interface, and not a type, this means that the operation will return a reference to anaccount object. This illustrates an important distinction between ordinary values and objects in CORBA: while members of basic and constructed types are passed by value, objects are passed by reference.

The qualificationraises (duplicateAccount) specifies thatopenAccount can raise the user-defined exceptionduplicateAccount, instead of returning an account. (The exceptionduplicateAccount has no fields.)

The operationopenCheckingAccount is similar toopenAccount, but takes an additional argument,limit, which represents the account's overdraft limit.

The operationretrieveAccount looks up the account (or checking account), if any, associated with a customer name, returning an object reference of interfaceaccount. The operation may raise the exceptionnonExistentAccount to indicate that there is no account under the supplied name.

The last operation,closeAccount, closes an account by deleting it from the bank's records.

BecausecheckingAccount inherits fromaccount, acheckingAccount object may be used wherever anaccount object is expected, whether as the actual argument, or the result, of an operation. For instance, this means that we can usecloseAccount to close checking accounts as well as accounts; and to useretrieveAccount to fetch checking accounts as well as accounts.

The complete IDL definition for the bank can be found in filebank.idl.