Re: universal server java client API vs. JDBC

Matthew Tepel (mtepel@hcs.harvard.edu) wrote: : I'm new to java and don't know too much about JDBC. Would JDBC be : sufficient to handle the features of IUS? Or should I just go ahead and : use the Informix Java API? IMHO, no. Use the IUS Java API. The advantage of JDBC is that it is a 'standard' interface. It's based on Microsoft's ODBC interface, and it supports similar functionality. The disadvantages are clear when you consider the kind of database that IUS is. IUS can be extended by the addition of new abstract (or scalar) data types. These new data types can be modifications of other data types, something the developer gets with a DataBlade module, or some business object which is specific to the universe of discourse the ORDBMS is addressing. The trouble is, the way ODBC is conceived, it understands a limited range of these data types based on the SQL-92 standard. Now, it's possible to write a mapping of the server side data type to some generic data type (BLOB). This seems to me more effort than its worth -- you might as well write to the Informix API -- and further it fails to truly leverage IUS. Architecturally speaking, in an extensible DBMS world, it isn't enough for the DBMS to provide the client with data; it needs to provide the client with class definitions too. This means that the server needs to ship to the client information about how to perform tasks like display the object, re-size it, perform edit checks, and so on. JDBC is fundamentally unsuitable for this approach. Of course, the standard argument is that the client application needs to talk to multiple DBMS back ends. Under these circumstances JDBC is clearly the only alternative. At least until someone wakes Sun up to the technical potential of their little language and gets them to agree to a saner interface standard. KR Pb