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
.