Java is architecture-neutral, portable, and robust in that it can run on various platforms and anywhere on a network, regardless of which graphic subsystem is in use. Java is independent of hardware, operating systems, and graphical
As discussed in the following sections, there are various places where JDBC can be leveraged to integrate databases. This can be on the client side or on any server tier or integration
However, you shouldn’t underestimate several aspects of integrating with databases. As a developer, you cannot always control all the environmental conditions in which the applications will have to run and behave properly. Here are some of these aspects:
The JDBC driver’s compliance to the standard API
The JDBC driver’s type, which may be fully Java or may use native libraries
Whether the JDBC driver is multithread-safe
The JDBC driver’s capability to tunnel networking protocols through HTTP
The JDBC driver’s naming scheme for databases
The JDBC driver’s and database’s limitations for data types and maximum type sizes
The database locking strategy (row versus page)
is more than a trend or a fashion. The way that systems are designed has matured enough to let most developers abandon the old fat-client, fat-database pattern to the early ages of IT systems (not to mention even dumb terminals and monolithic mainframe applications). N-tiered computing obliges developers to design components according to a business schema that represents entities, relationships, activities, roles, and rules, thereby enabling them to distribute functionality across logical and physical tiers, allowing better utilization of hardware and platform resources, as well as the sharing of those resources and the
Another aspect of splitting tiers is that application
A few examples, which are further elaborated on in this section, are the
Because I’m discussing integrating with databases, I’ll list a few consequences of splitting components across tiers:
Accounting and order-processing components must all access database entities, whether or not they are located on the same logical or physical
Presentation logic components may have to look up tables for reference, decoration, or localization purposes.
Security logic may have to access Access Control Lists (ACLs) residing in tables, in read-only mode.
Logging may be accomplished by using relational database tables to facilitate querying, for example.
Single-logon necessitates the preservation of the connection state across
Back-end integration logic may necessitate looking up credentials/ identifiers in a relational table.
Lots of business logic may have to be reused from legacy stored procedures.
All of the
The most common approach used when designing N-tiered systems is the three-tier architecture. In a three-tier architecture, the application responsibilities are layered as
Supporting various presentation devices, such as HTML browsers, Wireless Application Protocol (WAP) devices, or rich
This excludes all presentation logic, although it is made accessible to the users only via the first tier. Business logic mostly implements business processes, workflow, rules, and such. This tier doesn’t handle database access logic but uses the
Data logic (also called the resource tier ) : This third tier integrates databases by providing, for example, object-relational mapping. It provides a certain degree of data source independence to the other tiers by hiding these integration mechanisms to them.
Three-tier and N-tier notions are similar, although N-tiered architectures provide finer-grained
Ubiquitous database connectivity is definitely needed when developing N-tiered applications that run on many nodes and various operating systems. JDBC really offers everything necessary to achieve this goal. Of course, some of the nice features such as transparent load-balancing and fail-over of access to data components, drag-and-drop deployment of such components, distributed transaction coordination, and so on aren’t provided by JDBC per se. Java 2 Enterprise Edition and J2EE-compliant application servers exist for these purposes.