As I previously mentioned, the Java platform plays a dominant role in server-side application programming, as demonstrated by the recent increase in J2EE applications. Java succeeds because it has the right combination of tools and technologies that enable developers to create robust and scalable server applications. Corporations now use Java technologies for tasks such as providing the presentation layer for Web sites, the business logic on application servers, as well as creating custom client-server solutions.
Part of being a successful server-side technology is the ability to interact with data. Fortunately Java has this ability. It provides numerous APIs that help you access the different types of data stores. Figure 1-2 shows the role Java Data Access Technologies (JDATs) play in the enterprise environment.
From the figure you can see that JDAT includes JDBC, JNDI, JDO, and the XML APIs. You use the JDBC API to access data stored in a SQL database. The JNDI API gives you access to naming and directory services such as iPlanet’s Directory Server or Novell’s NDS. JNDI also supports LDAP so you can communicate with LDAP-enabled directory services. The JDO API provides a tool you can use to persist Java objects into a data store such as a relational database. This API does not compete with JDBC but rather complements it. Lastly, the XML APIs enable you to perform many different tasks with XML. For example, you can employ the APIs to use XML for inter-application messaging, making remote procedure calls, as well as parsing and transforming XML documents using SAX, DOM, and XSLT.
Notice in Figure 1-1 that any application can use the JDAT. Java Server Pages (JSP) technology, servlets, Enterprise Java Beans (EJBs), and stand-alone clients can take advantage of the APIs. Therefore, you do not need to rely on J2EE applications to access enterprise data stores. An application written using the Java 2 Standard Edition (J2SE) has equal access. The JDBC API provides a good example. A considerable amount of JDBC development does not reside in a J2EE container. Most often developers create clients that use the API to access relational databases without involving J2EE.
The remaining sections provide more details on the different Java data-access technologies shown in Figure 1.
Figure 1: The role Java Data Access Technologies (JDATs) play in the enterprise environment.
JDBC, the Java database-access technology, is probably the most widely known Java data-access API. Many books and Web sites exist to help educate you on its use. In addition, JDBC has wide industry support and you can find JDBC drivers for most databases on the market.
Note Here’s a piece of trivia. Contrary to popular belief, JDBC is not an acronym. It is a trademarked name by Sun Microsystems that represents a type of technology. It does not stand for “Java Database Connectivity” as most people think.
When Sun Microsystems released the original JDBC API 1.0 in 1997, the API had very limited features. It provided only a basic call-level interface to SQL databases. JDBC 2.0 touted more practical features such as scrollable cursors and batch updates. Along with the JDBC 2.0 release came the 2.0 Optional Package, which added a new package, javax.sql, and provided advanced features such as connection pooling, distributed transactions, and the RowSet interface.
Now at release 3.0, JDBC adds a few missing features to the API, such as transactional savepoints and more support for SQL99 data types. In addition, the core package, java.sql, and the optional API, javax.sql, are included with the Java 1.4 distribution. No longer must you separately download the javax.sql package to gain access to its features.
Where to Get the JDBC API
Both the JDK and JRE distributions include the JDBC 4.3 API. You can download both of these software packages at the JDBC homepage: www.javasoft.com/products/jdbc. However, the API only includes the JDBC-ODBC bridge driver, which enables you to use an ODBC driver to access a database. As a result, to use the bridge you must have an ODBC driver compatible with your database.
The API does not ship with drivers for other databases. You should contact your database vendor to determine if they have a JDBC driver available. If they do not, most likely a third party provides an implementation. You can find a list of driver vendors on the JDBC homepage.
In short, JDBC provides database developers with a powerful and flexible toolbox. It enables you to write database applications using one database interface. The methods defined in JDBC operate independently of the underlying database. For example, you use the same programming techniques to do any of the following tasks whether you are using DB2, Oracle, Informix, SQLServer, mSQL, or any other database:
- Open a connection
- Call stored procedures
- Add, modify, or delete data using SQL DML statements
- Execute DDL statements
- Handle database errors
As you can see, having one programmatic interface provides many benefits. If each vendor ignored JDBC and built its own API, dozens of different database programming paradigms would exist. Working with multiple databases would then require learning multiple interfaces. Fortunately, industry’s widespread adoption of JDBC has helped make it a standard.
The JNDI API 1.2 gives you a tool for accessing a variety of naming and directory services using Java. The JNDI API, like JDBC, also provides a single, consistent programming interface for access naming and directory services. Most enterprises use a directory service of some type. They may use one included with an operating system, such as Microsoft’s Active Directory Services, or a commercial product like iPlanet’s Directory Server.
JNDI plays an important role in the J2EE platform, as it enables you to locate and use objects stored in naming and directory services. For example, a J2EE deployment may use a naming or directory service as a repository to store objects like EJBs or JDBC DataSource objects. JNDI gives you the tools to create applications that can manage, retrieve, and use those objects from the services.
The JNDI API architecture consists of two components. The first, or core, API, provides the methods and properties you work with when writing client applications. You use this same API regardless of your target naming or directory service. Vendors use the second component, the Service Provider Interface (SPI), to develop drivers, creatively named service providers, for accessing naming and directory services. Just like a JDBC driver, the service provider abstracts the communication details used to interact with a naming or directory service. A service provider also plugs into the core API, which enables you to easily add support for different naming and directory services.
The JNDI 1.2 API ships with Java 1.3.1 or greater and includes the following service providers:
- Domain Name Service (DNS)
- CORBA’s Common Object Services (COS naming)
- RMI Registry
In addition, from Sun’s JNDI Web site you can also download other service providers created by Sun and third parties for the following naming and directory services:
- Sun’s Network Information Service (NIS)
- Novell’s Network Directory Service (NDS)
- File system
- Directory Services Markup Language (DSML)
The SPI architecture makes it easy for naming and directory vendors to create service providers. Because of the increased role these data stores are beginning to play in enterprises, you will probably see more service providers appearing — especially ones focused on high-performance LDAP access.
Java Data Objects (JDO) is a relatively new technology intended to make it easier to persist Java objects. Yes, you can easily persist objects by serializing them to disk, but no easy method exists for storing them in transactional systems like databases.
As of this writing, JDO is in development and only a reference implementation, version 0.95, exists. Thus, I do not cover the details of JDO in the book. However, the available code enables you to transparently store and retrieve Java objects from a B-tree storage structure stored on a hard drive. Support for relational databases should appear soon.
JDO fills a void that has plagued Java developers for some time. Often a developer needs to persist the state of an object in order to be able to resume at the same point later or share the object’s state with other components. Unfortunately, simple serialization does not enable you to use objects in transactions. Storing the objects in a database can alleviate the problem; however, doing so requires significant planning, as you must map an object’s fields to database fields. It also creates a maintenance challenge because object changes require database-schema changes as well.
JDO mitigates these problems. It provides an API with consistent interfaces that enable you to persist Java objects in different data stores. It also provides mechanisms for using stored objects in transactions as well as for searching for objects that meet certain criteria.
To obtain the latest information and JDO distribution, visit the JDO homepage at access1.sun.com/jdo.
Java XML APIs
Java has strong support for XML. In fact, both have quickly positioned themselves as indispensable players in server-side development and messaging applications. To support XML, Java has a suite of APIs that enable you to create, transform, and exchange XML documents. In addition, an API also exists that enables you to create Java classes representing an XML document based on its schema. The resulting classes handle parsing and transforming the XML document without you needing to worry about using the SAX parser and DOM trees.
The Java XML APIs also provides the foundation for the Web-services programming model. Using the APIs you can create distributed components that use XML to exchange information or look up application and business services.
As I mentioned earlier, Java provides several XML-centric APIs. The following list provides a partial list of what’s available:
- Java API for XML Parsing (JAXP) provides support for parsing and transforming XML documents. It supports SAX and DOM parsing as well as XSLT.
- Java API for XML-Based Remote Procedure Calls (JAX-RPC) enables you to use XML to make remote procedure calls across a network.
- Java API for XML Messaging (JAXM) gives an application the ability to send and receive XML-based messages. Based on Simple Object Access Protocol (SOAP) 1.1 with Attachments.
- Java Architecture for XML Binding (JAXB) provides a mechanism for creating Java classes based on XML schemas. Objects instantiated from the classes parse XML documents and enforce schema constraints.
- Java API for XML Registries and Repositories (JAXR) is a tool that enables you to search for registered business services listed in well-known XML business registries.
At the time of this writing most of the previous APIs were available as reference implementations or were under specification development. However JAXP, the parsing and transformation engine, is available. At version 1.1, it provides a fast, reliable, and flexible tool for working with XML documents. Visit Java site for more information.