A JDBC technology is an API (included in both J2SE and J2EE releases) that provides cross-DBMS connectivity to a wide range of SQL databases and access to other tabular datasources, such as spreadsheets or flat files.
With a JDBC technology-enabled driver, you can connect all corporate data even in a heterogeneous environment.
Two classes that can be used by a JDBC application to connect to a target data source:

• DriverManager: This fully implemented class connects an application to a data source, which is specified by a database URL.
  When this class first attempts to establish a connection, it automatically loads any JDBC 4.
  0 drivers found within the class path.
  Note that your application must manually load any JDBC drivers prior to version 4.
  0.
  
• DataSource: This interface is preferred over DriverManager because it allows details about the underlying data source to be transparent to your application.
  A DataSource object's properties are set so that it represents a particular data source.
  JDBC drivers.
  

These implementations are categorized as follows: Type 1, Type 2, Type 3 and Type 4.

• Type 1: Drivers that implement the JDBC API as a mapping to another data access API, such as ODBC (Open Database Connectivity).
  Drivers of this type are generally dependent on a native library, which limits their portability.
  The JDBC-ODBC Bridge is an example of a Type 1 driver.
  
• Type 2: Drivers that are written partly in the Java programming language and partly in native code.
  These drivers use a native client library specific to the data source to which they connect.
  Again, because of the native code, their portability is limited.
  Oracle's OCI (Oracle Call Interface) client-side driver is an example of a Type 2 driver.
  
• Type 3: Drivers that use a pure Java client and communicate with a middleware server using a database-independent protocol.
  The middleware server then communicates the client's requests to the data source.
  
• Type 4: Drivers that are pure Java and implement the network protocol for a specific data source.
  The client connects directly to the data source.
  

REMOTE METHOD INVOCATION (RMI) Remote method invocation allows applications to call object methods located remotely, sharing resources and processing load across systems.
Unlike other systems for remote execution which require that only simple data types or defined structures be passed to and from methods, RMI allows any Java object type to be used - even if the client or server has never encountered it before.
RMI allows both client and server to dynamically load new object types as required.
a) Consider the follow scenario: Developer X writes a service that performs some useful function.
He regularly updates this service, adding new features and improving existing ones.
Developer Y wishes to use the service provided by Developer X.
However, it's inconvenient for X to supply Y with an update every time.
The client must contact an RMI registry, and request the name of the service.
Developer Y won't know the exact location of the RMI service, but he knows enough to contact Developer X's registry.
This will point him in the direction of the service he wants to call.
Developer X's service changes regularly, so Developer Y doesn't have a copy of the class.
Not to worry, because the client automatically fetches the new subclass from a webserver where the two developers share classes.
The new class is loaded into memory, and the client is ready to use the new class.
This happens transparently for Developer Y - no extra code need to be written to fetch the class.