Client Server Architecture


Published on

Published in: Technology
1 Comment
  • Dear M. Rence Montanes,
    Thanks too much to you.
    How can I get your slides esp. the slides of client server architecture.
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Client-server software architecture is versatile and flexible in today’s fast-changing IT landscape. It is modular in structure and relies on messaging services for communication between components. They were designed to improve flexibility, usability, scalability, and interoperability. Software flexibility implies the ability for a program to change easily according to different users and different system requirements.
  • Another approach often invoked in Two-Tier architecture is the thin client <-> fat server configuration. In this configuration, the user will invoke procedures that are stored at the database server. The fat server model gains performance in a more effective fashion, as the network footprint, while heavy, is still a lot lighter than the fat client method. The negative side to this approach is that stored procedures focus on proprietary coding and customization because they rely on only one vendor’s procedure of functionality. What is more, as stored procedures tend to be buried deep in the database, every database containing a procedure has to be modified whenever there is a change made to the business logic. This can lead to major issues in the management arena, particularly when it comes to large distributed databases.
  • Client Server Architecture

    1. 1. Terrence Jose Montanes
    2. 2.  Clients and servers are separate logical entities that work together over a network to accomplish a task
    3. 3.  Service Shared resources Asymmetric protocols Transparency of location Mix-and-match Message based exchanges Encapsulation of services Scalability Integrity
    4. 4.  File Servers
    5. 5.  Database Servers
    6. 6.  Transaction Servers
    7. 7.  Groupware Servers
    8. 8.  Object Servers
    9. 9.  Web Servers
    10. 10. Fat Clients: File & Database Fat Servers: Groupware, Transaction & Web
    11. 11. 2-Tier 3-TierSystem administration Complex (more logic on the client to manage) Less complexSecurity Low (data-level security) HighEncapsulation of data Low (data tables are exposed) High (the client invokes services or methods)Performance Poor Good Poor (limited management of client Excellent (concentrates incoming sessions; canScale communications links) distribute loads across multiple servers)Application reuse Poor (monolithic application on client) Excellent (can reuse services and objects)Ease of development High Getting betterServer-to-server infrastructure No Yes (via server-side middleware) Yes (via gateways encapsulated by services orLegacy application integration No objects)Internet support Poor ExcellentHeterogeneous database support No Yes No (only synchronous, connection-orientedRich communication choices RPC-like calls) YesHardware architecture flexibility Limited (you have a client and a server) ExcellentAvailability Poor Excellent
    12. 12.  You can develop big applications in small steps Applications can reuse components Clients can access data and functions easily and safely Custom applications can incorporate off-the- shelf components Component environments dont get older— they only get better
    13. 13.  More than 50 applications Written in different languages or by different organizations Heterogeneous data sources Life longer than three years Many modifications or additions A high-volume workload Significant inter-application communication Expectation of growing the application
    14. 14. Intergalactic EraApplication Characteristics Client/Server Ethernet Era Client/ServerNumber of clients per application Millions Less than 100 100,000+ "Server-mania" with many heterogeneous servers performing differentNumber of servers per application roles 1 or 2Geography Global Campus-basedServer-to-server interactions Yes NoMiddleware ORBs on top of Internet SQL and stored proceduresClient/server architecture 3-tier (or N-tier) 2-tierTransactional updates Pervasive Very infrequentMultimedia content High LowMobile agents Yes No OOUIs, JavaBeans, Webtops, browsers, andClient front-ends shippable places Fat GUI clientsTimeframe 1998 and beyond 1985 till present
    15. 15.  Rich transaction processing Roaming agents Rich data management Intelligent self-managing entities Intelligent middleware
    16. 16.  The client building block The server building block The middleware building block
    17. 17.  A hodgepodge of s/w technologies A buzzword A key to developing client/server applications Middleware is a vague term that covers all the distributed software needed to support interactions b/w clients and servers.
    18. 18.  Starts with API Covers transmission from request to result Not includes -S/w that provide the actual service - Database - User interface.
    19. 19.  General pipes Service-specific pipes -Database-specific -OLTP-specific -Groupware-specific -Object-specific -Internet-specific -System management
    20. 20.  The stack sandwich The logical network driver The transport-independent APIs
    21. 21. Content Bandwidth Requirements RemarksAudio 44,100 samples/sec, 16-bit perп CD quality 706 Kbit/s sampleп Digital phone quality 64 Kbit/s 8,000 samples/sec, 8-bit samplesMinimum-quality, full-motion 1024 × 768 pixels, 30 frames/secvideo 566 Kbit/s 3 colors; 8 bits eachTV-quality, full-motion videoп Uncompressed 96 Mbit/sп MPEG-2 compression 6 Mbit/sData requirements 2 Mbit/s For LAN-speed responsiveness
    22. 22.  Waits for client-initiated requests Executes many requests at the same time Takes care of VIP clients first Initiates and runs background-task activity Keeps running Grows bigger and fatter
    23. 23.  Base Services
    24. 24.  Task Preemption Task Priority Semaphores Interprocess Communications (IPC) Local/Remote Interprocess Communications Threads Intertask Protection Multiuser High-Performance File System Efficient Memory Management Dynamically Linked Run-Time Extensions
    25. 25.  Extended Services
    26. 26.  Ubiquitous Communications Network Operating System Extensions Binary Large Objects (BLOBs) Global Directories and Network Yellow Pages Authentication and Authorization Services System Management Network Time Database and Transaction Services Internet Services Object-Oriented Services
    27. 27.  Non-GUI clients that do not need multitasking Non-GUI clients that need multitasking
    28. 28. Feature Grapical User Interface (GUI) Object-Oriented User Interface (OOUI) A graphic application consists of a collection of cooperating user objects. Everything that you see is an object. Each object is represented by an icon and has at A graphic application consists of an icon, a primary window with least one view. Objects can be reused in many tasks. The a menu bar, and one or more secondary windows. The focus is applications boundaries are fuzzy. The user defines on the main task. Ancillary tasks are supported by secondaryApplication Structure whats an application by assembling a collection of windows and pop-ups. Users must follow the rigid task structure objects. These objects may come from one or more (and may get trapped in a task). An application represents a programs and are integrated with the desktop objects the task. system provides (likes printers and shredders). The users can innovate and create their own "Lego-like" object collections.Icons Icons represent a running application. Icons represent object that may be directly manipulated.Starting an Users open the object on the desktop, which causes a Users start application before selecting an object to work with.Application window view of the object to be displayed. Users open a primary window and then specify the objects they A window is a view of whats inside an object. There is aWindows want to interact with. The same window can be used to display one-to-one relationship between a window and an other objects. object. Each object has a context menu. You navigate within an Menus provide the primary method for navigating within an application or across applications by directly manipulatingMenus application. objects. The desktop functions as one big menu; icons represent the objects that you can manipulate.Active Application Icons are augmented with the in-use emphasis to Icons represent minimized windows of active applications.Visual represent an active object.
    29. 29. Object-Oriented User InterfaceFeature Grapical User Interface (GUI) (OOUI) Objects are created, communicated with, An application may provide direct manipulationDirect Manipulation moved, and manipulated through drag-and-drop on an ad hoc basis. manipulation. Objects are created in an application-specific A templates folder contains a template for every manner, usually through some form of copy object type. To create a new instance of anCreating New Objects mechanism or using the menu choices: new or object, drag its template to where you want the open. new object to reside. In addition to choosing actions from menus, a Choose object; then choose action from menu user can drag objects to icons to performActions bar. operations; for example, dragging a file to a printer icon. In addition to list boxes, OOUIs provide container objects, including folders and Text-based list boxes provide the primary formContainers notebooks. These in turn can contain other of containment. objects. Actions performed on container objects affect all the objects inside them.Focus Focus is on the main task. Focus is on active objects and tasks. All the applications behave the same and the Control alternates between the user and theWho Is In Control? user acts as the conductor. Think of the user as application. the visual programmer of the desktop. NextStep/Mac OS X, Mac OS, Windows 98, OS/2Product Examples Windows 3.X, Motif, and simple Web pages. Workplace Shell, and Web pages that take advantage of Java 2 JavaBeans.
    30. 30. Requirements From an Non-GUI Client Simple GUI Without OOUI Client OS With Multitasking Client Multitasking Request/reply mechanism(preferably with local/remote Yes Yes Yes Yes transparency) File transfer mechanism to move picture, text, and Yes Yes Yes Yes database snapshots Pre-emptive multitasking No Yes Desirable Yes Task priorities No Yes Desirable YesInter-process communications No Yes Desirable Yes Threads for backgroundcommunications with server Yes (unless you like No Yes Yesand receiving callbacks from the hourglass icon) servers OS robustness, including intertask protection and No Yes Desirable Yes reentrant OS calls
    31. 31.  Clients are becoming more intelligent These "New Age" clients must provide a server lite function It should still be able to download shippable places, run Java applets, and receive calls from a server A server lite implementation does not need to support concurrent access to shared resources, load balancing, or multithreaded communications
    32. 32.  The desktop is becoming more fragmented The universal client is really a Web browser There will be a huge demand for super-fat PCs There will be a huge demand for ultra-thin PCs Shippable places will become the new desktops Embedded clients will be everywhere
    33. 33. Application vs Mixed Server File/Print Server Unix 83.00% 17.00%Windows NT 46.00% 54.00%OS/2 Warp 31.80% 68.20% Server NetWare 18.00% 82.00%
    34. 34.  Location transparency Namespace transparency Logon transparency Replication transparency Local/remote access transparency Distributed time transparency Failure transparency Administration transparency
    35. 35.  Immediate replication causes any update to the master to be immediately shadowed on all replicas Skulking causes a periodic propagation (for example, once a day) to all the replicas of all changes made on the master
    36. 36.  Directory-specific APIs and class libraries LDAP and X.500 APIs Java classes Distributed object interfaces Meta-directory services and scripts
    37. 37.  It periodically synchronizes the clocks on every machine in the network It introduces an inaccuracy component to compensate for unequal clock drifts that occur between synchronizations
    38. 38.  Authentication: Are you who you claim to be? Authorization: Are you allowed to use this resource? Audit Trails: Where have you been?
    39. 39.  Integrity: Is My In-Transit Data Safe? - Encryption - Cryptographic checksums Non-Repudiation: Can You Prove It in Court? -Evidence of message creation - Evidence of message receipt - An action timestamp - The evidence long-term storage facility - The adjudicator .
    40. 40.  How Do You Like your Keys? - Shared Private Keys - Public Keys
    41. 41.  Jeri must first obtain a certificate Jeri applies for a store account Merchant determines if the certificate is OK Jeris certificate is OK Jeri can now shop, shop, shop
    42. 42.  Jeri places an order Merchant asks bank for authorization The bank asks the credit card issuer for authorization The credit card company approves the transaction The bank says its OK The merchant sends Jeri a receipt and ships goods Jeri receives her monthly credit card bill
    43. 43.  A networking operating system is an operating system that contains components and programs that allow a computer on a network to serve requests from other computers for data and provide access to other resources such as printer and file systems.
    44. 44.  Add, remove and manage users who wish to use resources on the network. Allow users to access to the data on the network. This data commonly resides on the server. Allow users to access data found on other network such as the internet. Allow users to access hardware connected to the network. Protect data and services located on the network. Enables the user to pass documents on the attached network.
    45. 45.  basic support for hardware ports security features such as authentication, authorization, login restrictions, and access control name services and directory services file, print, data storage, backup and replication services remote access system management network administration and auditing tools with graphic interfaces clustering capabilities fault tolerance and high availability
    46. 46.  Sockets NetWare: IPX/SPX and TLI NetBIOS and NetBEUI Named Pipes
    47. 47.  An essential problem is that RPCs are not procedure calls at all; they are truly process invocations. The invoked program runs across the wire in a different resource domain
    48. 48. Remote Procedure Call Binding server binder (0) recv reqprogram stub (2) register stub procedure or search return LPC Bind req recv req execute (1) (3) (5) (5) (1) Recv bind unmarsh marshal (4) Send req LPC Recv marshal result (6) (8) send (8) unmarsh (7) result (6) return return client server
    49. 49. Remote Procedure Call: steps(0) Remote procedures registration;(1) Client procedure calls client stub in normal way;(2) Client stub sends a binding request asking for information;(3) Binding server searches for binding and reply to client stub;(4) Client stub packs a message (marshalling) and send to server stub;(5) Server stub unpacks parameters (unmarshalling), invokes LPC;(6) Server procedure executes and returns results to server stub;(7) Server stub packs results (marshalling) and sends to client stub;(8) Client stub unpacks results and returns to client procedure.Call-by-value: parameter is a straight value (int, float, …)Call-by-reference: parameter is a pointer to anything (int, record, array, pointer, …) Distributed Systems 87
    50. 50. StubsThe stub is application-specific code, but it isnot directly generated by the applicationwriter and therefore appears as a separatelayer from the programmers point of view.The function of the stub is to providetransparency to the programmer-writtenapplication code.
    51. 51. 1.On the client side: The stub handles the interface between theclients local procedure call and the run-timesystem, marshaling and unmarshaling data,invoking the RPC run-time protocol, and ifrequested, carrying out some of the bindingsteps.2. On the server side:The stub provides a similar interface between therun-time system and the local managerprocedures that are executed by the server.
    52. 52.  How are the server functions located and started How are parameters defined and passed between the client and the server How are failures handled How is security handled by the RPC How does the client find its server How is data representation across systems handled
    53. 53.  Every DAD needs a MOM DAD stands for Distributed Application Development MOM stands for Message-Oriented Middleware
    54. 54. Feature MOM: Messaging and Queuing Remote Procedure Call (RPC)Metaphor Post office-like. Telephone-like. Asynchronous. Clients and Synchronous. Clients and servers servers may operate at different must run concurrently. ServersClient/Server time relationship times and speeds. must keep up with clients. Servers must first come upClient/Server sequencing No fixed sequence. before clients can talk to them.Style Queued. Call-Return.Partner needs to be available No. Yes. Single queue can be used to implement FIFO or priority basedLoad-balancing policy. Requires a separate TP Monitor. Yes (some products). Message queue can participate in theTransactional support commit synchronization. No. Requires a transactional RPC.Message filtering Yes. No. Slow. An intermediate hop isPerformance required. Fast. Yes. Queues and triggers are Limited. Requires threads andAsynchronous processing required. tricky code for managing threads.
    55. 55. Dynamic Data Exchange or DDE is a Windows feature that allowsWindows applications to communicate with each other. DDE isbased on the messaging system built into Windows. Two Windowsprograms can carry on a DDE "conversation" by posting messages toeach other. These two programs are known as the "server" and the"client". A DDE server is the program that has access to data thatmay be useful to other Windows programs. A DDE client is theprogram that obtains this data from the server.
    56. 56.  Common Object Request Broker Architecture Communication infrastructure for distributed objects Allows a heterogeneous, distributed collection of objects to collaborate transparently
    57. 57.  Developing distributed applications Locating remote objects on a network Sending messages to those objects Common interface for transactions, security, etc.  CORBA Services (more later)
    58. 58.  Data is distributed  Administrative and ownership reasons  Heterogeneous systems  Shared by multiple applications  Scalability
    59. 59.  Computation is distributed  Scalability: multiprocessing  Take computation to data  Heterogeneous architectures Users are distributed  Multiple users interacting and communicating via distributed applications
    60. 60.  All entities are modeled as objects Systems support location transparency Interfaces, not implementations, define objects Good distributed object systems are open, federated systems
    61. 61.  Designers of CORBA Consortium of 700+ companies  Not including Microsoft Members: ▪ platform vendors ▪ database vendors ▪ software tool developers ▪ corporate developers ▪ software application vendors
    62. 62.  Has never been fully implemented Probably never will be Industry moves quickly and spec has to keep up
    63. 63. Client Serverrequest response ORB ORB “Object Bus”
    64. 64.  Examples  Service  Client  Component  Business object CORBA objects approach universal accessibility  Any Language  Any Host on network  Any Platform
    65. 65.  The client IDL stubs The Dynamic Invocation Interface (DII) The Interface Repository APIs The ORB Interface
    66. 66.  The Server IDL Stubs (OMG calls them skeletons) The Dynamic Skeleton Interface (DSI) The Object Adapter The Implementation Repository The ORB Interface
    67. 67. 1. ORB2. CORBA Services3. CORBA Facilities4. Application Objects
    68. 68.  Object Request Broker  “Object Bus” Handles all communication among objects Each host (machine) has its own ORB ORBs know how to talk to each other ORB also provides basic services to client
    69. 69.  Find the object implementation for the request Prepare the object implementation to receive the request Communicate the data making up the request Retrieve results of request
    70. 70.  There’s an ORB on the server too ORB receives request
    71. 71.  With an RPC, you call a specific function (the data is separate). In contrast, with an ORB, youre calling a method within a specific object. ORB method invocations have "scalpel-like" precision. The call gets to a specific object that controls specific data, and then implements the function in its own class-specific way. RPC calls have no specificity—all the functions with the same name get implemented the same way. Theres no differentiated service here.
    72. 72.  Internet Inter-Orb Protocol Network or “wire” protocol Works across TCP/IP (the Internet protocol)
    73. 73.  Method invocations  Static and Dynamic  Remote objects or CORBA services High-level language bindings  Use your favorite language; ORB translates Self-describing  Provides metadata for all objects and services
    74. 74.  Local or remote  Same API wherever target object lives Preserves context  Distributed security and transactions Coexistence with legacy code  Just provide a wrapper object
    75. 75.  Not a separate process Library code that executes in-process Listens to TCP ports for connections  One port per local object Opens TCP sockets to other objects  N ports per remote machine
    76. 76.  Interface Definition Language Defines protocol to access objects Like a contract Well-specified Language-independent
    77. 77. module Calc { interface Adder { long add(in long x, in long y); }} Defines an object called Adder with a method called add
    78. 78.  Stub  lives on client  pretends to be remote object Skeleton  lives on server  receives requests from stub  talks to true remote object  delivers response to stub
    79. 79. Client Host Machine Server Host Machine Client Object Remote Object Stub Skeleton ORB IIOP ORB
    80. 80.  in CORBA, a client is a client relative to a particular object i.e. an object with a reference to a “server” object A client may also act as a server  If it has an IDL and stubs and skeletons Technically, a CORBA server contains one or more CORBA objects
    81. 81.  Host machine Program running on host machine CORBA object running inside program  has IDL, stub, skeleton  Sometimes called a Servant
    82. 82.  Client code has no knowledge of the implementation of the object or which ORB is used to access the implementation.
    83. 83.  APIs for low-level, common tasks Life Cycle Service  creating, copying, moving, removing objects Naming Service  Register objects with a name  Look up objects by name
    84. 84.  Concurrency Control Service  Obtain and release exclusive locks Transaction Service  Two-phase commit coordination  Supports nested transactions Persistence Service  Storing objects in a variety of databases  RDBMS, OODBMS, file systems
    85. 85.  Security Service  Authentication, ACLs, encryption, etc. Event Service  Uncoupled notifications
    86. 86.  Relationship Externalization Query Licensing Properties Time Trader Collection … and so on… See what I mean about it never being implemented?
    87. 87.  Frameworks for specialized applications Distributed Document Component Facility  OpenDoc In progress:  Agents  Business Objects  Internationalization