| |
Home |
![[Table of Contents]](/dwicons/b_toc.gif)
|
Java in Adaptive Server Enterprise |
![[-]](/dwicons/i_colpse.gif)
| Chapter 1 An Introduction to Java in the Database |
Chapter 1
This chapter provides an overview of Java classes in Adaptive Server Enterprise.
Adaptive Server provides a runtime environment for Java, which means that Java code can be executed in the server. Building a runtime environment for Java in the database server provides powerful new ways of managing and storing both data and logic.
You can use the Java programming language as an integral part of Transact-SQL.
You can reuse Java code in the different layers of your application--client, middle-tier, or server--and use them wherever makes most sense to you.
Java in Adaptive Server provides a more powerful language than stored procedures for building logic into the database.
Java classes become rich, user-defined data types.
Methods of Java classes provide new functions accessible from SQL.
Java can be used in the database without jeopardizing the integrity, security, and robustness of the database. Using Java does not alter the behavior of existing SQL statements or other aspects of non-Java relational database behavior.
Java in Adaptive Server allows you to:
Invoke Java methods in the database
Store Java classes as datatypes
Store and query XML in the database
You can install Java classes in Adaptive Server, and then invoke the static methods of those classes in two ways:
You can invoke the Java methods directly in SQL.
You can wrap the methods in SQL names and invoke them as you would standard Transact-SQL stored procedures.
The methods of an object-oriented language correspond to the functions of a procedural language. You can invoke methods stored in the database by referencing them, with name qualification, on instances for instance methods, and on either instances or classes for static (class) methods. You can invoke the method directly in, for example, Transact-SQL select lists and where clauses.
You can use static methods that return a value to the caller as user-defined functions (UDFs).
Certain restrictions apply when using Java methods in this way:
If the Java method accesses the database through JDBC, result-set values are available only to the Java method, not to the client application.
Output parameters are not supported. A method can manipulate the data it receives from a JDBC connection, but the only value it can return to its caller is a single return value declared as part of its definition.
You can enclose Java static methods in SQL wrappers and use them exactly as you would Transact-SQL stored procedures or built-in functions. This functionality:
Allows Java methods to return output parameters and result sets to the calling environment.
Allows you to take advantage of traditional SQL syntax, metadata, and permission capabilities.
Allows you to invoke SQLJ functions across databases.
Allows you to use existing Java methods as SQLJ procedures and functions on the server, on the client, and on any SQLJ-compliant, third-party database.
Complies with Part 1 of the ANSI standard specification. See "Standards".
With Java in the database, you can install pure Java classes in a SQL system, and then use those classes in a natural manner as datatypes in a SQL database. This capability adds a full object-oriented datatype extension mechanism to SQL, using a model that is widely understood and a language that is portable and widely available. The objects that you create and store with this facility are readily transferable to any Java-enabled environment, either in another SQL system or standalone Java environment.
This capability of using Java classes in the database has two different but complementary uses:
It provides a type extension mechanism for SQL, which you can use for data that is created and processed in SQL.
It provides a persistent data capability for Java, which you can use to store data in SQL that is created and processed (mainly) in Java. Java in Adaptive Server provides a distinct advantage over traditional SQL facilities: you do not need to map the Java objects into scalar SQL datatypes or store the Java objects as untyped binary strings.
Similar to Hypertext Markup Language (HTML), the eXtensible Markup Language (XML) allows you to define your own application-specific markup tags and is thus particularly suited for data interchange.
Adaptive Server allows you to:
Generate XML-formatted documents from raw data stored in Adaptive Server.
Store XML documents and data extracted from them in Adaptive Server.
Query XML documents stored on the Web.
Adaptive Server uses the XML Query Language (XQL) to search XML documents. A Java-based XQL query processor is included with Adaptive Server. Because many of the tools commonly used to process XML are written in Java, Adaptive Server provides an excellent base for XML-SQL applications.
The SQLJ consortium of SQL vendors develops specifications for using Java with SQL. The consortium submits these specifications to ANSI for formal processing as standards. The standards can be found on the Web at http://www.ansi.org. In this document, SQLJ refers to capabilities compliant with SQLJ Part 1 of the standard specifications
Compliance with SQLJ standards ensures that Sybase functionality ports to all third-party, standards-compliant relational databases.The standard specifications are in three parts:
Part 0 - "Database Language SQL--Part 10: Object Language Bindings (SQL/OLB)," ANSI X3.135.10-1998.
Specifications for embedding SQL statements in Java methods. Similar to the traditional SQL facilities for embedded SQL in COBOL and C and other languages. The Java classes containing embedded SQL statements are precompiled to pure Java classes with JDBC calls.
Part 1 - "SQLJ--Part 1: SQL Routines using the Java Programming Language," ANSI NCITS N331.1.
Specifications for installing Java classes in a SQL system, and for invoking Java static methods as SQL stored procedures and functions.
Part 2 - "SQLJ--Part 2: SQL Types using the Java Programming Language," ANSI NCITS N331.2.
Specifications for using Java classes as SQL datatypes.
Sybase supports Part 1 of the specification. In addition, Sybase extends the capabilities provided in the standard. For example, Adaptive Server allows you to reference Java methods and classes directly in SQL, whereas SQLJ Parts 1 and 2 require that you use SQL aliases.
Although this book assumes that readers are familiar with Java, there is much to learn about Java in a database. Sybase is not only extending the capabilities of the database with Java, but also extending the capabilities of Java with the database. See
Both experienced and novice Java users should read this section. It uses a question-and-answer format to familiarize you with the basics of Java in Adaptive Server.
All of these points are explained in detail in later sections. With Java in Adaptive Server, you can:
Run Java in the database server using an internal Java Virtual Machine (Java VM).
Call Java functions (methods) directly from SQL statements.
Wrap Java methods in SQL aliases and call them as standard SQL stored procedures and built-in functions.
Access SQL data from Java using an internal JDBC driver.
Use Java classes as SQL datatypes.
Save instances of Java classes in tables.
Generate XML-formatted documents from raw data stored in Adaptive Server databases and, conversely, store XML documents and data extracted from them in Adaptive Server databases.
Debug Java in the database.
Java is an object-oriented language. Its instructions (source code) come in the form of classes. You write and compile the Java instructions outside the database into compiled classes (byte code), which are binary files holding Java instructions.
You then install the compiled classes into the database, where they can be executed in the database server.
Adaptive Server is a runtime environment for Java classes. You need a Java development environment, such as Sybase PowerJ(TM) or Sun Microsystems Java Development Kit (JDK), to write and compile Java.
To support Java in the database, Adaptive Server:
Comes with its own Java VM, specifically developed for handling Java processing in the server.
Uses its own JDBC driver that runs in the server and accesses a database.
The Sybase Java VM runs in the database environment. It interprets compiled Java instructions and runs them in the database server.
The Sybase Java VM meets the JCM specifications from Java Software; it is designed to work with the 2.0 version of the Java API. It supports public class and instance methods; classes inheriting from other classes; the Java API; and access to protected, public, and private fields. Some Java API functions that are not appropriate in a server environment, such as user interface elements, are not supported. All supported Java API packages and classes come with Adaptive Server.
The Adaptive Server Java VM is available at all times to perform a Java operation whenever it is required as part of the execution of a SQL statement. The database server starts the Java VM automatically when it is needed; you do not need to take any explicit action to start or stop the Java VM.
Client- and server-side JDBCJDBC is the industry standard API for executing SQL in Java.
Adaptive Server provides a native JDBC driver. This driver is designed to maximize performance as it executes on the server because it does not need to communicate across the network. This driver permits Java classes installed in a database to use JDBC classes that execute SQL statements.
When JDBC classes are used within a client application, you typically must use jConnect(TM) for JDBC(TM), the Sybase client-side JDBC database driver, to provide the classes necessary to establish a database connection.
A guiding principle for the design of Java in the database is that it provides a natural, open extension to existing SQL functionality.
Java operations are invoked from SQL - Sybase has extended the range of SQL expressions to include fields and methods of Java objects, so that you can include Java operations in a SQL statement.
Java methods as SQLJ stored procedures and functions - you create a SQLJ alias for Java static methods, so that you can invoke them as standard SQL stored procedures and user-defined functions (UDFs).
Java classes become user-defined datatypes - you store Java class instances using the same SQL statements as those used for traditional SQL datatypes.
You can use classes that are part of the Java API, and classes created and compiled by Java developers.
The Java Application Programming Interface (API) is a set of classes defined by Sun Microsystems. It provides a range of base functionality that can be used and extended by Java developers. It is the core of "what you can do" with Java.
The Java API offers considerable functionality in its own right. A large portion of the Java API is built in to any database that is enabled to use Java code--which includes the majority of nonvisual classes from the Java API already familiar to developers using the Sun Microsystems JDK.
You can use the Java API in stored procedures, in UDFs, and in SQL statements as extensions to the available built-in functions provided by SQL.
For example, the SQL function PI(*) returns the value for Pi. The Java API class java.lang.Math has a parallel field named PI that returns the same value. But java.lang.Math also has a field named E that returns the base of the natural logarithm, as well as a method that computes the remainder operation on two arguments as prescribed by the IEE754 standard.
Not all Java API classes are supported in the database. Some classes, for example, the java.awt package that contains user interface components for applications, are not appropriate inside a database server. Other classes, including part of java.io, deal with writing information to a disk, and are also not supported in the database server environment. See Chapter 12, "Reference Topics," for a list of supported and unsupported classes.
You can install your own Java classes into the database as, for example, a user-created Employee class or Inventory class that a developer designed, wrote, and compiled with a Java compiler.
User-defined Java classes can contain both information and methods. Once installed in a database, Adaptive Server lets you use these classes in all parts and operations of the database and execute their functionality (in the form of class or instance methods).
The JDBC interface is an industry standard designed to access database systems. The JDBC classes are designed to connect to a database, request data using SQL statements, and return results that can be processed in the client application.
You can connect from a client application to Adaptive Server Enterprise via JDBC, using jConnect or a JDBC/ODBC bridge. Adaptive Server also provides an internal JDBC driver, which permits Java classes installed in a database to use JDBC classes that execute SQL statements.
You can create Java classes that can be used on different levels of an enterprise application. You can integrate the same Java class into either the client application, a middle tier, or the database.
Using Java classes, whether user-defined or from the Java API, is a three-step activity:
Write or acquire a set of Java classes that you want to use as SQL datatypes, or as SQL aliases for static methods.
Install those classes in the Adaptive Server database.
Use those classes in SQL code:
Call class (static) methods of those classes as UDFs.
Declare the Java classes as datatypes of SQL columns, variables, and parameters. In this book, they are called Java-SQL columns, variables, and parameters.
Reference the Java-SQL columns, their fields, and their methods.
Wrap static methods in SQL aliases and use them as stored procedures or functions.
There are many books about Java and Java in the database. Two particularly useful books are:
James Gosling, Bill Joy, Guy Steele, and Gilad Bracha, The Java(TM) Language Specification, Second Edition, Addison-Wesley, 2000.
Seth White, Maydene Fisher, Rick Cattell, Graham Hamilton, and Mark Hapner, JDBC(TM) API Tutorial and Reference, Second Edition, Addison-Wesley, 1999.
Adaptive Server is a runtime environment for Java classes, not a Java development environment.
You cannot carry out these tasks in the database:
Edit class source files (*.java files).
Compile Java class source files (*.java files).
Execute Java APIs that are not supported, such as applet and visual classes.
Use Java threading. Adaptive Server does not support java.lang.Thread and java.lang.ThreadGroup. If you attempt to spawn a thread, Adaptive Server throws java.lang.UnsupportedOperationException.
Use Java objects as parameters sent to a remote procedure call or received from a remote procedure call. They do not translate correctly.
Sybase recommends that you do not use static variables in methods referenced by Java-SQL functions, SQLJ functions, or SQLJ stored procedures. The values returned for these variables may be unreliable as the scope of the static variable is implementation-dependent.
The chapters of this book use simple Java classes to illustrate basic principles for using Java in the database. You can find copies of these classes in the chapters that describe them and in the Sybase release directory in $SYBASE/$SYBASE_ASE/sample/JavaSql (UNIX) or %SYBASE%\Ase-12_5\sample\JavaSql (Windows NT). This subdirectory also contains Javadoc facilities so that you can view specifications about sample classes and methods with your Web browser.
|
|