Notes(MWT)

MIDDLE-WARE TECHNOLOGIES


1 CLIENT / SERVER CONCEPTS Client Server File Server, Database server, Group server, Object server, Web server .Middleware General middleware Service specific middleware. Client / Server Building blocks RPC Messaging Peer to- Peer. 2 EJB ARCHITECTURE EJB EJB Architecture Overview of EJB software architecture View of EJB Conversation Building and Deploying EJBs Roles in EJB. 3. EJB APPLICATIONS EJB Session Beans EJB entity beans EJB clients EJB Deployment Building an application with EJB. 4. CORBA CORBA Distributed Systems Purpose - Exploring CORBA alternatives Architecture overview CORBA and networking model CORBA object model IDL ORB - Building an application with CORBA. 5. COM COM Data types Interfaces Proxy and Stub Marshalling Implementing Server / Client Interface Pointers Object Creation, Invocation , Destruction Comparison COM and CORBA Introduction to .NET Overview of .NET architecture Marshalling - Remoting. TEXT BOOKS 1. Robert Orfali, Dan Harkey and Jeri Edwards, The Essential Client/Server Survival Guide, Galgotia Publications Pvt. Ltd., 2002. (Unit 1) 2. Tom Valesky, Enterprise Java Beans,Pearson Education, 2002.(Unit 2 & 3) 3. Jason Pritchard, COM and CORBA side by side, Addison Wesley, 2000 (Unit 4 & 5) 4. Jesse Liberty, Programming C#, 2nd Edition, OReilly Press, 2002. (Unit 5) REFERNCES 1. Mowbray,Inside CORBA, Pearson Education, 2002. 2. Jeremy Rosenberger, Teach yourself CORBA in 14 days, Tec media, 2000.

CONTENTSUNIT I CHAPTER - 1 CLIENT / SERVER ARCHITECTURE1.1 1.2 1.3 1.4 1.5 1.6 1.7 INTRODUCTION LEARNING OBJECTIVES EVOLUTION OF CLIENT / SERVER ARCHITECTURE CLIENT / SERVER MODEL CHARACTERISTICS OF CLIENT / SERVER MODEL CLIENT/SERVER ARCHITECTURE IN THE WEB TYPES OF SERVERS 1.7.1 File Server 1.7.2 Database Server 1.7.3 Application Server 1.7.4 Web Server 1.7.5 Object Server 1.7.6 Other Types of Servers 1.8 TYPES OF CLIENT/SERVER MODELS 1.8.1 Two-tier Model 1.8.2 Three-tier Model 1.8.3 Multi-tier Model ADVANTAGES/DISADVANTAGES OF CLIENT/SERVER MODEL 1.9.1 Advantages 1.9.2 Disadvantages CONCLUTION 1 1 1 2 3 7 9 9 10 10 10 12 13 14 15 16 18 20 20 20 20

1.9

1.10

CHAPTER - 2 REMOTE PROCEDURE CALL / PEER-TO-PEER2.1 2.2 2.3 INTRODUCTION LEARNING OBJECTIVES REMOTE PROCEDURE CALL 2.3.1 RPC Overviewi

24 24 24 24

2.3.2 How RPC Works 2.3.3 ONC RPC Protocol 2.3.4 RPC Implementation Issues 2.3.5 Other Features of RPC 2.3.6 RPC Application Development 2.3.7 RPC Usage Considerations 2.3.8 XML-RPC 2.4 PEER-TO-PEER 2.4.1 Peer-To-Peer Network 2.4.2 Advantages of P2P Systems 2.4.3 P2P Challenges 2.4.4 Comparison of Client/Server & Peer-To-Peer CONCLUSION

26 28 30 34 36 38 38 39 40 42 43 43 44

2.5

CHAPTER - 3 MIDDLE-WARE3.1 3.2 3.3 3.4 3.5 3.6. INTRODUCTION LEARNING OBJECTIVES EVOLUTION TOWARDS MIDDLEWARE MIDDLEWARE ARCHITECTURE / SERVICES REQUIREMENTS OF MIDDLEWARE TYPES OF MIDDLEWARE 3.6.1 Transactional Middleware 3.6.2 Message-Oriented Middleware 3.6.3 Procedural Middleware 3.6.4 Object and Component Middleware 3.6.5 ODBC and JDBC 3.6.6 Web Services (Introduction) 3.7 CONCLUSION 48 48 48 52 56 62 63 66 69 72 76 77 78

UNIT II CHAPTER - 4 EJB ARCHITECTURE4.1. 4.2. INTRODUCTION LEARNING OBJECTIVESii

83 83

4.3. 4.4. 4.5. 4.6

THE HISTORY OF EJB EJB OVERVIEW EJB TECHNOLOGY DESIGN GOALS EJB ARCHITECTURE 4.6.1 Bean Class 4.6.2 Remote Interface 4.6.3 Home Interface 4.6.4 Deployment Descriptors 4.6.5 EJB Server 4.6.6 EJB Container 4.6.7 Java Naming and Directory Interfaces 4.6.8 EJB Object 4.6.9 Home Object 4.6.10 JAR Files THE EJB ECOSYSTEM 4.7.1 The Bean provider 4.7.2 The Application Assembler 4.7.3 EJB Deployer 4.7.4 The System Administrator 4.7.5 The Application Server 4.7.6 The Tool Vendors EJB 3.0 SPECIFICATIONS HIGHLIGHTS ENTERPRISE BEANS AS DISTRIBUTED OBJECTS EJB ARCHITECTURE VIEWS 4.10.1 The clients view of an EJB is defined strictly by interfaces 4.10.2 EJBs are isolated and supported by an EJB container ADVANTAGES OF USING EJB DISADVANTAGES OF USING EJB CONCLUSION

83 84 86 87 88 88 88 88 89 90 92 92 93 94 94 94 95 95 95 96 96 97 99 101 101 102 102 105 105

4.7

4.8 4.9 4.10

4.11 4.12 4.13

CHAPTER - 5 BUILDING AND DEPLOYING EJB5.1 5.2 5.3 5.4 INTRODUCTION LEARNING OBJECTIVES EJBS ROLES TYPES OF BEANSiii

110 110 110 113

5.4.1 5.4.2 5.4.3 5.5

Session Bean Entity Bean Message-Driven Bean

115 116 118 119 120 122 123 124 125 127 129 130 131 133 133 136 137 138 140

THE LIFE CYCLES OF ENTERPRISE BEANS 5.5.1 Stateful Session Bean 5.5.2 Stateless Session Bean 5.5.3 Entity Bean 5.5.4 Message-Driven Bean EJB USAGE DEVELOPING AN EJB COMPONENT 5.7.1 5.7.2 5.7.3 5.7.4 5.7.5 5.7.6 5.7.7 5.7.8 The Remote Interface The Local Interface The Home Interface The Local Home Interface The Bean class The Deployment Descriptor The Ejb-jar File Deploying the Bean

5.6 5.7

5.8

CONCLUTION

UNIT III CHAPTER - 6 EJB APPLICATIONS6.1 6.2 6.3 INTRODUCTION LEARNING OBJECTIVES SESSION BEANS 6.3.1 6.3.2 6.4 Stateless Session Beans Stateful Session Beans 145 145 145 148 157 166 166 169 176 177 178 179iv

ENTITY BEANS 6.4.1 Features of Entity Beans 6.4.2 Entity Bean Code Example DEPLOYMENT 6.5.1 Deployment Descriptor Class 6.5.2 The Accesscontrolentry Class 6.5.3 The Controldescriptor Class

6.5

6.5.4 6.5.5 6.5.6 6.6

The Sessiondescriptor Class The Entitydescriptor Class EJB 3.0 Deployment

180 180 181 181

CONCLUSION

UNIT IV CHAPTER - 7 CORBA7.1 7.2 7.3 INTRODUCTION TO CORBA LEARNING OBJECTIVES THE HISTORY OF CORBA 7.3.1 7.3.2 7.4 7.5 7.6 Object Management Group (OMG) Corba 185 185 186 186 186 187 189 191 195 195 196 196 196 197 197 198 198 198 199 199 199 200 200 201 202 203 205

OMA REFERENCE MODEL OVERVIEW OF CORBA OBJECT REQUEST BROKER ARCHITECTURE 7.6.1 7.6.2 7.6.3 7.6.4 7.6.5 7.6.6 7.6.7 7.6.8 7.6.9 7.6.10 7.6.11 7.6.12 7.6.13 7.6.14 Object Request Broker Clients Object Implementations Object References OMG Interface Definition Language Mapping of IDL to Programming Languages Client Stubs Dynamic Invocation Interface Implementation Skeleton Dynamic Skeleton Interface Object Adaptors ORB Interface Interface Repository Implementation Repository

7.7 7.8 7.9 7.10 7.11

EXAMPLE ORBS STRUCTURE OF A CLIENT STRUCTURE OF AN OBJECT IMPLEMENTATION STRUCTURE OF AN OBJECT ADAPTER PORTABLE OBJECT ADAPTERv

7.11.1 7.11.2 7.11.3 7.11.4 7.12 7.13 7.14 7.15

POAArchitecture POA Policies The POA Semantics Object Reference Creation

206 209 210 211 212 213 214 231 232 232 234 235 240 240 241 241 241 241 242 242 243 245 245

7.16 7.17

7.18

7.19

THE INTEGRATION OF FOREIGN OBJECT SYSTEMS THE CORBA NETWORKING /COMMUNICATION MODE CORBA HELLO WORLD EXAMPLE THE CORBA OBJECT MODEL 7.15.1 Object Distribution 7.15.2 Object References 7.15.3 Basic Object Adapters (BOAs) THE CORBA COMPONENT MODEL (CCM) CORBAALTERNATIVES 7.17.1 Socket Programming 7.17.2 Remote Procedure Call (RPC) 7.17.3 OSF Distributed Computing Environment (DCE) 7.17.4 Microsoft Distributed Component Object Model (DCOM) 7.17.5 Java Remote Method Invocation (RMI) INTERFACE DEFINITION LANGUAGE 7.18.1 Lexical Conventions 7.18.2 Literals 7.18.3 Pre-Processing CONCLUSION

UNIT V CHAPTER - 8 COMPONENT OBJECT MODEL (COM)8.1 8.2 8.3 INTRODUCTION LEARNING OBJECTIVES COM OVERVIEW 8.3.1 COM Evolution 8.3.2 Component Benefits 8.3.3 What is not COM ? 8.3.4 Weaknesses of COM 8.4 COM COMPONENTSvi

251 251 252 252 253 254 254 254

8.4.1 8.4.2 8.4.3 8.4.4 8.4.5 8.5 8.6

COM Fundamentals Binary Standards Interfaces COM Data Types Automation Data Types

256 257 257 258 259 262 264 264 267 268 269 269 272 274 274 275 277 277 278 278 279 280 280 280 287 289 290 292 293 293 296 296 298 300 300 300

A DISTRIBUTED OBJECT EXAMPLE INTERFACES 8.6.1 8.6.2 8.6.3 8.6.4 8.6.5 8.6.6 Attributes of Interfaces Globally Unique Identifiers (GUIDs) An Example for Interface Iunknown Query Interface Behind the Interface

8.7

PROXY AND STUB 8.7.1 Remote Method Invocation 8.7.2 COM Proxies and Stubs SERVERS IN EXE 8.8.1 Different Processes 8.8.2 Local Procedure Call (LPC) MARSHALING CLIENT / SERVER IMPLEMENTATION 8.10.1 Creating the Component 8.10.2 Exploring a Function from a DLL 8.10.3 Loading the DLL

8.8

8.9 8.10

8.11 CLASS FACTORY 8.11.1 Object Creation Process 8.11.2 Sample Code Explanation 8.12 INTRODUCTION TO NET PLATFORM 8.12.1 .Net Framework Overview 8.12.2 Net Framework Architecture MARSHALING IN .NET 8.13.1 Application Domains 8.13.2 Creating and Using App Domains 8.13.3 Marshaling Across App Domain Boundaries 8.13.4 Understanding Marshaling With Proxies 8.13.5 Specifying the Marshaling Methodvii

8.13

8.14

8.15 8.16 8.17 8.18

REMOTING IN NET 8.14.1 Understanding Server Object Types 8.14.2 Specifying a Server with an Interface 8.14.3 Building a Server 8.14.4 Building the Client 8.15.5 Using Single Call ADVANTAGES OF USING COM DISADVANTAGES OF USING COM COMPARISON OF COM AND CORBA CONCLUSION

307 308 308 309 312 315 316 317 317 322

viii


UNIT I

NOTES

CHAPTER - 1CLIENT / SERVER ARCHITECTURE1.1 INTRODUCTION The actual client/server model started gaining acceptance in the late 1980s. The term client/server was first used in the 1980s in reference to personal computers (PCs) on a network. The client/server software architecture provides a versatile, messagebased and modular infrastructure that is intended to improve usability, flexibility, interoperability and scalability as compared to centralized, mainframe, time sharing computing. This unit introduces the reader to the client / server architecture. The usage and functionality of the different types of servers : File server, Database server, Group server and more recently the Object server have been explained. This unit covers the different types of client / server models which have been illustrated using examples. 1.2 LEARNING OBJECTIVES At the end of this unit, the reader must be familiar with the following concepts: Evolution of client / server architecture Client / Server architecture Characteristics of client / server model Different types of servers Client / server on the Internet Different types of client/server models 1.3 EVOLUTION OF CLIENT / SERVER ARCHITECTURE Before the advent of client / server architecture, computing environments consisted of mainframes hooked to dumb terminals that only did processing at the mainframe. In mainframe software architectures all intelligence (processing, data) was within the central host computer. Users interacted with the host through a terminal that captures keystrokes and sends that information to the host. As the number of users increased, the power of the mainframes had also to increase to cope with the increased processing requirements and1

NOTES

user connectivity. This era saw the development of very powerful mainframe computers capable of immense processing power and providing support to hundreds of users. Computers were generally large, costly systems owned by large corporations, universities, government agencies and similar-sized institutions. The advent of Personal Computers (PC)s saw drastic changes in the computing scenario. Personal computers are normally operated by one user at a time to perform such general purpose tasks such as word processing and data anlysis using spreadsheet software. PCs were also widely used for multimedia applications and other entertainment like games. The software industry provided a wide range of products for use in personal computers, targeted at both the expert and the nonexpert user. Like the telephone, automobile, and television before it, the PC changed the way people communicate, shop, retrieve information and entertain themselves. The personal computers started to replace these dumb terminals but the processing continued to be done on the mainframe. The improved capacity of personal computers were largely ignored or used on an individual level. With so much computing power idle, many organizations started thinking about sharing, or splitting, some of the processing demands between the mainframe and the PC. Client/server technology evolved out of this movement for greater computing control and more computing value. Client/server refers to the way in which software components interact to form a system that can be designed for multiple users. This technology is a computing architecture that forms a composite system allowing distributed computation, analysis, and presentation between PCs and one or more larger computers on a network. Each function of an application resides on the computer most capable of managing that particular function. There is no requirement that the client and server must reside on the same machine. In practice, it is quite common to place a server at one site in a local area network (LAN) and the clients at the other sites. The client, a PC or workstation, is the requesting machine and the server, a LAN file server, mini or mainframe, is the supplying machine. Clients may be running on heterogeneous operating systems and networks to make queries to the server(s). 1.4 CLIENT / SERVER MODEL Client/server describes the relationship between two computer programs in which one program, the client, makes a service request from another program, the server, which fulfills the request. The client/server idea can be used by programs within a single computer, but finds greater application of the idea in a network. In a network, the client/server model provides a convenient way to interconnect programs that are distributed efficiently across different locations.

2


Businesses of various sizes have various computing needs. Larger businesses may therefore need to use more computers than smaller businesses do. This type of architecture provides a division of labor for the computing functions required by a large business. Under the structure of the client-server architecture, a businesss computer network will have a server computer, which functions as the brains of the organization, and a group of client computers, which are commonly called workstations. The server part of the client- server architecture will be a largecapacity computer, perhaps even a mainframe, which supports multiple uses and has usually a large amount of data and functionality stored on it. The client portions of the client-server architecture are smaller computers that employees use to perform their computer-based responsibilities. Servers commonly contain data files and applications that can be accessed across the network by workstations or employee computers. The server can be used to store the organizations data which could be accessed by the client computers. For example, client requests for files from servers may be implemented using the File Transfer Protocol (FTP). The server is not used just for storage only. Many networks have a clientserver architecture in which the server acts as a processing power source as well. In this scenario, the client computers are virtually plugged in to the server and gain their processing power from it. In this way, a client computer can simulate the greater processing power of a server without having the requisite processor stored within its framework. Alternatively, the clients may also access applications available in the server. Examples of such applications are numerous; among the most popular are word processors, spreadsheets. The client/server model has become one of the central ideas of network computing. In a true client / server environment, both clients and servers must share in the business processing. Most business applications being written today use the client/server model. In the usual client/server model, one server is developed and activated to await client requests. Typically, multiple client programs share the services of a common server program. Both client programs and server programs are often part of a larger program or application. 1.5 CHARACTERISTICS OF CLIENT / SERVER MODEL A client is defined as a requester of services and a server is defined as the provider of services. Figure 1.1 illustrates a simple client-sever architecture.

NOTES

3

NOTESClient initiates request

Server services request

SERVER

CLIENT

Figure 1.1 Client / Server Model 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 quickly. Any normal desktop or personal computer can act as a server. The server can range in size from PCs to mainframes. However standard server hardware normally includes: Support for large amount of RAM Fast input and output Fast network cards Ability to support multiple processors Support for fault tolerance Some of the important characteristics of a client / server architecture are: Asymmetrical protocols: there is a many-to-one relationship between clients and a server. Clients always initiate a dialog by requesting a service. Servers wait passively for requests from clients. Encapsulation of services: the server is a specialist which determines how a client request has to be serviced. Servers can be upgraded without affecting clients as long as the published message interface used by both is unchanged. Location transparency: the server is a process that can reside on the same machine as a client or on a different machine across a network. Client/server software usually hides the location of a server from clients by redirecting service requests. A program can be a client, a server, or both. Message-based exchanges: clients and servers are loosely-coupled processes that can exchange service requests and replies using messages.

4


Modular, extensible design: the modular design of a client/server application enables that application to be fault-tolerant. In a fault-tolerant system, failures may occur without causing a shutdown of the entire application. In a faulttolerant client/ server application, one or more servers may fail without stopping the whole system as long as the services offered on the failed servers are available on servers that are still active. Another advantage of modularity is that a client/server application can respond automatically to increasing or decreasing system loads by adding or shutting down one or more services or servers. Platform independence: the ideal client/server software is independent of hardware or operating system platforms, allowing you to mix client and server platforms. Clients and servers can be deployed on different hardware using different operating systems, optimizing the type of work each performs. Scalability: client/server systems can be scaled horizontally or vertically. Horizontal scaling means adding or removing client workstations with only a slight performance impact. Vertical scaling means migrating to a larger and faster server machine or adding server machines. Separation of Client/Server Functionality: client/server is a relationship between processes running on the same or separate machines. A server process is a provider of services. A client is a consumer of services. Client/server provides a clean separation of functions. Shared resources: one server can provide services for many clients at the same time, and regulate their access to shared resources. The server can additionally provide many benefits including: Optimization : Server hardware is designed to service client requests quickly and efficiently Centralization: Files and data available in a central location for common and easy access by multiple clients. This also results in cheaper maintenance. Data Integity : Since the data is centralized, it facilitates maintenance of data integrity (accuracy and completeness) Security : Multiple levels of permission and security of access by different clients Back-up : Data and files can be backuped up and restored quickly in case of problems Client/server networking focuses primarily on the applications rather than the hardware. The same computer can function as a server and client. Also the same machine can function as both a client and a server depending on the software configuration. Computer transactions using the client/server model are very common. To be a true client/server environment, both client and server must share in the business transaction processing. A typical client transaction could be to check balance of a bank account. A program in the client computer would forward the request of the

user to the main server at

NOTES5

NOTES

the bank. The request would be serviced by a server program in the main server and the information is returned to the client which displays the information to the user. To consider a more complex scenario as illustrated in Figure 1.2: 4

1CLIENT

2 3

MAIN SERVER

Figure 1.2 Client / Server Transaction Processing 1. The client program in the user PC could forward the users request to the banks main server 2. The server program at the banks main server would in turn forward the request to its own client program that sends a request to a database server at another computer to retrieve the account balance 3. The server program at the database server would service the client request from the banks main server and return the account balance to the banks main server client 4. The banks main server program in turn serves it back to the client in the users personal computer, which displays the information. In the above example, the bank main server acts as both client and server to process the user request for knowing the bank account balance. The functions of the Client and Server have been summarized and given below: Client Initiates requests Waits for and receives replies Can connect to several servers at the same time Typically interacts directly with end-users using a graphical user interface

6


Server Waits for requests from clients Upon receipt of requests, processes them and then serves replies Usually accepts connections from a large number of clients Typically does not interact directly with end-users 1.6 CLIENT/SERVER ARCHITECTURE IN THE WEB

NOTES

The World Wide Web (WWW) or the Web as it is called revolves around the client/ server architecture. The client computer system uses browsers like Internet Explorer, Netscape Navigator and Mozilla etc. to interact with the Internet servers using protocols. These protocols help in the accurate transfer of data through requests from a browser and responses from the server. There are many protocols available on the Internet. Commonly used protocols in the web are: HTTP (Hyper Text Transfer Protocol) used to transfer web pages and files contained in web pages such as images. FTP (File Transfer Protocol) used for transferring files from one computer to another. SMTP (Simple Mail Transfer Protocol) used for email. Three models have been used to examine the client/server communication on the web using HTTP. Figure 1.3 shows the client / server architecture for delivering static HTML pages on the Web.

Figure 1.3 Client / Server Architecture Static HTML pages The client program (browser) requests for an HTML file stored on the remote server. The server program which processes the client request locates this file and passes it to the client. The client program then displays this file on the client machine. In this case, the HTML page is static. Static pages do not change until the developer modifies them.

7

NOTES

Figure 1.4 shows the client / server architecture for delivering dynamic web pages using CGI script. The content of such web pages will depend on the user input.

Figure 1.4 Client / Server Architecture Dynamic HTML pages The Common Gateway Interface (CGI) is a standard for interfacing external applications with information servers, such as HTTP or Web servers. A plain HTML document that the Web daemon (server program) retrieves is static, which means it exists in a constant state: a text file that doesnt change. A CGI program, on the other hand, is executed in real-time, so that it can output dynamic information. CGI program can be used to generate dynamic web pages. For example, suppose a web page has a search option to look up information and the word computers is typed in as the search query. The client browser will send the request to the server. The server checks the headers and locates the necessary CGI program and passes it the data from the request including your search query computers. The CGI program processes this data and returns the results to the server. The server then sends this formatted in HTML to your browser which in turn displays the HTML page. Thus the CGI program generates a dynamic HTML page. The contents of the dynamic page depend on the query passed to the CGI program. The third model illustrated in Figure 1.5 also involves dynamic response to users request. In this model, dynamic response is generated by the use of server side technologies

Figure 1.5 Client / Server Architecture Server-side Scripting

8


Server-side scripting is a web server technology in which a users request is fulfilled by running a script directly on the web server to generate dynamic HTML pages. It is usually used to provide interactive web sites that interface to databases or other data stores. The web page is generated using data retreived from such data stores as per user query. There are many technologies available for server-side scritpting. These include Active Server Pages (ASP) and ASP.NET from Microsoft, JavaServer Pages (JSP), a Java- based system for embedding Java-related code in HTML pages, PHP a widely-used general-purpose scripting language for embedding code into HTML page and other commercial systems like ColdFusion. 1.7 TYPES OF SERVERS 1.7.1 File Server 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 client / server architecture for File Server is given in Figure 1.5.

NOTES

Figure 1.6 Client / Server Architecture File Server 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 clients request. The server gets access to the file and sends the file back to the clients system.

9

NOTES

1.7.2 Database Server A computer in a LAN dedicated to database storage and retrieval. The database server is a key component in a client/server environment. It holds the Database Management System (DBMS) and the databases. Upon requests from the client machines, it searches the database for selected records and passes them back over the network. A database server and file server may be one and the same, because a file server often provides database services. However, the term implies that the system is dedicated for database use only and not a central storage facility for applications and files. A sample example to illustrate the use of database server is given in Figure 1.7. A team of software professionals developing an information system will share a common database to create their schema, programs and documents. The workgroup members use PCs that are linked by the way of a local area network (LAN). The database is managed by a computer, called database server, which is part of the network. Data is retrieved from the database by the database server as per user request. Depending on the size of the organization, either a single database server or multiple database servers could also be used to service users requests. Depending on the business requirement, individual database servers could be used for each department. For a marketing department the database would store data concerning customers, order, sales persons etc. Such departmental database servers would be linked to enable access to data stored in any of the Servers from anywhere in the organization.

Figure 1.7 Client / Server Architecture Database Server 1.7.3 Application Server The difference between a file / database server and an application server, is that the file server stores the programs and data, while the application server runs the programs and processes the data.

10


In a two-tier client/server environment, which is most common, the users machine performs the business logic as well as the user interface, and the server provides the database processing. In a three-tier environment, a separate computer (application server) performs the business logic and some data access, although some part may still be handled by the users machine. Application servers are typically used for complex transaction-based applications. An application server in a three-tier client/server environment provides middle tier processing between the users machine and the database management system (DBMS). Two and three tier architecture is explained in greater detail in section 1.8. 1.7.4 Web Server A Web server is a computer system that delivers Web pages to browsers and other files to application via the HTTP protocol. It includes the hardware, operating system, Web server software, Communication protocols like TCP/IP protocol and site content (Web pages and other files) as shown in Figure 1.8.

NOTES

Figure 1.8 Client / Server Architecture Web Server Web servers traditional function has been to serve static HTML and more recently XML. A web server serves web pages to clients across the Internet or an Intranet. If the Web server is used internally and not by the public, it may be called an intranet server. The web server hosts the pages, scripts, programs, and multimedia files and serves them using HTTP. Uniform Resource Locator (URL) is a string of characters which represent a pointer to a resource available in the Web. A common way to get to a Web site is to enter the URL of its home page file in the Web browsers address line. For example, if the URL http://

11

NOTES

www.servername.com/index.html is requested by a client, this would be translated into a connection to www.servername.com using HTTP protocol. The web server will locate the file index.html and send it to the client. Any computer can be turned into a Web server by installing server software and connecting the machine to the Internet. Many different servers are in use on the Internet. Some of the more popular ones are: Apache Free open source server Internet Information Server (IIS) Microsofts web server Netscape Enterprise Server Popular server

Web servers also have the capability of logging information like client requests and server responses. The log files can be analyzed to collect statistics on client requests. Many public web servers also implement features such as: Verifying the identity of the client before allowing access to web content Support for both static and dynamic content delivery by supporting one or more standard interfaces like CGI, PHP, ASP, etc. Security to allow the web contents to be encrypted and sent to the clients using protocols such as HTTPS (HTTP over Secure Socket Layer (SSL)) Content compression to reduce the size of the responses for lower bandwidth usage Bandwidth throttling to limit the speed of the responses in order not to saturate the network and to be able to serve more clients.

1.7.5 Object Server Business objects are intelligent components that encapsulate the data and business logic needed to carry out a business function. Business objects provide a way to describe application independent objects like a customer, order, payment or patient. Object Servers are used to make business logic available to different kinds of clients in a distributed environment.An object servers supports support distributed objects and these technologies support interoperability across languages and platforms, as well as enhancing maintainability and adaptability of the system. There are currently two prominent distributed object technologies: Common Object Request Broker Architecture (CORBA) and COM/DCOM (Component Object Model and Distributed COM). These distributed object technologies provide a range of services for component services from services promoting component integration on a single platform to component interaction across heterogeneous networks. The distributed/collaborative enterprise architecture that emerged in 1993 is a software architecture based on Object Request Broker (ORB) technology. It uses shared, reusable

12


business models (not just objects) on an enterprise-wide scale. The benefit of this architectural approach is that standardized business object models and distributed object computing are combined to give an organization flexibility to improve effectiveness organizationally, operationally, and technologically. An enterprise is defined here as a system comprised of multiple business systems or subsystems. More details about CORBA and ORB is given in the later sections of this courseware. 1.7.6 Other Types of Servers There are a number of other servers emerging in todays scenario. To list a few of such servers: Chat Servers Chat servers enable a large number of users to exchange information in an environment similar to Internet newsgroups that offer real-time discussion capabilities. Fax Servers A fax server is an ideal solution for organizations looking to reduce incoming and outgoing telephone resources but that need to fax actual documents. FTP Servers One of the oldest of the Internet services, File Transfer Protocol makes it possible to move one or more files securely between computers while providing file security and organization as well as transfer control. Groupware Servers A GroupWare server is software designed to enable users to collaborate, regardless of location, via the Internet or a corporate Intranet and to work together in a virtual atmosphere. List Servers List servers offer a way to better manage mailing lists, whether they are interactive discussions open to the public or one-way lists that deliver announcements, newsletters, or advertising. Mail Servers Mail servers move and store mail over corporate networks via LANs and WANs and across the Internet.

NOTES

13

NOTES

News Servers News servers act as a distribution and delivery source for the thousands of public news groups currently accessible over the USENET news network. USENET is a worldwide bulletin board system that can be accessed through the Internet or through many online services The USENET contains more than 14,000 forums called newsgroups that cover every imaginable interest group. It is used daily by millions of people around the world. Proxy Servers Proxy servers sit between a client program typically a Web browser and an external server (typically another server on the Web) to filter requests, improve performance, and share connections. Telnet Servers A Telnet server enables users to log on to a host computer and perform tasks as if theyre working on the remote computer itself. 1.8 TYPES OF CLIENT/SERVER MODELS Every client/server application contains three functional units: Presentation logic or user interface (for example, ATM machines) Business logic (for example software that enables a customer to request an account balance) Data (for example, records of customer accounts)

These functional units can reside on either the client or on one or more servers in the application. Depending on the way the application is split, many possible variations of the client / server architecture can occur. Middleware is the set of software used to communicate between the tiers. Client/server architecture can be deployed to meet the processing needs in different situations. Small Business : the client, the middleware software, and most of the business services operate on the same computer system which may be a desktop or even a laptop. Examples of such usage could be small shops, doctors office, dentists office, a home office and a business traveler who frequently works on a laptop computer. Small to Medium Business and Corporate departments: a LAN based single- server deployment may be adequate to meet the information needs. Users of this type of application include small businesses, such as a medical practice with several doctors, a multi-department corporation, or a bank with several branch offices. In14


this type of application, multiple clients talk to a local server. Administration is simple and failures can be detected easily. Large enterprises: multiple servers that offer diverse functionality may be required. Multiple servers can reside on the Internet, intranets, and corporate networks, all of which are highly scalable. Servers can be partitioned by function, resources, or databases, and can be replicated for increased fault tolerance or enhanced performance. This model provides a great amount of power and flexibility. The development of the application, and partitioning of work among the various servers is critical for the successful deployment of this client/server model. 1.8.1 Two-tier Model The two-tier model is the basic client / server model. In a two-tier model, the client talks directly to the server. The user (client) machine commonly performs the business logic as well as the user interface. The server was commonly a database or file server which provided the data needed for the business processing. Alternatively, the business logic can be divided between the client and server as shown in Figure 1.9. File servers and database servers with stored procedures are examples of two-tier architecture. The two tier client/server architecture is a good solution for distributed computing when work groups are defined with small number of users, limited to say about 100 people interacting on a LAN simultaneously. It does have a number of limitations. When the number of users exceeds the LAN limit, the performance begins to deteriorate.

NOTES

Figure 1.9 Two-Tier Client / Server Architecture In the Internet processing environment, the first tier, the client, generally operates on a web browser environment. The server side is the place where the functionality of the

15

NOTES

information service is supported; the information service provides data and responds to user queries. The client / server architecture for this type of environment is given in Figure 1.10. The server side is implemented as a Web Server (Internet In-formation Server IIS, Apache, Tomcat, Java Web Server JWS), operating on different environments (Windows, UNIX, Sun, HP). In this model the server give data to unlimited number of users by statics HTML pages on HTTP written statement.

Figure 1.10 Two-Tier Client / Server Architecture on the Internet 1.8.2 Three-tier Model The three tier architecture emerged to overcome the limitations of the two tier architecture. In the three tier architecture, a middle tier was added between the user system interface client environment and the database management server environment. The business logic can reside in the middle tier, separate from the data and user interface. The client / server with business logic in a separate tier is given in Figure 1.11. In this way, processes can be managed and deployed separately from the user interface and the database. Also, 3-tier systems can integrate data from multiple sources

Figure 1.11 Three -Tier Client / Server Architecture

16


There are a variety of other ways of implementing this middle tier, such as transaction processing monitors, message servers, or application servers. The middle tier can perform queuing, application execution, and database staging. For example, if the middle tier provides queuing, the client can deliver its request to the middle layer and disengage because the middle tier will access the data and return the answer to the client. In addition the middle layer adds scheduling and prioritization for work in progress. The three tier client/server architecture has been shown to improve performance for groups with a large number of users (in the thousands) and improves flexibility when compared to the two tier approach. Flexibility in partitioning can be as simple as dragging and dropping application code modules onto different computers in some three tier architectures. Three tier architecture with transaction processing monitor technology: One way of implementing the three tier architecture is by having a middle layer consisting of Transaction Processing (TP) monitor technology. The TP monitor technology is a type of message queuing, transaction scheduling, and prioritization service where the client connects to the TP monitor (middle tier) instead of the database server. The transaction is accepted by the monitor, which queues it and then takes responsibility for managing it to completion, thus freeing up the client. When the capability is provided by third party middleware vendors it is referred to as TP Heavy because it can service thousands of users. When it is embedded in the DBMS (and could be considered a two tier architecture), it is referred to as TP Lite because experience has shown performance degradation when over 100 clients are connected. TP monitor technology also provides the ability to update multiple different DBMS in a single transaction connectivity to a variety of data sources including flat files, non-relational DBMS, and the mainframe the ability to attach priorities to transactions robust security Using a three tier client/server architecture with TP monitor technology results in an environment that is considerably more scalable than a two tier architecture with direct client to server connection. For systems with thousands of users, TP monitor technology (not embedded in the DBMS) has been reported as one of the most effective solutions. Three tier with message server Messaging is another way to implement three tier architectures. Messages are prioritized and processed asynchronously. Messages consist of headers that contain priority information, and the address and identification number. The message server

connects to

NOTES17

NOTES

the relational DBMS and other data sources. The difference between TP monitor technology and message server is that the message server architecture focuses on intelligent messages, whereas the TP Monitor environment has the intelligence in the monitor, and treats transactions as dumb data packets. Messaging systems are good solutions for wireless infrastructures. Three tier with an application server The three tier application server architecture allocates the main body of an application to run on a shared host rather than in the user system interface client environment. The application server does not drive the GUIs; rather it shares business logic, computations, and a data retrieval engine. Advantages are that with less software on the client there is less security to worry about, applications are more scalable, and support and installation costs are less on a single server than maintaining each on a desktop client. The application server design should be used when security, scalability, and cost are major considerations Three tier with an Object Server Architecture The middle tier can be designed to be an Object Server that clients can interface to access application objects for business processing. The server objects provide an integrated model of the disparate data sources and back-end applications. The client objects can be insulated from the need to know about stored procedures and databases that are present in the third tier. The server objects communicate with the third tier to process and deliver the client requests. Figure 1.12 illustrates a three-tier model in the Internet. The first tier is the web client (browser), the second tier is the Web server and the third tier is the Application server.

Figure 1.12 Client / Web / Database Server 1.8.3 Multi-tier Model Multi-tier models have four or more tiers. Figures 1.13, 1.14 and 1.15 illustrate different types of four tier model over the Internet.

18


NOTES

Figure 1.13 Client / Web / Application / Database Servers

Figure 1.14 Client / Web / Transaction / Database Servers

Figure 1.15 Client / Web / Application / Transaction / Database Servers19

NOTES

1.9 ADVANTAGES / DISADVANTAGES OF CLIENT/SERVER MODEL 1.9.1 Advantages In most cases, a client-server architecture enables the roles and responsibilities of a computing system to be distributed among several independent computers that are known to each other only through a network. This creates an additional advantage to this architecture: greater ease of maintenance. For example, it is possible to replace, repair, upgrade, or even relocate a server while its clients remain both unaware and unaffected by that change. All the data are stored on the servers, which generally have far greater security controls than most clients. Servers can better control access and resources, to guarantee that only those clients with the appropriate permissions may access and change data. Since data storage is centralized, updates to those data are far easier to administer than would be possible when data is distribtued over several peers, each of which are independently managed computer systems. Data updates may need to be distributed and applied to each peer in the network, which is both timeconsuming and error-prone, as there can be thousands or even millions of peers.

Many mature client-server technologies are already available which were designed to ensure security, friendliness of the user interface, and ease of use. It functions with multiple different clients of different capabilities.

1.9.2 Disadvantages Traffic congestion on the network has been an issue since the inception of the client-server paradigm. As the number of simultaneous client requests to a given server increases, the server can become severely overloaded. Under client-server, should a critical server fail, clients requests cannot be fulfilled. Hence, lack of robustness is a cause for concern.

1.10 CONCLUSION In a client / server architecture, clients request information or a service from a server and that server responds to the client by acting on that request and returning the results. The client and server could be on the same computer system or more generally the client and server applications reside on different computer systems accessed over a network. The client and server are two separate devices which can work over a LAN, long-distance WANs or the Internet. This approach to networking has proven to be a cost-effective way to share data between tens or hundreds of clients. Client/server is just one approach to distributed computing. The client/server model has been popular for a long time, but peer-to-peer networking and grid technology have emerged as viable alternatives for distributed computing.

20


HAVE YOU UNDERSTOOD QUESTIONS? a) What is a client / server model? b) How did the client / server architecture evolve? c) What are the roles and functions of client and server? d) What are the important characteristics of the client / server architecture? e) What are the different types of servers and what are the functionalities provided by each type of server? f) What are the different types of client/server models? g) What are the advantages and disadvantages of client/server architecture? SUMMARY In a client/server model (also known as client/server architecture), processing is shared between the client and server The client issues the request and the server services the request The client/server technology has evolved from mainframe computing environment. The advent of PC (of low cost and with processing power) saw the replacement of dumb terminals of mainframes with PCs as clients capable of sharing the processing load. The client and server can be on the same computer or different computer systems. Typically, the client and server are connected over a LAN or WAN using standard communication protocols. The important characteristics of a client / server environment includes location transparency of files, data and application, message-based exchanges and modular extensible designs that can be scaled to support numerous clients and multiple servers. Servers can be classified based on the type of service they provide : File servers, Database servers, Application servers, Object servers etc.

NOTES

Different types of client / server models can be deployed to match the processing needs of an organization or Institution. These are typically 2-tier, 3-tier and multi- tier models. Some of key advantages of client / server architecture include sharing of processing load, sharing of resources between multiple users, easy maintenance and security of access. One of the key disadvantages of client / sever environment is traffic congestion that can be caused in the network due to heavy and simultaneous client requests to the servers Middleware is the software layer that connects the client and server over a network.

21

NOTES

EXERCISES Part I 1. In mainframe environment processing & data handling take place at a) Central host computer c) Local Computer 2. clients a) Only one c) Maximum of three 3. Server commonly contains a) Only system programs c) Only application programs 4. a) Complier c) Browser 5. Web server is accessed using its a) Index.html c) URL 6. a) TCP/IP c) Operating System 7. a) ASP&CGI c) C Language 8. at a) Client c) Web Server 9. a) Client c) middle-Tier software a) Internet explorer c) JSP b) main.html d) Ethernet address b) Application Server d) none b) HTML d) Operating System b) Server d) Client & Server b) Server d) Network b) Mozilla d) Netscape navigator b) Data files, applications d) System software & application programs b) Operating System d) Machine Language Program b) Local host d) None b) Only Two d) Many

Server can interact simultaneously with how many

Client computer system interacts with the Internet servers using the program

Network protocol used to access web server

Client/Server architecture delivers dynamic web pages using

In a client/Server model, business processing is done

For dynamic webpage creation, script is executed at

10. Which of the following is not a browser

22


Part II 11. What are the various functions of Client/Server? 12. What is the difference between file and database servers? 13. What are the objectives of a file server? 14. What are the features of public web servers? 15. Explain the role played by middle tier architecture? Part III 16. What are the benefits provided by the server in client/server model? 17. What are the advantages / disadvantages of client / server model? 18. List out and explain the various types of server? 19. Explain the important characteristics of Client/Server architecture?

NOTES

20. Explain three-tier architecture and the functions of each tier in detail with examples? Part I Answers: 1) a 2) d 3) b 4) c 5) c 6) a 7) a 8) b 9) b 10) d

REFERENCES 1. Websites : http://www.sei.cmu.edu/str/descriptions/clientserver_body.html http:// www.webdevelopersnotes.com/basics/client_server_architecture.php3, wikipedia.org, http://faqs.org/faqs/client-server-faq/

23

NOTES

CHAPTER - 2REMOTE PROCEDURE CALL / PEER-TO-PEER2.1 INTRODUCTION Remote Procedure Call (RPC) is a client/server infrastructure that increases the interoperability, portability, and flexibility of an application by allowing the application to be distributed over multiple heterogeneous platforms. It reduces the complexity of developing applications that span multiple operating systems and network protocols by insulating the application developer from the details of the various operating system and network interfaces. Peer-to-peer, also known by the acronym P2P describes a type of network in which each workstation (peer or computer system) has equivalent capabilities and responsibilities. This differs from client/server architectures, in which some computers are dedicated as servers to service client request. RPC and Peer-to-Peer networking have been explained in this unit. The comparison of peer-to-peer and client /server architecture has been discussed. 2.2 LEARNING OBJECTIVES Overview of Remote Procedure Call How RPC works? RPC Implementation Issues RPC Usage Considerations Peer-to-Peer Networking Common Peer-to-Peer Applications Comparison of Client/Server & PEER-TO-PEER

2.3 REMOTE PROCEDURE CALL 2.3.1 RPC Overview Remote Procedure Call (RPC) is a powerful technique for constructing distributed, client-server based applications. The idea of RPC is quite simple. It is based on the observation that procedure calls are a well-known and well understood mechanism for transfer of control and data within a program running on a single computer to another program. RPC extends this mechanism to provide for transfer of control and data across24


a communication network. Hence, the called procedure need not exist in the same address space as the calling procedure. The two processes may be on the same system, or they may be on different systems with a network connecting them. By using RPC, programmers of distributed applications avoid the details of the interface with the network. The transport independence of RPC isolates the application from the physical and logical elements of the data communications mechanism and allows the application to use a variety of transports. Remote Procedure Call is implemented as a protocol (is a set of rules) that one program (client) can use to request a service from a program (server) located in another computer in a network without having to understand network details. A procedure call is also sometimes known as a function call or a subroutine call. RPC uses the client/server model of distributed computing. An RPC is initiated by the client sending a request message to a known remote server in order to execute a specified procedure using supplied parameters. A response is returned to the client where the application continues along with its process. There can be many variations and subtleties in various implementations of RPC resulting in a variety of different (incompatible) RPC protocols. Some of the well-known and commonly used RPC analogues include: Java Remote Method Invocation (Java RMI) API provides similar functionality to standard UNIX RPC methods XML-RPC is an RPC protocol which uses XML to encode its calls and HTTP as a transport mechanism Microsoft .NET Remoting offers RPC facilities for distributed systems implemented on the Windows platform RPyC (Remote python call) implements RPC mechanisms in Python, with support for asynchronous calls. Routix-RPC technology based on TCP-transport and XML-packets (messages) By using RPC, the complexity involved in the development of distributed processing is reduced by keeping the semantics of a remote call the same whether or not the client and server are co-located on the same system. Like a regular or local procedure call, an RPC is a synchronous operation requiring the requesting program to be suspended until the results of the remote procedure are returned. However, the use of lightweight processes or threads that share the same address space allows multiple RPCs to be performed concurrently.

RPC facilitates communication between client and server processes by allowing a client component of an application to employ a function call to access a server on a remote system. RPC allows the remote component to be accessed without knowledge of the network address or any other lower-level information.

NOTES25

NOTES

2.3.2 How RPC Works An RPC is analogous to a function call. Like a function call, when an RPC is made, the calling arguments are passed to the remote procedure and the caller waits for a response to be returned from the remote procedure. Most RPC implementations use a synchronous, request-reply (sometimes referred to as call/wait) protocol which involves blocking of the client until the server fulfills its request. Asynchronous (call/no wait) implementation of RPC is also available. Figure 2.1 shows the flow of activity that takes place during a synchronous RPC call between two networked systems. In synchronous RPC the thread that issued the RPC call blocks the client until the RPC call is complete.

Figure 2.1 Synchronous RPC 1. Call is issued by the application. 2. The RPC runtime sends the call to the server, on behalf of the client. Meanwhile, the client thread that issued the RPC call is stuck in the RPC runtime waiting for the call to complete.

3. The call is dispatched by the server side RPC runtime. The server application then executes the remote call. 4. Control returns back to the server RPC runtime.

26


5. Server RPC runtime sends the reply to client. 6. The client thread unblocks. The RPC call is complete. Asynchronous Remote Procedure Call (RPC) is an extension of the synchronous RPC mechanism. Asynchronous RPC allows the thread that issued the call to continue execution and pick up the results at a later time. Similarly, on an Asynchronous RPC server the logical RPC call can continue even after the dispatched call returns from the application code into the RPC runtime (manager routine), as shown in Figure 2.2.

NOTES

Figure 2.2 Asynchronous RPC 1. The client submits Asynchronous RPC call. Control returns back to the client thread. The thread is free to continue with other work. 2. RPC runtime sends request to the server, on behalf of the client. 3. Request is dispatched to the server. The server application begins execution of the remote call. Control returns back to the server RPC runtime, but the server side call is not complete. 4. Server completes the call. 5. Reply is sent back to the client. 6. Client is notified that reply has arrived. 7. Client calls back into the RPC runtime and picks up the reply. At this point, the Asynchronous RPC is complete.

27

NOTES

It is useful to use Asynchronous RPC on the client when the remote procedure call takes a while to complete and the client can do other work on the thread before it needs the results of this RPC. The client can also make simultaneous calls to one or more servers. For example, if a client wants to make simultaneous synchronous RPC calls to four servers, it cannot do so with one thread. It has to spin off at least three threads and make an RPC call in each thread. However, if it is using Asynchronous RPC, it can make all four calls on the same thread and then wait for all of them. It is useful to use Asynchronous RPC on the server when the processing of the call will take a long time to complete. Instead of just processing the call in as with synchronous RPC, the server can add it to the work queue and process it later. In synchronous RPC is used, the server will have to start a thread for every RPC call. The server application can notify the client on completion of the task. 2.3.3 Onc RPC Protocol The Open Network Computing (ONC) Remote Procedure Call (RPC) protocol is documented in RFC 1831. It is based on the remote procedure call model. One thread of control logically winds through two processes: the callers (client) process, and a servers process. The caller process first sends a call message to the server process and waits (blocks) for a reply message. The call message includes the procedures parameters, and the reply message includes the procedures results. Once the reply message is received, the results of the procedure are extracted, and callers execution is resumed. On the server side, a process is dormant awaiting the arrival of a call message. When one arrives, the server process extracts the procedures parameters, computes the results, sends a reply message and then awaits the next call message. However, this model is only given as an example. The ONC RPC protocol makes no restrictions on the concurrency model implemented and others are possible. For example, an implementation may choose to have RPC calls be asynchronous, so that the client may do useful work while waiting for the reply from the server. Another possibility is to have the server create a separate task to process an incoming call, so that the original server can be free to receive other requests. There are a few important ways in which remote procedure calls differ from local procedure calls: Error handling: failures of the remote server or network must be handled when using remote procedure calls Global variables and side-effects: since the server does not have access to the clients address space, hidden arguments cannot be passed as global variables or returned as side effects.

28


Performance : remote procedures usually operate one or more orders of magnitude slower than local procedure call Authentication: since remote procedure calls can be transported over unsecured networks, authentication may be necessary. Authentication prevents one entity from masquerading as some other entity. The RPC protocol can be implemented on several different transport protocols like TCP or UDP. The RPC protocol does not care how a message is passed from one process to another, but only with specification and interpretation of messages. However, the application may wish to obtain information about (and perhaps control over) the transport layer through an interface not specified in this document. For example, the transport protocol may impose a restriction on the maximum size of RPC messages, or it may be stream-oriented like TCP with no size limit. The client and server must agree on their transport protocol choices. It is important to point out that RPC does not try to implement any kind of reliability and that the application may need to be aware of the type of transport protocol underneath RPC. If it knows it is running on top of a reliable transport such as TCP then most of the work is already done for it. On the other hand, if it is running on top of an unreliable transport such as UDP, it must implement its own time-out, retransmission, and duplicate detection policies as the RPC protocol does not provide these services. The RPC protocol provides the fields necessary for a client to identify itself to a service, and vice-versa, in each call and reply message. Security and access control mechanisms can be built on top of this message authentication. Several different authentication protocols can be supported. A field in the RPC header indicates which protocol is being used. To summarize RPC protocol implementations must provide for the following: Unique specification of a procedure to be called. Provisions for matching response messages to request messages. Provisions for authenticating the caller to service and vice-versa. Besides these requirements, features that detect the following are worth supporting because of protocol roll-over errors, implementation bugs, user error, and network administration: RPC protocol mismatches Remote program protocol version mismatches. Protocol errors (such as misspecification of a procedures parameters). Reasons why remote authentication failed. Any other reasons why the desired procedure was not called.29

NOTES

NOTES

2.3.4 RPC Implementation Issues RPC provides a simple means for an application programmer to construct distributed programs because it abstracts away from the details of communication and transmission. However, the achievement of true transparency is a problem which needs to be resolved. The following issues regarding the properties of remote procedure calls need to be considered in the design of an RPC system if the distributed system is to achieve transparency. Messages The semantics of RPC are the same as those of a local procedure call. The calling process calls and passes arguments to the procedure and it blocks while the procedure executes. The ONC RPC message protocol consists of two distinct structures: the call message and the reply message. A client makes a remote procedure call to a network server and receives a reply containing the results of the procedures execution. By providing a unique specification for the remote procedure, RPC can match a reply message to each call (or request) message. The RPC message protocol is defined using the eXternal Data Representation (XDR) data description, which includes structures, enumerations, and unions. The initial structure of an RPC message is as follows: struct rpc_msg { unsigned int xid; union switch (enum msg_type mtype) { case CALL; call_body cbody; case REPLY; reply_body rbody; } body; }; All RPC call and reply messages start with a transaction identifier, xid, which is followed by a two-armed discriminated union. The unions discriminant is msg_type, which switches to one of the following message types: CALL or REPLY. The msg_type has the following enumeration: enum msg_type { CALL = 0, REPLY = 1 };

30


The xid parameter is used by clients matching a reply message to a call message or by servers detecting retransmissions. The initial structure of an RPC message is followed by the body of the message. The body of a call message has one form. The body of a reply message, however, takes one of two forms, depending on whether a call is accepted or rejected by the server. The RPC protocol for a reply message varies depending on whether the call message is accepted or rejected by the network server. A call message can be rejected by the server for two reasons: either the server is not running a compatible version of the RPC protocol, or there is an authentication failure. The reply message to a request contains information to distinguish the following conditions: RPC executed the call message successfully. The remote program is not available on the remote system. The remote program does not support the requested version number. The lowest and highest supported remote program version numbers are returned. The requested procedure number does not exist. This is usually a caller-side protocol or programming error. Communication transparency The users should be unaware that the procedure they are calling is remote. The three difficulties when attempting to achieve transparency are: the detection and correction of errors due to communication and site failures the passing of parameters Exception handling Communication and site failures can result in inconsistent data because of partially completed processes. The solution to this problem is often left to the application programmer. Parameter passing in most systems is restricted to the use of value parameters. Exception handling is a problem also associated with heterogeneity. The exceptions available in different languages vary and have to be limited to the lowest common denominator.

NOTES

For example, if a request is sent, but no response is received, what should the requestor do? If the request is blindly retransmitted, the remote procedure might be executed twice (or more) If the request is not retransmitted, the remote procedure might not be executed at all

31

NOTES

It may be possible for some remote procedures to be safely executed twice. Such procedures are said to be idempotent. It is essential that remote procedures must execute with desired behavior. Location of services In a distributed environment, Servers need to advertise their services and clients need to identify compatible servers. Hence some type of Directory Service or Registry services must be implemented for registration and location of available services as shown in Figure 2.4. The RPC runtime can access the Directory Service to locate the server.

Figure 2.4 Location of services Binding Binding provides a connection between the name used by the calling process and the location of the remote procedure. Binding can be implemented, at the operating system level, using a static or dynamic linker extension which binds the procedure name with its location on another machine. Another method is to use procedure variables which contain a value which is linked to the procedure location. The act of binding a particular client to a particular service and transport parameters is NOT part of ONC RPC protocol specification. Both TCP and UDP rely on wellknown port numbers to perform service rendezvous, that is connect to a particular service on the server. For example, TCP TELNET service is available on port 21, FTP on port 23, SMTP on port 25, and so on. Connecting to TCP and UDP services simply requires connecting to the right port number. RPC introduces another step in this process, to divorce services from being tied to a given port number. It does so using a special RPC service called PORTMAPPER or RPCBIND. These binding protocols, documented in RFC 1833 and often referred to as the portmapper, are unique among RPC services since they

have an assigned port of their own

(port 111). Other RPC services, running on any port number, can register themselves using an RPC call to port 111. The portmapper offers32


other RPC calls to permit service lookup. The most important consequence of this design is that the portmapper must be the first RPC program started, and must remain in constant operation Concurrency Concurrency mechanisms should not interfere with communication mechanisms. Single threaded clients and servers, when blocked while waiting for the results from a RPC, can cause significant delays. These delays can be exacerbated by further remote procedure calls made in the server. Lightweight processes allow the server to execute calls from more than one client concurrently. Heterogeneity Different machines may have different data representations, the machines may be running different operating system or the remote procedure may have been written using a different language. Static interface declarations of remote procedures serve to establish agreement between the communicating processes on argument types, exception types (if included), type checking and automatic conversion from one data representation to another, where required. Service Interface In order to allow servers to be accessed by differing clients, a number of standardized RPC systems have been created. Most of these use an interface description language (IDL) to allow various platforms to call the RPC. IDL also known as Interface Definition Language is a specification language used to describe a software components interface. IDLs describe an interface in a language- neutral way, enabling communication between software components that do not share a language for example, between components written in C++ and components written in Java. IDLs are commonly used in remote procedure call software. In these cases the machines at either end of the link may be using different operating systems and computer languages. IDLs offer a bridge between the two different systems. The IDL files can then be used to generate code to interface between the client and server. A common tool used for this is RPCGEN. Hence the requirements for effective RPC implementation can be summarized as follows: Resolve differences in data representation Support a variety of execution semantics Support multi-threaded programming33

NOTES

NOTES

Provide good reliability Provide independence from transport protocols Ensure high degree of security Locate required services across networks

2.3.5 Other features of RPC RPC protocol also supports other features which include: Batching calls Broadcasting calls Callback procedures Authentication

Batching calls Batching allows a client to send an arbitrarily large sequence of call messages to a server. Batching typically uses reliable byte stream protocols, such as TCP/IP, for its transport. When batching, the client never waits for a reply from the server, and the server does not send replies to batched requests. The RPC architecture is designed so that clients send a call message and then wait for servers to reply that the call succeeded. This implies that clients do not compute while servers are processing a call. However, the client may not want or need an acknowledgment for every message sent. Therefore, clients can use RPC batch facilities to continue computing while they wait for a response. Batching can be thought of as placing RPC messages in a pipeline of calls to a desired server. Batching assumes the following: Each remote procedure call in the pipeline requires no response from the server, and the server does not send a response message. The pipeline of calls is transported on a reliable byte stream transport such as TCP/IP.

Because the server sends no message, the clients are not notified of any failures that occur. Therefore, clients must handle their own errors. Because the server does not respond to every call, the client can generate new calls that run parallel to the servers execution of previous calls. Furthermore, the TCP/IP implementation can buffer many call messages, and send them to the server with one write subroutine. This overlapped execution decreases the inter-process communication overhead of the client and server processes as well as the total elapsed time of a series of calls. Batched calls are buffered, so the client should eventually perform a non-batched remote procedure call to flush the pipeline with positive acknowledgment.34


Broadcasting Calls

In broadcast RPC-based protocols, the client sends a broadcast packet to the network and waits for numerous replies. Broadcast RPC uses only packet-based protocols, such as User Datagram Protocol/Internet Protocol (UDP/IP), for its transports. Servers that support broadcast protocols respond only when the request is successfully processed and remain silent when errors occur. Broadcast RPC requires the RPC port map service to achieve its semantics. The port map daemon converts RPC program numbers into Internet protocol port numbers. The main differences between broadcast RPC and normal RPC are as follows: Normal RPC expects only one answer, while broadcast RPC expects one or more answers from each responding machine. The implementation of broadcast RPC treats unsuccessful responses as garbage by filtering them out. Therefore, if there is a version mismatch between the broadcaster and a remote service, the user of broadcast RPC may never know. All broadcast messages are sent to the port-mapping port. As a result, only services that register themselves with their port mapper are accessible through the broadcast RPC mechanism. Broadcast requests are limited in size to the maximum transfer unit (MTU) of the local network. For the Ethernet system, the MTU is 1500 bytes. Broadcast RPC is supported only by packet-oriented (connectionless) transport protocols such as UPD/IP. Call-back Procedures Occasionally, the server may need to become a client by making an RPC callback to the clients process. To make an RPC callback, the user needs a program number on which to make the call. The program number is dynamically generated. Authentication The server may require the client to identify itself before being allowed access to services. Remote Procedure Call (RPC) authentication provides a certain degree of security.

NOTES

RPC deals only with authentication and not with access control of individual services. Each service must implement its own access control policy and reflect this policy as return statuses in its protocol. The programmer can build additional security and access controls on top of the message authentication. The authentication subsystem of the RPC package is open-ended. Different forms of authentication can be associated with RPC clients. That is, multiple types of authentication are easily supported at one time. Examples of authentication types include UNIX, DES, and NULL. The default authentication type is none.

35

NOTES

The RPC protocol provisions for authentication of the caller to the server, and vice versa, are provided as part of the RPC protocol. Every remote procedure call is authenticated by the RPC package on the server. Similarly, the RPC client package generates and sends authentication parameters. The call message has two authentication fields: credentials and verifier. The reply message has one authentication field: response verifier. 2.3.6 RPC Application Development RPC is typically implemented in one of two ways: within a broader, more encompassing propriety product by a programmer using a proprietary tool to create client/server RPC stubs

For example, a client/server application can be developed to lookup a database located on a remote machine. A server has to be established on the remote machine that can respond to queries. The client can retrieve information by sending a query to the remote server for processing and obtaining the reply. To develop an RPC application, therefore the following steps are needed: Specify the protocol for client server communication Develop the client program Develop the server program

The programs will be compiled separately. The communication protocol is achieved by generated stubs and these stubs and RPC (and other libraries) will need to be linked in. When program statements that use RPC are compiled into an executable program, a stub is included in the compiled code to act as the representative of the remote procedure code. When the program is run and the procedure call is issued, the stub receives the request and forwards it to a client runtime program in the local computer. The client runtime program has the knowledge of how to address the remote computer and server application and sends the message across the network that requests the remote procedure. Similarly, the server includes a runtime program and stub that interface with the remote procedure itself. Results are returned the same way. Some of the terms and definitions associated with RPC are: Client: A process such as a program or task that requests a service provided by another program. The client process uses the requested service without having to deal with many working details about the other program or the service. Server: A process, such as a program or task, that responds to requests from a client. Endpoint: The name, port, or group of ports on a host system that is monitored by a server program for incoming client requests. The endpoint is a network-specific address

36


of a server process for remote procedure calls. The name of the endpoint depends on the protocol sequence being used. Endpoint Mapper (EPM): Part of the RPC subsystem that resolves dynamic endpoints in response to client requests and, in some configurations, dynamically assigns endpoints to servers. Client Stub: Module within a client application containing all of the functions necessary for the client to make remote procedure calls using the model of a traditional function call in a standalone application. The client stub is responsible for invoking the marshalling engine and some of the RPC application programming interfaces (APIs). Server Stub: Module within a server application or service that contains all of the functions necessary for the server to handle remote requests using local procedure calls. The sequence of steps of a client / server interchange is depicted in Figure 2.3.

5. The server stub executes a local procedure call to the actual server function, passing it the argument s that it received from the client.

Figure 2.3: Functional steps in a remote procedure call 1. The client calls a local procedure, called the client stub. To the client process, it appears that this is the actual procedure. The client stub packages the arguments to the remote procedure and builds one or more network messages. These complex data structures have to be converted into a format suitable for transmission. The conversion to a standard format and packaging of arguments into a network message is called marshaling. 2. Network messages are sent by the client stub to the remote system (via a system call to the local kernel). 3. Network messages are transferred by the kernel to the remote system via some communication protocol (either connectionless or connection-oriented). 4. A server stub procedure on the server receives the messages. It unmarshals the arguments (reverse of marshaling) from the messages and possibly converts them from a standard form into a machine-specific form. The process

NOTES37

NOTES

6. When the server is finished, it returns to the server stub with its return values. 7. The server stub converts the return values (if necessary) and marshals them into one or more network messages to send to the client stub. 8. Messages get sent back across the network to the client stub. 9. The client stub reads the messages from the local kernel. 10. It then returns the results to the client function (possibly converting them first). The client code then continues its execution in the normal manner. 2.3.7 RPC Usage Considerations RPC is appropriate for client/server applications in which the client can issue a request and wait for the servers response before continuing its own processing. Because most RPC implementations do not support peer-to-peer, or asynchronous, client/server interaction, RPC is not well-suited for applications involving distributed objects or object- oriented programming. Asynchronous and synchronous mechanisms each have strengths and weaknesses that should be considered when designing any specific application. In contrast to asynchronous mechanisms employed by Message-Oriented Middleware, the use of a synchronous request-reply mechanism in RPC requires that the client and server are always available and functioning (i.e., the client or server is not blocked). When utilizing RPC over a distributed network, the performance (or load) of the network should be considered. One of the strengths of RPC is that the synchronous, blocking mechanism of RPC guards against overloading a network, unlike the asynchronous mechanism of Message-Oriented Middleware (MOM). However, when recovery mechanisms, such as retransmissions, are employed by an RPC application, the resulting load on a network may increase, making the application inappropriate for a congested network. Also, because RPC uses static routing tables established at compile-time, the ability to perform load balancing across a network is difficult and should be considered when designing an RPCbased application. 2.3.8 XML-RPC Its a specifications and a set of implementations that allow software running on disparate operating systems, running in different environments to make procedure calls over the Internet. It is a remote procedure call protocol which uses HTTP as the transport and XML (Extensible Markup Language) to encode the calls as shown in Figure 2.8.

38


NOTES

Figure 2.8 XML-RPC XML-RPC is designed to be as simple as possible, while allowing complex data structures to be transmitted , processed and returned. XML-RPC was first created by Dave Winer of UserLand Software in 1998 with Microsoft. As new functionality was introduced, the standard evolved into what is now SOAP (Simple Object Access Protocol). SOAP is a lightweight protocol for exchange of information in a decentralized, distributed environment. It is an XML based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined data types, and a convention for representing remote procedure calls and responses. Within the world of XML there are two main ways to implement a Remote Procedure Call (RPC) XML-RPC and SOAP. SOAP tries to pick up where XMLRPC left off by implementing user defined data types, the ability to specify the recipient, message specific processing control, and other features. 2.4 PEER-TO-PEER The term peer-to-peer (P2P) refers to a class of systems and applications that employ distributed resources to perform a critical function in a decentralized manner. With the pervasive deployment of computers, P2P is increasingly receiving attention in research, product development, and investment circles. P2P is a way to leverage vast amounts of computing power, storage, and connectivity from personal computers distributed around the world. P2P is about sharing: giving to and obtaining from the peer community. A peer gives some resources and obtains other resources in return. Some of the benefits of a P2P approach include: improving scalability by avoiding dependency on centralized points;

39

NOTES

eliminating the need for costly infrastructure by enabling direct communication among clients; and enabling resource aggregation. 2.4.1 Peer-to-Peer Network A pure peer-to-peer network does not have the notion of clients or servers, but only equal peer nodes that simultaneously function as both clients and servers to the other nodes on the network. This model of network arrangement differs from the client-server model where communication is usually to and from a central server as shown in Figure 2.8.

Figure 2.8 Peer-to-Peer Network & Client/server Model A peer-to-peer (P2P) computer network uses diverse connectivity between participants in a network and the cumulative bandwidth of network participants rather than conventional centralized resources where a relatively low number of servers provide the core value to a service or application. Peer-to-peer networks are typically used for connecting nodes via largely ad hoc connections. Such networks are useful for many purposes. Sharing content files (see file sharing) containing audio, video, data or anything in digital format is very common, and realtime data, such as telephony traffic, is also passed using P2P technology. The earliest peer-to-peer network in widespread use was the Usenet news server system, in which peers communicated with one another to propagate Usenet news articles over the entire Usenet network. Particularly in the earlier days of Usenet, UUCP (UNIX to-UNIX Copy) was used to extend even beyond the Internet. However, the news server system also acted in a client-server form when individual users accessed a local news server to read and post articles. P2P however gained greater visibility with Napsters support for music sharing on the Web. Other popular applications include Free net (distributed data store), Gnutella (file sharing) and Kaaza (free music download). SETI@home, another example of P2P, is a scientific experiment that uses Internet-connected computers in the Search for Extraterrestrial Intelligence (SETI). You can participate by running a

free program that

downloads and40


analyzes radio telescope data. However, it is increasingly becoming an important technique in various areas, such as distributed and collaborative computing both on the Web and in ad-hoc networks. Although Peer-to-Peer networking is still an emerging area, some Peer-toPeer concepts are already applied successfully in different contexts. Good examples are Internet routers, which deliver IP packages along paths that are considered efficient. Theses routers form a decentralized, hierarchical network. They consider each others as peers, which collaborate in the routing process and in updating each other. Unlike centralized networks, they can compensate node failures and remain functional as a network. But, unlike a typical P2P application, a router by itself does not change how resources within the network are shared. Peer-to-Peer as it has evolved today takes these concepts from the network to the application layer, where software defines purpose and algorithms of virtual (non- physical) Peer-to-Peer networks. There also exist countless hybrid peer-to-peer systems. Such systems normally have a central server that keeps information on peers and responds to requests for that information. Peers are responsible for hosting available resources (as the central server does not have them), for letting the central server know what resource

Notes(MWT)

Documents

Transcript of Notes(MWT)