Forwarded message:
> From HyperNews-Owner Fri Jun 21 10:26:57 KST 1996
> Date: Fri, 21 Jun 1996 10:26:52 +0900
> To: hollobit@kisco.co.kr
> From: hollobit@kisco.co.kr (Jonathan, Jeon)
> Reply-To: hollobit@kisco.co.kr (Jonathan, Jeon)
> X-HN-Base: Intranet W/G Board
> Keywords: JDBC DBMS ODBC
> Subject: The center of the universe is a database
> Message-ID: <"/intranet/27/7"@www.kisco.co.kr>
> In-Reply-To: <"/intranet/27"@www.kisco.co.kr>
> X-Hn-Url: http://www.kisco.co.kr/HyperNews/get/intranet/27/7.html
>
> HyperNews notification. Respond via:
> http://www.kisco.co.kr/HyperNews/get/intranet/27/7.html
>
> The center of the universe is a database
>
>
> Java and its role in the corporate database
>
> By William Blundon
>
> J ava holds great promise for a wide variety of computing,
> telecommunications, and entertainment applications. The world is rife
> with software products, but the center of the corporate universe is the
> database and the information it contains. The new JDBC database API to
> be finalized by JavaSoft this week is an excellent start as far as
> making Java a major component in corporate information systems. Creative
> developers don't have to wait for JDBC to connect to database servers
> today.
>
> The corporate database
> Designing, updating, securing, reporting, and disseminating information
> in databases is the chief occupation of the majority of information
> professionals, and this information may be stored in hierarchical,
> CODASYL, relational, object-relational, or object databases.
>
> If you seek evidence of the importance of databases, consider the
> following: Five of the top dozen software companies (IBM, Oracle,
> Sybase, Informix, and Software A.G.) have built their businesses
> primarily on databases. The top 25 software companies are heavily skewed
> toward databases, database tools, and applications built on top of
> databases. And in the corporate world, product licensing and staffing
> costs are primarily oriented toward building, deploying, and maintaining
> database applications.
>
> In order for Java to be a serious power in the enterprise, programmers
> must be able to write client applets, server servlets, and server
> applications that easily integrate with corporate databases. While the
> lure of Hollywood and the Internet may be painting Java as a tool to
> enliven Web sites with entertaining multimedia and interactivity, it is
> in the nuts-and-bolts world of data management that the language will
> either succeed or fail.
>
> Java and JDBC
> The JDBC specification has been available for review on JavaSoft's site
> on the World Wide Web since March and is expected to be finalized by the
> time you read this article. JDBC is built around three basic
> assumptions: Java must have native support for popular databases; the
> initial API should be built to include compatibility with existing
> database APIs like ODBC; and database support must range from remote
> access via applets through multitier applications distributed across
> servers.
>
> Java must have native support for SQL databases at a minimum, and
> ideally must include support for SQL3, object-relational databases, and
> object databases. Object and object-relational databases are relatively
> easy to support because they are flexible enough to provide support for
> all Java data structures directly. Indeed, for many object database
> vendors like Object Design, supporting Java is easier than supporting
> the complete C++ data model as they do today. Mapping Java's object view
> of the world to the 2-D world of relational databases is a greater
> challenge, but simply accessing information from these sources through a
> low-level interface is not.
>
> The JDBC API is an enhancement of concepts in widespread use through the
> call-level interface (CLI) originally defined by X/Open and popularized
> through Microsoft's ODBC. As a call-level interface, JDBC is a low-level
> standard, its primary purpose being to execute raw SQL statements and
> return their results to the caller (in many cases a browser). While SQL
> itself is a "standard," variants on that standard are supported by
> nearly every database vendor as a means toward product differentiation.
> This is particularly true in areas such as outer joins and stored
> procedures. JDBC is designed to pass any query string to the underlying
> database; it will permit access to extended SQL features at the
> potential risk of generating an error from data sources where the
> feature is not supported. The minimum level of SQL support required from
> a database product is SQL-2 Entry Level, on which most existing products
> can comfortably reside.
>
> Importantly, JDBC is designed to insure that its API fits easily with
> existing APIs like ODBC. JavaSoft is working closely with a number of
> database vendors and tools suppliers (such as Intersolv) to provide
> bridges between the two standards. However, ODBC is not the only
> standard that may be supported via JDBC. Database-specific interfaces
> from Oracle, Sybase, and IBM, among others, will undoubtedly be written
> for applications that must coexist with existing applications, or in
> cases in which performance is of primary concern. Similarly, JDBC
> interfaces will evolve for network interfaces to enable access to
> multiple databases on different servers.
>
> Today many people think of Java as a language for building applets that
> are downloaded to and executed by browsers, but its database API has
> been designed for much larger, more sophisticated applications. JDBC
> provides for the concept of database access applets. It lets developers
> distinguish between trusted and untrusted applets. Untrusted applets are
> typical in an Internet scenario in which information is transferred
> across insecure boundaries. Untrusted applets face a particular set of
> challenges in that they must execute in the "sandbox" of the Java
> Virtual Machine (JVM), from which there is no access to -- and
> frequently no knowledge of -- the local client's systems resources.
> Communications between databases and Internet applets also face an
> unknown latency as requests are routed across an ever-changing network
> topology to a server that may be in the next room or on the next
> continent.
>
> JDBC presupposes that Java will be used in other application scenarios.
> As such, the API is designed to manage data access where code is trusted
> and is permitted to access local or network resources (beyond a specific
> URL) to read and write files and open network connections. To succeed as
> a language and as an interface, Java and JDBC must provide a solution to
> developers who write these mission-critical database applications. In a
> typical intranet scenario, developers may use Java to build multiple
> applications on which access to a single database is both common and
> essential.
>
> JDBC is also designed to provide a natural implementation platform for
> N-tier client/server environments. In this scenario, a Java application
> may make a call to a middleware layer of services, which in turn
> accesses databases. These calls may be made through mechanisms such as a
> remote procedure call (RPC), an object request broker, or -- dare we say
> it -- OLE. Multitier database implementations provide an additional
> layer of security, performance, and management for database
> administrators by providing mediated access to specific databases where
> caching or local business rules may be implemented as needed.
>
> An alternative solution
> While JDBC holds great promise for database applications built in Java,
> it isn't quite there yet. Developers who need to implement an
> application immediately have a clever alternative. As long as there is a
> non-Java program on the server to handle the basic details of database
> interface, existing APIs like ODBC can be used with Java applets without
> recourse to any other interface.
>
> Some background: One of the great benefits of using Internet
> technologies is the simple but elegant construct of a universal resource
> locator (URL). In today's world, URLs typically point to static HTML
> pages. This may be more an artifact of Internet history than a design
> limitation. The reality is that URLs can (and increasingly will) point
> to other resources -- especially programs. URLs are an excellent
> mechanism for interfacing with programs because they consist not only of
> a network address but of an argument list that can be interpreted by an
> intelligent resource.
>
> When a program resides at the end of a URL address, these arguments can
> simply become arguments to a program and can be executed on a remote
> server. Through two simple calls, GET to pass a single packet of
> information to the server and POST for arbitrary-length requests that
> can amount to entire files, a client can pass a complex stream of
> information to the server for interpretation and execution. When the
> server application is a program (a C++ program is the best example), it
> is quite possible to use this simple mechanism to do the equivalent of a
> remote procedure call over the network.
>
> The URL address points to the server application, the application
> invokes a method on the server, and the URL's arguments are input to
> this method. Where the method accesses a database through an existing
> standard like ODBC, the arguments can execute typical database
> constructs such as INSERT, DELETE, and UPDATE . Results are returned to
> the client via the standard HTTP protocol for interpretation and display
> by the browser. The results may be converted by the server program into
> any standard HTML content type or any available plug-in. Typically the
> conversion will be to an HTML page that replaces the typical dialog box
> in a standard ODBC environment.
>
> Since the concept of a URL is built into Java, and since Java applets
> are capable of executing on many browsers, the language provides a
> flexible environment for distributing logic across clients and servers.
> The nature of Java promotes the use of object-oriented constructs and
> the notion of method passing as the primary interface between client and
> server. The fact that the client is a Java applet running in a browser,
> and the server is a C++ program executing as part of an HTTP server, is
> only relevant to the harried developer.
>
> Conclusion
> Databases are the center of the corporate universe and central to Java's
> future. When the history of information management is written by some
> hominid in the future, most of the paragraphs that include the word Java
> will also include the word database. While JDBC will be the focus of
> this history, existing standards like ODBC will be much more than a
> footnote, and they are readily accessible to the creative programmer
> today. [IMAGE][3]
>
> About the author
> William Blundon is president and COO of SourceCraft Inc.[4]
> (http://www.sourcecraft.com), a leading developer of intranet
> development tools for Java and C++. His focus in the last seven years
> has been on distributed-object environments and the Internet. He is a
> former director of the Object Management Group. He can be reached at
> william.blundon@javaworld.com[5] .
>
> -----------------------------------------------------------------------
> [1] /icons/blueline.gif
> [2] /icons/blueline.gif
> [3] /javaworld/icons/dingbat.gif
> [4] http://www.sourcecraft.com
> [5] /javaworld/cgi-bin/jw-mailto.cgi?william.blundon@javaworld.com
>