CHARACTERISTICS OF CLIENT / SERVER MODEL A client is defined as a requester of services and a server is defined as the pr ovider of services

A Server is simply a computer that is running software that enables it to serve specific requests from other computers, called clients . The server is normally dedicated because it is optimized to serve requests from the client computers quickl y.

What are types of the Server ? 1. File Servers 2. Database Servers 3. Transaction servers 4. Groupware servers 5. Object Application servers 6. Web Application Servers File Servers: A File Server is a high-speed computer in a network that stores the programs and data files shared by users. It acts like a remote disk drive. The objectives of File Server are: To promote sharing of files. (computer programs and/or data) To encourage indirect or implicit (via programs) use of remote computers. To shield a user from variations in file storage systems among hosts. To transfer data reliably and efficiently. File Transfer Protocol (FTP) for example uses client/server interactions to exchange files between systems. An FTP client requests a file that resides on another system. An FTP server on the system where the file resides handles the client s request. The server gets access to the file and sends the file back to th e client s system. Database Servers A computer in a LAN dedicated to database storage and retrieval. Upon requests f rom the client machines, it searches the database for selected records and passe s them back over the network. A database server and file server may be one and t he same.

With a database server, the client passes SQL requests as messages to the databa se server (see Figure 2-5). The results of each SQL command are returned over th e network. The code that processes the SQL request and the data reside on the sa me machine. The server uses its own processing power to find the requested data instead of passing all the records back to a client and then letting it find its own data, as was the case for the file server. The application code resides o n the client. So you must either write code for the client application or you ca n buy a shrink-wrapped query tool. Database servers provide the foundation for d ecision-support systems that require ad hoc queries and flexible reports. They a lso play a key role in data warehousing. Transaction Servers ( Collection of sql statements are called Transaction) With a transaction server, the client invokes remote procedures (or services) th at reside on the server with an SQL database engine. These remote procedures on

the server execute a group of SQL statements. The network exchange consists of a single request/reply message (as opposed to the database server's approach of o ne request/reply message for each SQL statement in a transaction). The SQL state ments either all succeed or fail as a unit. These grouped SQL statements are cal led transactions. With a transaction server, you create the client/server application by writing t he code for both the client and server components. The client component usually includes a Graphical User Interface (GUI). The server component usually consists of SQL transactions against a database. These applications are called Online Tr ansaction Processing, or OLTP. They tend to be mission-critical applications tha t require a 1 3 second response time 100% of the time. OLTP applications also requ ire tight controls over the security and integrity of the database. Two forms of OLTP will be discussed in this book: TP-Lite, based on the stored procedures pr ovided by database vendors; and TP-Heavy, based on the TP Monitors provided by O LTP vendors. Groupware Servers Groupware addresses the management of semi-structured information such as text, image, mail, bulletin boards, and the flow of work. These client/server systems place people in direct contact with other people. Lotus Notes and Microsoft Exch ange are the leading examples of such systems, although a number of other applic ations including document management, imaging, multiparty applications, and workfl ow are yaddressing some of the same needs. Specialized groupware software can be b uilt on top of a vendor's canned set of client/server APIs. In most cases, appli cations are created using a scripting language and form-based interfaces provide d by the vendor. Typically, the communication middleware between the client and the server is vendor-specific.

However, many groupware products now use e-mail as their standard messaging midd leware. In addition, the Internet is quickly becoming the middleware platform of choice for groupware. Both Netscape and IBM/Lotus are moving their products in this direction. Object Application Servers With an object server, the client/server application is written as a set of comm unicating objects. Client objects communicate with server objects using an Objec t Request Broker (ORB). The client invokes a method on a remote object. The ORB locates an instance of that object server class, invokes the requested method, a nd returns the results to the client object. Server objects must provide support for concurrency and sharing. The ORB and a new generation of CORBA application servers bring it all together. After years of incubation, "real life" commercial ORBs are now in production. Examples of commercial ORBs that comply with the Ob ject Management Group's CORBA standard include Iona's Orbix, Inprise's VisiBroke r, ICL's DAIS, JavaSoft's Java IDL, BEA's ObjectBroker, IBM's SOM, and Expersoft 's PowerBroker. Figure 2-8: Client/Server With Distributed Object. CORBA is also the foundation technology for the Enterprise JavaBeans component m odel. A new generation of CORBA application servers also called Object Transaction Monitors (OTMs) provide server-side component coordination services. Examples of CORBA application servers are BEA's M3, IBM's Component Broker, Oracle's Applica tion Server 4.0, GemStone's GemStone/J, Persistence's PowerTier for EJB, Sun's N etDynamics 4.0, Sybase's Jaguar CTS, and Inprise's forthcoming Application Serve r. However, CORBA is not the only game in town. Microsoft has its own ORB called the Distributed Component Object Model (DCOM). DCOM is the foundation technolog y for Microsoft's enterprise software and also its ActiveX component model. The Microsoft Transaction Server (MTS) is the application server for ActiveX compone

nts. You should note that the latest name for this technology is COM+ (Microsoft also calls it DNA). Web Application Servers The World Wide Web is the first truly intergalactic client/server application. T his new model of client/server consists of thin, portable, "universal" clients t hat talk to superfat servers. In its simplest incarnation, a Web server returns documents when clients ask for them by name (see. The clients and servers commun icate using an RPC-like protocol called HTTP. This protocol defines a simple set of commands; parameters are passed as strings, with no provision for typed data . Figure 2-9: Client/Server With Web Servers. The Web client/server model is evolving. More specifically, the Web and distribu ted objects are starting to come together to provide a very interactive form of client/server computing. We call this new convergence the Object Web. Java apple ts and CORBA-enabled browsers are the first manifestations of this new Object We b. The next step is the componentization of the Web. For example, we are startin g to see the deployment of JavaBeans on the client and Enterprise JavaBeans on t he server. These client and server beans talk to each other via CORBA or HTTP In Microsoft's parallel universe, the Object Web is based on ActiveX components th at communicate via either a COM+ or HTTP pipe. Web application servers are a new class of Internet software. They augment stand ard HTTP servers with server-side component frameworks. Functionally, they are v ery similar to object servers. Soon, you won't be able to tell the difference be tween the two. For example, in the Microsoft world, the MTS distributed object s erver is also the Web application server of choice. MTS is tightly integrated wi th Microsoft's IIS HTTP server; it uses IIS as an HTTP front-end. In the CORBA/J ava world, Enterprise JavaBeans are becoming the common currency of Web applicat ion servers. In addition, most servers manage ordinary CORBA objects. Finally, s ome of these servers also provide COM/CORBA bridges. Examples of CORBA/Java Web application servers are Netscape/Kiva's Application Server, BEA's WebLogic, Blue stone's Sapphire Web, IBM's WebSphere, SilverStream's SilverStream Application S erver 2.0, Novera's jBusiness Application Server, and HAHT's HAHTsite Applicatio n Server 4.0. SQL Database Server Architectures show three server architectures that databases use to handle remote database cli ents: process-per-client, multithreaded, and hybrid. Here are the trade-offs of the three approaches: ? Process-per-client architectures : The process-per client architecture p rovides a separate process for each client requests as show in figure. This mea ns if there are 10 client requests, the database server has to oepn 10 process to communicate with the clients. The advantage of this architecture is that eve ry client has its own process so there is no interference among clients. Exampl es of database servers that implement this architecture include DB2, Informix, a nd Oracle6. ? Multithreaded architectures The second architecture is the multithreaded architecture. Multithreading refer es to the ability of a program or operating system process to provide services t o more than one user or more than one request at a time. All the client request s run in the same process. Multitaksing refers to the capability of performing more than one computer task at a time.

provide the best performance by running all the user connections, applications, and the database in the same address space. This architecture provides its own i nternal scheduler and does not rely on the local OS's tasking and address protec tion schemes. The advantage is that it conserves memory and CPU cycles by not re quiring frequent context switches. In addition, the server implementations tend to be more portable across platforms because they don't require as many local OS services. The disadvantage is that a misbehaved user application can bring down the entire database server and all its tasks. In addition, user programs that c onsist of long-duration tasks (for example, long queries) can hog all the server resources. Finally, the preemptive scheduling provided by the server tends to b e inferior to the native OS's scheduler. Examples of database servers that imple ment this architecture include Sybase and MS SQL Server (SQL Server uses Windows NT's SMP scheduler). ? Hybrid architectures

Request from multiple clients are handled by a multithreaded listner program tha t listens or receives client request and assign them to a dispatcher. The dispa tcher places the client requests in a request queue / response queue. Then the database server takes the reqeust from queue, executes them a shared server pro cess and return thte results back to the queue. The dispatcher queue dequeues t he response from queue and sends it back to the client. consist of three components: 1) multithreaded network listeners that participate in the initial connection task by assigning the client to a dispatcher; 2) disp atcher tasks that place messages on an internal message queue, and then dequeue the response and send it back to the client; and 3) reusable shared server worke r processes that pick the work off the queue, execute it, and place the response on an out queue. The advantage of this architecture is that it provides a prote cted environment for running the user tasks without assigning a permanent proces s to each user. The disadvantages are queue latencies. The first database server to implement this architecture is Oracle7, and it did suffer from queue latenci es. However, it seems that Oracle8 may have fixed this problem; it's a screamer when it comes to performance.

So which architecture is best for client/server? It's a tough choice. The proces s-per-client architectures perform poorly when a large number of users connect t o a database, but they provide the best protection. The multithreaded architectu res can support a large number of users running short transactions, but they do not perform well when large queries are involved. They also do not provide bulle t-proof protection. Hybrid architectures may provide the best balance. However, are they better than using a TP Monitor with a process-per-client database serve r? As a rule of thumb, these architectures don't matter much if you're just doin g simple LAN-based decision support. However, they do matter if you're planning to create a bullet-proof OLTP system. If you're planning the latter, we suggest that you check references carefully and go for the maximum amount of bullet-proo fing. In addition, you should seriously consider using a 3-tier client/server ar chitecture. Typically, your server-side application will run in the middle tier under the control of a TP Monitor or Object Transaction Monitor the database serve r is the third tier (more on this in.

Stored Procedures : A stored procedure is a named collection of SQL statements and procedural logic that is compiled, verified, and stored in the server database. A stored procedu re is typically treated like any other database object and registered in the SQL catalog. Stored procedures accept input parameters so that a single procedure can be used over the network by multiple clients using different input data. The client invokes a remote procedure and passes it the parameters required to do a job. A single remote message can trigger the execution of a collection of store d SQL statements. The result is a reduction of network traffic, which should pro vide better performance. Access to the stored procedure is controlled through the server's security mech anisms. A stored procedure is a group of Transact-SQL statements that is compiled one ti me, and then can be executed many times. This increases performance when the sto red procedure is executed because the Transact-SQL statements do not have to be recompiled. A trigger is a special type of stored procedure that is not called d irectly by a user. When the trigger is created, it is defined to fire when a spe cific type of data modification is made against a specific table or column.A CRE ATE PROCEDURE or CREATE TRIGGER statement cannot span batches. This means that a stored procedure or trigger is always created in a single batch and compiled in to an execution plan. The execution plan is created the first time the stored pr ocedure or trigger is executed. Triggers and Rules: Triggers are special user-defined actions usually in the form of stored procedures t hat are automatically invoked by the server based on data-related events. Trigge rs can perform complex actions and can use the full power of a procedural langua ge. A rule is a special type of trigger that is used to perform simple checks on data. Both triggers and rules are attached to specific operations on specific t ables. In other words, an event tells you something happened to the database; a trigger or rule is an event handler you write to take the proper action in respo nse to that event

Figure 10-6: The Mechanics of SQL Triggers. Triggers and rules are typically used to perform tasks related to changes in tab les, such as auditing, looking for value thresholds, or setting column defaults. Enabled triggers or rules are executed whenever a table is updated by an SQL DE LETE, INSERT, or UPDATE command. A separate trigger or rule can be defined for e ach of these commands, or a single trigger may be defined for any updates to a t able. In general, triggers can call other triggers or stored procedures. So what makes a trigger different from a stored procedure? Triggers are called implicit ly by database generated events, while stored procedures are called explicitly b y client applications. Format Access Protocol Distributed Objects and Components Distributed object technology is extremely well-suited for creating flexible cli ent/server systems because the data and business logic are encapsulated within o bjects, allowing them to be located anywhere within a distributed system.

In addition, distributed objects of the CORBA, Java, and COM+ variety are highly int rospective, which means they can tell you everything about themselves. This allo ws visual tools and other applications to discover an object's interfaces, event s, and properties "on-the-fly." Consequently, distributed objects are very toola ble. Distributed Objects to Components distributed object is a blob of intelligence that can live anywhere on a network . Distributed objects are packaged as independent pieces of code that can be acc essed by remote clients via method invocations. The language and compiler used t o create distributed server objects are totally transparent to their clients. Cl ients don't need to know where the distributed object resides or what operating system it executes on; it can be on the same machine or on a machine that sits a cross an intergalactic network. Distributed objects are smart pieces of software that can message each other tra nsparently anywhere in the world. Distributed objects can interrogate each other " tell me what you do." Distributed objects are very dynamic they come and go and ma y occasionally move around. Definition of:distributed objects Software modules that are designed to work together but reside in multiple comp uter systems in a private network or on the global Internet. A program in one ma chine sends a message to an object in a remote machine to perform some processin g. The results are sent back to the calling machine. Distributed objects over th e Web are known as "Web services." See CORBA, DCOM and Web services. Distributed Objects, CORBA-Style The specifications are written in a neutral Interface Definition Language (IDL) that defines a component's boundaries that is, its contractual interfaces with pot ential clients. You can access IDL-defined components via a CORBA Object Request B roker (ORB) across languages, tools, operating systems, and networks. And with the adoption of the CORBA 2.0 IIOP specification, these components can now interope rate across multivendor CORBA ORBs. What Is a CORBA Distributed Object? CORBA objects are blobs of intelligence that can live anywhere on a network. The y are packaged as binary components that remote clients can access via method in vocations. Both the language and compiler used to create server objects are tota lly transparent to clients. Clients don't need to know where the distributed obj ect resides or what operating system it executes on. It can be in the same proce ss or on a machine that sits across an intergalactic network. In addition, clien ts don't need to know how the server object is implemented. For example, a serve r object could be implemented as a set of C++ classes, or it could be implemente d with a million lines of existing COBOL code the client doesn't know the differen ce. What the client needs to know is the interface its server object publishes. This interface serves as a binding contract between clients and servers