Persistent POA Example----------------------This example demonstrates usage of a persistent POA. Objects in a persistentPOA can by definition outlive the process they're created in. A mechanism isprovided to save the objects' state to persistent storage (for example, afile on disk) and to restore the information when the object is reactivated.The implementation of Bank and Account hasn't changed much compared withthe previous example (Account-2). We have added a "name" parameter toBank::create() so that each Account has a Name that we will use as afile name to store the Account on disk lateron. We have also added aBank::shutdown() operation to demonstrate transparent reactivation ofthe servant by micod.More changes have been done in AccountManager, the ServantManager imple-mentation. Now, when asked to incarnate a new servant, the Manager seesif the object's state from a previous activation can be read from disk.Upon etherealize, the object's balance is written to disk.Unfortunately, all we get in our implementation of etherealize() is aPortableServer::Servant value. We know that it actually points to anAccount_impl object, but we cannot directly call any of Account_impl'smethods to save the state, and we also cannot narrow the pointer to anAccount_impl (save with advanced C++ features). We must therefore keepa map mapping Servant values to Account implementations.The server process uses a total of three POAs: first, the Root POA.Second, the persistent "Accounts" POA. Third, the "Bank" POA. TheBank must also be registered in a persistent POA so that the Objectreference kept by the client does not become invalid between serveractivations. We could of course register the Bank in the "Accounts"POA, but then we'd have to distinguish between the Bank and all theAccounts in our ServantManager. There's no penalty for using multiplePOAs -- the concept has been introduced to make our life easier afterall.Note that the Bank, though registered in the "Bank" POA, creates allits Account references in the "Account" POA.The "account" shell script first starts the POA Daemon (which is containedin micod) and adds a "poa" entry to the Implementation Repository. The firstinstance is started up manually using `imr activate', so that the server hasthe chance to write the Bank's IOR into a file. Lateron, the server is restar-ted by the MICO Daemon whenever the server is not running.