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 The Server A server application is any application that provides centralized services to client applications. The client applications can be pure client applications or applications that themselves act as servers to still other applications. Server applications are generally more complex in their logic and larger than the client applications that use them. They generally run on multiuser systems with preemptive multitasking capabilities, which allows the server applications to handle simultaneous client requests for services. Client applications make requests of server applications via messaging protocols for RPCs. RPCs may be part of the server application software or the communications software and operates in synchronous mode. Messaging and queuing protocols are usually handled by the applications software, although there may be a transaction-processing manager that handles it instead. Both messaging protocols and RPCs are middleware. As mentioned previously, the application logic that is present within a server application is usually, though not always, much more complex than that of the client applications that use its services. The partitioning of logic complexity between the client and the server does, however, depend on the type of service being provided on the server. Example of Partitioning an Application In the sample system discussed here, a server application handles data base requests via SQL queries from client applications. The client application uses a geographic information system (GIS) to construct the query by allowing the user to draw a box or outline on a map background of the area for which data is required. Exhibit 6-3-6 illustrates this GIS client/server example. The client application takes the retrieved data and allows the user to construct complex what-if scenarios or overlay data from different data sets. For example, an urban planner who uses a GIS application may wish to overlay a city's electrical grid with its street grid. In this case, the server application merely provides the access to the data base. The client software is far more complex than the server software. The server software is housed on a larger computer because many users or client applications will wish to access the data base simultaneously. Also, the amount of data that is usually accessed on a server by clients often necessitates a larger computer for the server than for the client. Proper capacity planning can help determine the size and features of both the client and server hardware. In the sample application, the server hardware would likely be tuned for high disk performance and possibly for network performance. The client hardware would likely be tuned for processor and graphics performance. Exhibit 6-3-6.  Geographic Information Systems Looking at the sample GIS client/server system another way, if the GIS application is available for both the client and server platforms and the development team has access to the server hardware before it has access to the client hardware, is there any reason why the team cannot construct the applications for implementation and test them in a full client/server configuration on the server hardware? The answer is, in fact, no. If the server hardware and operating system is capable of running the GIS and data base software, there is no reason why both the client and server applications cannot reside on the same platform. After all, the software architecture was not defined primarily in the context of the hardware on which it was to be executed. Middleware Middleware is defined in terms of the services it provides to allow the client and server applications to communicate with one another. Probably the first real implementation of middleware was the Sun Microsystems TIRPC specification. There are three different classes of middleware products: •  Distributed computing. •  Data base connectivity. •  Transaction managers. Distributed Computing Middleware The purest form of middleware is distributed computing products. Most of the current commercially available distributee computing products are based on the Open Software Foundation’s DCE. DCE provides a framework for distributing applications over heterogeneous systems and networks. A specification for distributing objects is the object request broker (ORB) of the Object Management Group’s CORBA. CORBA provides a means for service applications to be registered with a broker, which then provides access for other applications to look up the registry of available service providers for the one that meets its needs. RPCs and message queuing, already mentioned as examples of middleware, can also be described as distributed computing technologies. Whereas RPCs are based on a synchronous protocol, interprocess communications (IPC) provides asynchronous protocol for client and server applications communications. DCE uses both RPCs and IPCs as part of its architecture (see Exhibit 6-3-7). Exhibit 6-3-7.  RPC and IPC Protocols RPCs are high-level interface for building distributed applications. The two common RPCs in use are Sun’s TIRPC and Open Software Foundation’s RPC, which is built into its DCE. The common components of a general RPC are: •  Binding. •  Registration. •  Transport. •  Data representation. •  Authentication. Binding is similar to typical procedure calls where the caller must bind the procedure call to the actual procedure being called. The only variation is that for a remote procedure call, the caller must specify the remote host and the procedure on that host that is to be bound by the caller. The provider of a remote procedure must advertise its existence and how to bind to it so that potential callers will know how to register. 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.