Supporting J2EE APIs
J2EE provides a number of "supporting" APIs. The purpose of most of these APIs is to enable interaction between the "main" software layers/components in the J2EE architecture.
RMI is an important API used for supporting distributed computing and has been supported in core Java since version 1.1. RMI allows a Java client application to communicate with a Java server application by invoking methods on that remote object. With RMI, the client gets a reference to a server object and then it can invoke methods on that object as if it were a local object within the same virtual machine.
For server objects developed in other languages, you must employ other techniques like
using Java IDL with CORBA or RMI/IIOP to access the server object.
Java Naming and Directory Interface (JNDI)
JNDI allows Java programs to use name servers and directory servers to look up objects or data by name. This important feature allows a client object to locate a remote server object or data.
JNDI is a generic API that can work with any name or directory servers. Server
providers have been implemented for many common protocols (e.g. NIS, LDAP and NDS) and for
CORBA object registries. Of particular interest to users of J2EE, JNDI is used to locate
Enterprise JavaBean (EJB) components on the network.
JMS is an API for using networked messaging services. Data sent in a message is often
intended as a sort of event notification (e.g. a Email-handling process may need to be
notified when a request is enqueued). Another common use for messaging (thus JMS) is
for interfacing with "external", third party or legacy applications, typically via a Message
Oriented Middleware product like IBM's MQ Series (now WebSphere MQ). It can be complex/risky to use
RPC/RMI to directly invoke remote applications while a messaging solution can provide a
simpler and more reliable interconnection.
JTA is used for managing distributed transactions (e.g. updates to multiple databases that must be handled in a single transaction). JTA is a low-level API and associated coding is complex and error-prone.
Fortunately, EJB containers (or application servers) generally provide support for
distributed transactions using JTA. For this reason, the EJB developer is able to gain the
benefit of distributed transaction while leaving the complex implementation details to the
provider of the EJB container.
Java Database Connectivity (JDBC) / SQLJ
In principle, JDBC serves the same purpose as ODBC. JDBC provides a database-independent protocol for accessing relational databases from Java. JDBC supports Data Manipulation Language (DML) statements like insert, update, delete, select. It also includes Data Definition Language (DDL) statements like Create Table, Alter Table, etc.
JDBC was included in core Java starting with version 1.1. With JDBC, the SQL is always dynamically generated at runtime and sent to the database.
A easier-to-use industry standard for Java database access has emerged
and is called SQLJ. SQLJ allows static SQL to be used and it requires less
cumbersome syntax than JDBC. Other SQLJ advantages over JDBC include better code
quality (due to compile-time syntax checking) and better performance (due to compile-time
optimization). James Woodger co-authored an in-depth article on SQLJ for the
November 2000 issue of Java Enterprise Developer.
JavaMail is an independent mail platform which works with major industry protocols (SMTP, POP3, etc.). It allows a Java client application to send mail to heterogeneous mail servers.
... back to Java Topics