We can now design the interface of a bank 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 its name attribute.
The operation openAccount is declared to take a CORBA string and return an account . Because account is defined as an interface, and not a type, this means that the operation will return a reference to an account 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 qualification raises ( duplicateAccount ) specifies that openAccount can raise the user-defined exception duplicateAccount , instead of returning an account. (The exception duplicateAccount has no fields.)
The operation openCheckingAccount is similar to openAccount , but takes an additional argument, limit , which represents the account's overdraft limit.
The operation retrieveAccount looks up the account (or checking account), if any, associated with a customer name, returning an object reference of interface account . The operation may raise the exception nonExistentAccount 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.
Because checkingAccount inherits from account , a checkingAccount object may be used wherever an account object is expected, whether as the actual argument, or the result, of an operation. For instance, this means that we can use closeAccount to close checking accounts as well as accounts; and to use retrieveAccount to fetch checking accounts as well as accounts.
The complete IDL definition for the bank can be found in file bank.idl .