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.



JDBC 3. 0. JAVA Database Connectivity
JDBC 3: Java Database Connectivity
ISBN: 0764548751
EAN: 2147483647
Year: 2002
Pages: 148

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net