Flylib.com

Books Software

 
 
 

Write Once, Run Anywhere

Write Once, Run Anywhere

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 user interfaces (GUIs). The design of the Java Virtual Machine (JVM), as well as all the standard and enterprise APIs, makes Java portable — much more portable than C or C++ — which greatly simplifies deployment issues. This is why Java has such presence in the industry. Although there are still a number of issues when porting application code from platform to platform, those issues are minor when compared to the problems of porting C++ code from UNIX to the Macintosh OS, for example, not only for multithreading, networking, or UI aspects, but also when proprietary database APIs come in the picture. JDBC tries to preserve development efforts by abstracting almost all aspects of interfacing programs with relational databases. As a result, it won’t be that hard for a programmer to switch from, say, Oracle to Sybase, or vice versa, or from mSQL to DB2. Java 2 Enterprise Edition and the Enterprise JavaBeans actually benefit from database independence a lot, as a good part of this framework heavily relies on database access.

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 tier — and even on smartcards and Palmtops because lightweight databases are now available on those platforms, too. JDBC is an interface specification designed to be platform independent and is truly portable. Depending on what is done at the application side and how it is done, the whole may be fully or partially portable. You won’t be necessarily constrained to use the very basic features of relational databases to build portable applications. Indeed, JDBC’s coverage is broad enough to provide naming, connection, querying, transaction management, type mapping, database metadata, cursors , and several other facilities in a totally database-independent manner. It is up to database vendors and third parties to implement fully compliant drivers for specific databases.

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)

N-tiered Computing

N-tiered computing 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 components that they support to serve several large applications at the same time.

Another aspect of splitting tiers is that application deployers and administrators are able to identify bottlenecks and throw hardware at them to enable load-balancing and fail-over of certain nodes.

A few examples, which are further elaborated on in this section, are the splits made between application logic components, security logic and presentation logic, computational-intensive and I/O- intensive components, and so on.

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 tier .

  • 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 requests to functions of the whole system; this may happen in a session table, also featuring a session timeout using timestamps.

  • 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 preceding may have to be performed in one single transaction.

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 follows :

  • Presentation logic: Supporting various presentation devices, such as HTML browsers, Wireless Application Protocol (WAP) devices, or rich clients , should not affect the whole application. This is the reason why code related to presentation is usually designed as components separate from the rest of the application.

  • Business logic: 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 next tier when data sources need to be accessed.

  • 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 layers . Architects often decide to lay out much more than three tiers to deploy services: An infrastructure that supports three-tier is often made of several machines and services whose functionalities aren’t part of the three-tier design (Web servers and Public Key Infrastructure [PKI] servers, for example).

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.