The concept of TAF (transparent application failover) can be used to do some interesting things such as high availability without any HA technology.

Imagine you have a schema manually duplicated to two databases, db1 and db2, for reporting purpose. There's no HA technology connecting db1 and db2, i.e. no data guard, replication or anything. You want your users's database connection to be able to fail over when one database fails. You can create a service salesum in both databases and create a TNS entry for the client like this

salesum =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = host1)(PORT = 1521))
      (ADDRESS = (PROTOCOL = TCP)(HOST = host2)(PORT = 1521))
      (FAILOVER=YES)
    )
    (CONNECT_DATA =
      (service_name = salesum)
      (FAILOVER_MODE=(TYPE=select)(METHOD=basic))
    )
  )

Note the entry is TAF-like and we're not using RAC at all. But if service salesum on host1 fails, the client connects to the one on host2. For more on this, see [note1].

In fact, even if you only have one schema in one database on one host, the above concept has its merit. The TNS entry is the same as above except that the two ADDRESS lines are the same

salesum =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = host1)(PORT = 1521))
      (ADDRESS = (PROTOCOL = TCP)(HOST = host1)(PORT = 1521))
      (FAILOVER=YES)
    )
    (CONNECT_DATA =
      (service_name = salesum)
      (FAILOVER_MODE=(TYPE=select)(METHOD=basic))
    )
  )

Now, if your network is disconnected and then restored, you run a query and you get ORA-12571: TNS:packet writer failure. Repeat the query and you see the result nicely! No need to explicitly re-connect to the database.

_________________
[note1]
Duplicating a schema for resilience is not limited to reporting. Suppose you have a schema petstore in database orcl. Your customer asks you to create another "database" that completely mirrors this database to protect against database failure (including datafile corruption), and the new "database" must be completely synchronized with orcl and be open for read and write. Performance is not a concern even for the future. You think advanced replication, streams replication or logical standby is way too much for this small, simple, database. What do you do?

Find another database, or create one if it's really needed, and import petstore from orcl into this database. Modify the midtier application so that every insert/delete/update is done against both databases (using two separate TNS connection strings). Let's call this approach poor man's replication, or rather poor developer's replication. But for all queries, you only need to connect to one database. Although you can just pick one of the two, it's better to create a "TAF"-like TNS connection so queries have the failover capability.