The JDBC API is the industry standard for database-independent connectivity between the Java programming language and

a wide range of databases. The JDBC API provides a call-level API for SQL-based database access. JDBC technology allows you to use the Java programming language to exploit "Write Once, Run Anywhere" capabilities for applications that require access to enterprise data. JDBC API Overview The JDBC API makes it possible to do three things: Establish a connection with a database or access any tabular data source Send SQL statements Process the results JDBC Architecture The JDBC API contains two major sets of interfaces: the first is the JDBC API for application writers, and the second is the lower-level JDBC driver API for driver writers. JDBC technology drivers fit into one of four categories. Applications and applets can access databases via the JDBC API using pure Java JDBC technology-based drivers, as shown in this figure:

Left side, Type 4: Direct-to-Database Pure Java Driver This style of driver converts JDBC calls into the network protocol used directly by DBMSs, allowing a direct call from the client machine to the DBMS server and providing a practical solution for intranet access. Right side, Type 3: Pure Java Driver for Database Middleware This style of driver translates JDBC calls into the middleware vendor's protocol, which is then translated to a DBMS protocol by a middleware server. The middleware provides connectivity to many different databases. The graphic below illustrates JDBC connectivity using ODBC drivers and existing database client libraries.

Left side, Type 1: JDBC-ODBC Bridge plus ODBC Driver This combination provides JDBC access via ODBC drivers. ODBC binary code -- and in many cases, database client code -- must be loaded on each client machine that uses a JDBC-ODBC Bridge. Sun provides a JDBC-ODBC Bridge driver, which is appropriate for experimental use and for situations in which no other driver is available. Right side, Type 2: A native API partly Java technology-enabled driver This type of driver converts JDBC calls into calls on the client API for Oracle, Sybase, Informix, DB2, or other DBMS. Note that, like the bridge driver, this style of driver requires that some binary code be loaded on each client machine. For comparison of driver types, please see the article published in Computerworld. Partnering for Progress Sun worked with an array of companies in the industry to create and rapidly establish the JDBC API as the industrystandard, open interface for Java applications to access databases. Industry Momentum Leading database, middleware and tool vendors have been building support for JDBC technology into many new products. This ensures that customers can build portable Java applications while choosing from a wide range of competitive products for the solution best suited to their needs. See the Industry Support page for a list of companies that are shipping products with support for JDBC technology. Advantages of JDBC Technology Leverage Existing Enterprise Data With JDBC technology, businesses are not locked in any proprietary architecture, and can continue to use their installed databases and access information easily -- even if it is stored on different database management systems. Simplified Enterprise Development The combination of the Java API and the JDBC API makes application development easy and economical. JDBC hides the complexity of many data access tasks, doing most of the "heavy lifting"for the programmer behind the scenes. The JDBC API is simple to learn, easy to deploy, and inexpensive to maintain. Zero Configuration for Network Computers With the JDBC API, no configuration is required on the client side. With a driver written in the Java programming language, all the information needed to make a connection is completely defined by the JDBC URL or by a DataSource object registered with a Java Naming and Directory Interface (JNDI) naming service. Zero configuration for clients supports the network computing paradigm and centralizes software maintenance.

Key Features Full Access to Metadata The JDBC API provides metadata access that enables the development of sophisticated applications that need to understand the underlying facilities and capabilities of a specific database connection. No Installation A pure JDBC technology-based driver does not require special installation; it is automatically downloaded as part of the applet that makes the JDBC calls. Database Connection Identified by URL JDBC technology exploits the advantages of Internet-standard URLs to identify database connections. The JDBC API includes an even better way to identify and connect to a data source, using a DataSource object, that makes code even more portable and easier to maintain.

In addition to this important advantage, DataSource objects can provide connection pooling and distributed transactions, essential for enterprise database computing. This functionality is provided transparently to the programmer. Included in the Java Platform As a core part of the Java 2 Platform, the JDBC API is available anywhere that the platform is. This means that your applications can truly write database applications once and access data anywhere. The JDBC API is included in both the Java 2 Platform, Standard Edition (J2SE) and the Java 2 Platform, Enterprise Edition (J2EE), providing serverside functionality for industrial strength scalability. An example of a J2EE based architecture that includes a JDBC implementation:

Requirements Software: The Java 2 Platform (either the Java 2 SDK, Standard Edition, or the Java 2 SDK, Enterprise Edition), an SQL database, and a JDBC technology-based driver for that database. Hardware: Same as for the Java 2 Platform.

Why J2EE Connector Architecture?

The J2EE Connector architecture is based on the technologies defined and standardized in the Java 2 Platform, Enterprise Edition (J2EE) and is part of the J2EE platform. As more businesses move towards an e-business strategy, integration with existing enterprise information systems (EIS) becomes the key to success. Enterprises with successful e-businesses need to integrate their existing EIS systems with new web-based applications. They also need to extend the reach of their EIS systems to support business-to-business (B2B) transactions. Before the the J2EE Connector architecture was defined, no specification for the Java platform addressed the problem of providing a standard architecture for integrating heterogeneous EIS systems. Most EIS vendors and application server vendors use non-standard vendor-specific architectures to provide connectivity between application servers and enterprise information systems. The following diagram illustrates the complexity of a heterogenous environment.

J2EE Platform Overview

The Java 2 Platform, Enterprise Edition provides containers for client applications, web components based on Servlets and JavaServer Pages (JSP) technologies, and Enterprise JavaBeans (EJB) components. These containers provide deployment and runtime support for application components. They also provide a federated view of the services provided by the underlying application server for the application components. Containers run on existing systems: web servers for the web containers, application servers, transaction processing (TP) monitors, and database systems for EJB containers. This enables enterprises to leverage both the advantages of their existing systems and those with J2EE technology. Enterprises can write (or rewrite) new applications using J2EE technology capabilities and can also encapsulate parts of existing applications with Enterprise JavaBeans or JavaServer Pages (JSP) technologies. Enterprise applications access functions and data associated with applications running on EISs. Application servers extend their containers and support connectivity to heterogeneous EISs. Enterprise tools and Enterprise Application Integration (EAI) vendors add value by providing tools and frameworks to simplify the EIS integration task. The J2EE Connector architecture defines a standard architecture for connecting the J2EE platform to heterogeneous EIS systems. Examples of EIS systems include ERP, mainframe transaction processing, database systems, and

legacy applications not written in the Java programming language. By defining a a set of scalable, secure, and transactional mechanisms, the J2EE Connector architecture enables the integration of EISs with application servers and enterprise applications. The J2EE Connector architecture enables an EIS vendor to provide a standard resource adapter for its EIS. The resource adapter plugs into an application server, providing connectivity between the EIS, the application server, and the enterprise application. If an application server vendor has extended its system to support the J2EE Connector architecture, it is assured of seamless connectivity to multiple EISs. An EIS vendor needs to provide just one standard resource adapter which has the capability to plug in to any application server that supports the J2EE Connector architecture. Multiple resource adapters (that is, one resource adapter per type of EIS) are pluggable into an application server. This capability enables application components deployed on the application server to access the underlying EIS systems.

Resource Adapter

To achieve a standard system-level pluggability between application servers and EISs, the J2EE Connector architecture defines a standard set of system-level contracts between an application server and EIS. The resource adapter implements the EIS-side of these system-level contracts. A resource adapter is a system-level software driver used by an application server or an application client to connect to an EIS. By plugging into an application server, the resource adapter collaborates with the server to provide the underlying mechanisms, the transactions, security, and connection pooling mechanisms. A resource adapter is used within the address space of the application server.

System Contracts

An application server and an EIS collaborate to keep all system-level mechanisms, such as transactions, security, and connection management, transparent from the application components. As a result, an application component provider focuses on the development of business and presentation logic for its application components and need not get involved in the system-level issues related to EIS integration. This promotes easier and faster development of scalable, secure, and transactional enterprise applications that require connectivity with multiple EIS systems. The J2EE Connector architecture (Version 1.0) defines the following set of system-level contracts between an application server and EIS, which enables outbound connectivity to an EIS:

A Connection Management contract that lets an application server pool connections to an underlying EIS, and lets application components connect to an EIS. This leads to a scalable application environment that can support a large number of clients requiring access to EISs A Transaction Management contract between the transaction manager and an EIS that supports transactional access to EIS resource managers. This contract lets an application server use a transaction manager to manage transactions across multiple resource managers. This contract also supports transactions that are managed internal to an EIS resource manager without the necessity of involving an external transaction manager. A Security contract that enables a secure access to an EIS. This contract provides support for a secure application environment, which reduces security threats to the EIS and protects valuable information resources managed by the EIS. The J2EE Connector architecture (Version 1.5) defines the following set of system-level contracts between an application server and EIS, which enables inbound connectivity from an EIS:

A Transaction Inflow contract that allows a resource adapter to propagate an imported transaction to an application server. This contract also allows a resource adapter to flowin transaction completion and crash recovery calls initiated by an EIS, and ensures that the ACID properties of the imported transaction are preserved. A Message Inflow contract that allows a resource adapter to asynchronously deliver messages to message endpoints residing in the application server independent of the specific messaging style, messaging semantics and messaging infrastructure used to deliver messages. This contract also serves as the standard message provider pluggability contract that allows a wide range of message providers (Java Message Service (JMS), Java API for XML Messaging (JAXM), and so on) to be plugged into any J2EE technology-compatible application server via a resource adapter. The J2EE Connector architecture (Version 1.5) also defines the following set of system-level contracts between an application server and EIS, which enables resource adapter lifecycle management and thread management:

A Lifecycle Management contract that allows an application server to manage the lifecycle of a resource adapter. This contract provides a mechanism for the application server to bootstrap a resource adapter instance during its deployment or application server startup, and to notify the resource adapter instance during its undeployment or during an orderly shutdown of the application server. A Work Management contract that allows a resource adapter to do work (monitor network endpoints, call application components, etc.) by submitting Work instances to an application server for execution. The application server dispatches threads to execute submitted Work instances. This allows a resource adapter to avoid creating or managing threads directly, provides a mechanism for a resource adapter to do its work, and allows an application server to efficiently pool threads and have more control over its runtime environment. The resource adapter can control the security context and transaction context with which Work instances are executed.

Common Client Interface (CCI)

The J2EE Connector architecture also defines a Common Client Interface (CCI) for EIS access. The CCI defines a standard client API for application components. The CCI enables application components and Enterprise Application Integration (EAI) frameworks to drive interactions across heterogeneous EISs using a common client API. The CCI is intended for use by Enterprise Application Integration (EAI) and enterprise tools vendors.

html
Webpages are written in HTML - a simple scripting language. HTML is short for HyperText Markup Language.

Hypertext is simply a piece of text that works as a link. Markup Language is a way of writing layout information within documents.

Basically an HTML document is a plain text file that contains text and nothing else. When a browser opens an HTML file, the browser will look for HTML codes in the text and use
them to change the layout, insert images, or create links to other pages.

Since HTML documents are just text files they can be written in even the simplest text editor. A more popular choice is to use a special HTML editor - maybe even one that puts focus on the
visual result rather than the codes - a so-called WYSIWYG editor ("What You See Is What You Get").

Some of the most popular HTML editors, such as FrontPage or Dreamweaver will let you create
pages more or less as you write documents in Word or whatever text editor you're using.

However, there are some very good reasons to create your own pages - or parts of them - by
hand...

It is possible to create webpages without knowing anything about the HTML source behind the
page.

There are excellent editors on the market that will take care of the HTML parts. All you need to do is
layout the page.

However, if you want to make it above average in webdesign, it is strongly recommended that you
understand these tags.

The most important benefits are:

You can use tags the editor does not support. You can read the code of other people's pages, and "borrow" the cool effects. You can do the work yourself, when the editor simply refuses to create the effects you want.

You can write your HTML by hand with almost any available text editor, including notepad that
comes as a standard program with Windows.

All you need to do is type in the code, then save the document, making sure to put an .html
extension or an .htm extension to the file (for instance "mypage.html").

Dhtml
DHTML is NOT a W3C Standard
DHTML stands for Dynamic HTML. DHTML is not a standard defined by the World Wide Web Consortium (W3C). DHTML is a "marketing term" - used by Netscape and Microsoft to describe the new technologies the 4.x generation browsers would support. DHTML is a combination of technologies used to create dynamic Web sites. To most people DHTML means a combination of HTML 4.0, Style Sheets and JavaScript. W3C once said: "Dynamic HTML is a term used by some vendors to describe the combination of HTML, style sheets and scripts that allows documents to be animated."

DHTML Technologies

With DHTML a Web developer can control how to display and position HTML elements in a browser window.

HTML 4.0
With HTML 4.0 all formatting can be moved out of the HTML document and into a separate style sheet. Because HTML 4.0 separates the presentation of the document from its structure, we have total control of presentation layout without messing up the document content.

Cascading Style Sheets (CSS)

With CSS we have a style and layout model for HTML documents. CSS was a breakthrough in Web design because it allowed developers to control the style and layout of multiple Web pages all at once. As a Web developer you can define a style for each HTML element and apply it to as many Web pages as you want. To make a global change, simply change the style, and all elements in the Web are updated automatically.

The Document Object Model (DOM)

DOM stands for the Document Object Model. The HTML DOM is the Document Object Model for HTML. The HTML DOM defines a standard set of objects for HTML, and a standard way to access and manipulate HTML objects. "The W3C Document Object Model (DOM) is a platform and language neutral interface that allows programs and scripts to dynamically access and update the content, structure, and style of a document" .

JavaScript
Allows you to write code to control all HTML elements.

Servlet
What are Java Servlets?
Servlets are Java technology's answer to CGI programming. They are programs that run on a Web server and build Web pages. Building Web pages on the fly is useful (and commonly done) for a number of reasons:

The Web page is based on data submitted by the user. For example the results pages from search engines are generated this way, and programs that process orders for e-commerce sites do this as well. The data changes frequently. For example, a weather-report or news headlines page might build the page dynamically, perhaps returning a previously built page if it is still up to date. The Web page uses information from corporate databases or other such sources. For example, you would use this for making a Web page at an on-line store that lists current prices and number of items in stock.

2. What are the Advantage of Servlets Over "Traditional" CGI?

Java servlets are more efficient, easier to use, more powerful, more portable, and cheaper than traditional CGI and than many alternative CGI-like technologies. (More importantly, servlet developers get paid more than Perl programmers :-). Efficient. With traditional CGI, a new process is started for each HTTP request. If the CGI program does a relatively fast operation, the overhead of starting the process can dominate the execution time. With servlets, the Java Virtual Machine stays up, and each request is handled by a lightweight Java thread, not a heavyweight operating system process. Similarly, in traditional CGI, if there are N simultaneous request to the same CGI program, then the code for the CGI program is loaded into memory N times. With servlets, however, there are N threads but only a single copy of the servlet class. Servlets also have more alternatives than do regular CGI programs for optimizations such as caching previous computations, keeping database connections open, and the like. Convenient. Hey, you already know Java. Why learn Perl too? Besides the convenience of being able to use a familiar language, servlets have an extensive infrastructure for automatically parsing and decoding HTML form data, reading and setting HTTP headers, handling cookies, tracking sessions, and many other such utilities.

Powerful. Java servlets let you easily do several things that are difficult or impossible with regular CGI. For one thing, servlets can talk directly to the Web server (regular CGI programs can't). This simplifies operations that need to look up images and other data stored in standard places. Servlets can also share data among each other, making useful things like database connection pools easy to implement. They can also maintain information from request to request, simplifying things like session tracking and caching of previous computations.

Portable. Servlets are written in Java and follow a well-standardized API. Consequently, servlets written for, say I-Planet Enterprise Server can run virtually unchanged on Apache, Microsoft IIS, or WebStar. Servlets are supported directly or via a plugin on almost every major Web server. Inexpensive. There are a number of free or very inexpensive Web servers available that are good for "personal" use or low-volume Web sites. However, with the major exception of Apache, which is free, most commercial-quality Web servers are relatively expensive. Nevertheless, once you have a Web server, no matter the cost of that server, adding servlet support to it (if it doesn't come preconfigured to support servlets) is generally free or cheap.

BEA WebLogic Server 10.0

BEA WebLogic Server is an enterprise-ready Java EE application server that supports the deployment of missioncritical applications in a robust, secure, highly available, and scalable environment. WebLogic Server is an ideal foundation for building applications based on Service Oriented Architectures (SOA).