Class 4 JDBC Driver Architecture

The final class of distributed driver is still an all java client, but the jdbc client library implements the exact same protocol as that used by the C client library. Now, the interbase server can't tell the difference between a java client and a C client. So you remove the need for a separate jdbc server.

All client components are pure Java

Driver subsumes DBMS client library and protocol

Class 4

• Reuse existing remote layer for both C and Java clients
  
• But pinned to legacy protocol
  which may not be amenable for jdbc access

Class 3

• More flexible
  More flexible architecture since you have complete control over the server side; no legacy protocol issues; streamlined for jdbc.
• But requires a new remote server
  In addition to the interbase server, there is now a jdbc server that must be started on the server or middle tier. C clients and Java clients use different remote layers.

Another advantage of the class 3 architecture is that it's tiered, with the jdbc server in the middle tier. This adds flexibility for things like security, compression, and underlying data marshalling. If you look at sybase which has a class 4 driver, no sybase server remote layer currently supports SSL, so if you want data security using jConnect, you have to go thru an intermediary HTTPS gateway.

Because interserver is tailored specifically for interbase remote access, to say interserver is a driver component, or a dbms component is rather arbitrary. But it is clear that interserver and its remote protocol are shrink wrapped tightly around the interbase native api and interbase capabilities. This flexibility gives rise to the fastest jdbc driver on the market today, interclient.