Handbook of Local Area Networks, 1998 Edition:LAN-based Application Development Issues and Solutions
Click Here!
Search the site:
ITLibrary
ITKnowledge
EXPERT SEARCH
Programming Languages
Databases
Security
Web Services
Network Services
Middleware
Components
Operating Systems
User Interfaces
Groupware & Collaboration
Content Management
Productivity Applications
Hardware
Fun & Games
EarthWeb sites
Crossnodes
Datamation
Developer.com
DICE
EarthWeb.com
EarthWeb Direct
ERP Hub
Gamelan
GoCertify.com
HTMLGoodies
Intranet Journal
IT Knowledge
IT Library
JavaGoodies
JARS
JavaScripts.com
open source IT
RoadCoders
Y2K Info
Previous
Table of Contents
Next
Networking Protocol Support for Client/Server
The definition of standardized network protocols has as much to do with the client/server revolution as does the rapid decline in hardware costs. These protocols were the first real products that provided the glue that allowed application segmentation to occur.
In the days of centralized and remote-processing architectures, programmers often had to define and develop their own protocols for making applications work over communications links. These standardized networking protocols free architects, developers, and programmers to think more about the problem to be solved than about the technology underneath it all. They also allow clients to transmit requests to servers and servers to reroute those requests to other servers for handling—transparently to the applications. They also permit communications between networks.
Exhibit 6-3-12 shows the more commonly available and used network protocols mapped as best as can be done to the OSI seven-layer reference model. The seven layers are commonly referred to as a protocol stack. As long as the defined protocols are adhered to, protocol stacks from two different vendors can communicate with one another.
Exhibit 6-3-12. Commonly Used Network Protocols
The OSI reference model, although commonly used to describe networking architectures, is only a set of published standards and not an actual product. The advantage of the layered architecture is that layer 7 on one machine interacts with layer 7 on another machine, and layer 6 with layer 6 and so on up the stack.
As Exhibit 6-3-12 illustrates, not all commonly used protocols map exactly to the OSI seven-layer model. All networking architectures do, however, use a layered structure to delineate between the hardware and software components.
A common characteristic of this layered structure is that, as a general rule, layers know about and can talk to layers immediately above them or below them, but they cannot jump layers in their own architecture. The rules and format for communication between layers are called interfaces. The rules and formats for communication between devices and equivalent layers on another machine are called protocols. Exhibit 6-3-13 illustrates the difference between protocols and interfaces.
Exhibit 6-3-13. Protocol Stack Versus Interface Between Layers
Layer 1 in one protocol stack has an interface to layer 2 in the same stack. Layer 2 in turn also has an interface to layer 3, and so on. Protocols, on the other hand, are designed to provide a framework for communications between two different stacks. They are commonly accepted definitions to which all vendors (if they are to claim they have such a protocol) must adhere when they developed their protocol stack. For example, the Internetwork Protocol in one TCP/IP protocol stack would communicate with the IP protocol in another TCP/IP protocol stack. The second stack could be from the same vendor as the first or a different vendor. It does not really matter as both vendors must have implemented the same IP definition in both their stacks in order to sell their products.
All networking architectures capable of being used in enterprise or global networks need a convention for naming systems and objects within their namespaces. The TCP/IP protocol uses the DNS. ISO uses the X.500 global directory system. The next two subsections examine both methods for naming network-addressable objects.
The Domain Name System
DNS is based on the concept of grouping names into domains. All names of objects within a domain are unique, and all domains are arranged in a tree-line structure that is designed in a top-down fashion. The top-level domain is by country or organization type.
DNS uses nameservers to handle different zones. Each zone begins at a node in the tree and includes all underlying branches. Each nameserver recognizes its neighbor servers above and below. It is customary for each site of an organization to have a primary nameserver along with a backup nameserver in case the primary is unavailable. By knowing its neighbor nameservers, DNS is able to resolve each unique address in a globally connected network such as the Internet in a matter of seconds.
Organizational network administrators are responsible for ensuring that no conflicts exist within the organization’s namespace. The top-level naming conventions are internationally recognized and followed, otherwise the Internet would never work. Systems on Internet networks also have numbered addresses that are cross-linked to the network names that DNS uses.
The X.500 Global Directory Service
X.500 is a global directory service that creates a directory of all network-addressable objects to facilitate communications. The X.500 directory service works equally well with such different objects as system names, e-mail addresses, network-connected devices,data, and application segments. If a network object’s address changes, X.500 allows connectivity to be maintained. Like DNS, X.500 provides a mapping between an object’s name and its network address when applicable, so objects can address other objects by name rather than by network address.
LDAP
Originally developed as a lightweight, TCP/IP-based alternative access protocol for X.500, LDAP is now available as a standalone directory implementation. In this capacity, LDAP has gained considerable popularity over other directory alternatives.
CLIENT/SERVER ADVANTAGES AND DISADVANTAGES
Flexibility
The client/server architecture for systems development offers considerable flexibility compared to the traditional monolithic architecture. The first and perhaps most significant advantage of the client/server architecture is application segmentation.
The split of an application’s logic between the client application and the server application can be decided on a needs basis. In situations in which the logic will be needed by all users or when only a large computer will have the necessary horsepower to complete the task, it would make sense to place that logic in the server application.
It is vitally important to have an enterprisewide architecture that can handle changes in the placement of logic within the client or server applications. Server logic can also be dispersed across a network of servers that work cooperatively. The reasons for placing logic on one or another server today may not be valid in six months time—the design of the system should be able to adapt to such changes. Similarly, when the application segment’s logic is specific to a given user (or user class), it may be better to place it in the client application.
Previous
Table of Contents
Next
Use of this site is subject certain Terms & Conditions.
Copyright (c) 1996-1999 EarthWeb, Inc.. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited.
Please read our privacy policy for details.
Wyszukiwarka
Podobne podstrony:
01 (581)577,24,artykul01 (577)575 577Instrukcja GECO Z 581 P02 S v01 w01 POL581 583Nuestro Círculo 581 Campeona Argentina Mar şa F Fernandez581 583577 (2)SHS 581 661SHS 501 581więcej podobnych podstron