Middleware

• Clients


  Applications that request services
• Servers


  Systems that manage resources and provide services in response to client requests
• Client-server examples


  • FTP (file transfer protocol)
  • WWW (World Wide Web)
  • E-mail
• Server types


  • File Server
  • Database Server
  • Transaction Server
  • Groupware Server
  • Object Server
  • Web Server

  
• File Servers


  • Clients pass requests for file records over a network
  • Useful for sharing files across a network
  • Act as a repository of documents, images, engineering drawings and other large data objects
• Database Servers


  • Clients pass SQL requests as messages
  • Server processes the SQL request and the data resides in the same machine
  • Distributed database servers may increase efficiency
  • Provide foundation for decision-support systems

  
• Transaction Servers


  • Clients invoke remote procedures that reside on the server with an SQL database engine
  • Server executes a group of SQL statements as a single transaction
  • Used for Online Transaction Processing (OLTP)
  • Require tight controls over security and integrity

  
• Groupware Servers


  • Manage semi-structured information like text, image, mail, bulletin boards, and workflow
  • Place people in direct contact with other people
  • Applications created using vendor-specific scripting language and form-based interfaces

  
• Object Servers


  • Client/server application written as a set of communicating objects
  • Client invokes a method on a remote object
  • Object Request Broker (ORB) locates the object, invokes the method, and returns the results

  
• Web Servers


  • Clients and servers communicate using HTTP protocol
  • HTML documents are stored in the Web Server

  
• Middleware


  Software that facilitates communication between the client and server, but does not include the actual service or user interface
• Middleware types


  • General Middleware
  • Service-Specific Middleware
• General Middleware


  • Communication stacks, distributed directories, authentication services, network time, remote procedure calls, queuing services
• Service-Specific Middleware


  • Database-specific, OLTP-specific, Groupware-specific, Object-specific, Internet-specific, System Management-specific
• Client/Server Building Blocks


  • Client
  • Middleware
  • Server
  • Distributed System Management (DSM)
• Client Building Block


  • Runs the client side of the application
  • Runs on an OS with GUI/OOUI and can access distributed services
  • Runs a component of the Distributed System Management (DSM)
• Server Building Block


  • Runs the server side of the application
  • Runs on top of server software packages like SQL databases, TP Monitors, groupware, objects, web
  • Depends on the OS to interface with middleware
  • Runs a DSM component
• Middleware Building Block


  • Runs on both client and server sides
  • Includes transport stacks, network OS, and service-specific middleware
  • Provides the "nervous system" of the client/server infrastructure
  • Includes a DSM component
• Distributed System Management (DSM)


  • Runs on every node in the client/server network
  • Manages and monitors the network from a central workstation
• Server-to-server Middleware


  • Handles specialized server-to-server interactions like two-phase commit and store-and-forward messaging
• Client/Server Deployment Models


  • Client/Server for tiny shops and nomadic tribes
  • Client/Server for small shops and departments
  • Client/Server for intergalactic enterprises
  • Client/Server for a post-scarcity world
• Client/Server for tiny shops and nomadic tribes


  • Runs client, middleware, and most services on the same machine
  • Suitable for one-person shops, home offices, and mobile users
• Client/Server for small shops and departments


  • Classic Ethernet client/single-server model
  • Used in small shops, departments, and branch offices
  • Middleware is kept simple
• Client/Server for intergalactic enterprises

  • Multiserver model with servers presenting a single system image to clients
  • Servers can be spread throughout the enterprise
  • Requires advanced middleware features like directory services, security, RPC, and network time

  
• Client/Server for a post-scarcity world

  • Every machine is both a client and a full-function server
  • Runs file server, database, workflow, TP Monitor, and web server
  • Uses personal agents instead of mobile agents
• Remote Procedure Call (RPC)


  • Client calls a function on a remote server and waits for the results
  • Parameters passed like an ordinary procedure call
  • Poses challenges for NOS designers in terms of locating and starting server functions, managing multiple clients, and defining/passing parameters

  
• Server functions


  Server starts the process, when a remote invocation is received with necessary parameters and returns the response to the client
• Multiple clients invoking the same function

  • Needs an environment to start and stop servers, prioritize requests, perform security checks, and provide some form of load-balancing
• Each incoming request


  • Invokes a thread in the server side
• Server loop


  • Created to manage the pool of threads waiting for work rather than create a thread for each incoming request
• TP Monitors


  Provide more functions than a NOS on the server side
• Interface Definition Language (IDL)


  Describes the functions and parameters that a server exports to its clients
• Using IDL


  1. IDL compiler takes descriptions and produces source code stubs (and header files) for both the client and server

  2. Client stubs packages the parameters in an RPC packet, converts the data, calls the RPC run-time library and waits for the server's reply

  3. Server stubs unpacks the parameters, calls the remote procedure, packages the results, and sends the reply to the client

  
• RPC failures


  • Both the sides of the RPC can fail separately, it is important for the software to be able to handle all the possible failure combinations
  • If the server does not respond, the client side will normally block, timeout, and retry the call
  • The server side must guarantee only once semantics to make sure that a duplicate request is not re-executed
  • If the client unexpectedly dies after issuing a request, the server must be able to undo the effects of that transition
• RPC security


  Modern NOSs, like DCE – make it easy to automatically incorporate their security features into the RPC
• Binding


  The association of a client with a server
• Client finding server


  1. Hardcoded in the client

  2. Consulting a configuration file or an environment parameter

  3. Using the network directory services (dynamic binding)

  4. RPC client stub will locate a server from a list of servers that support the interface (automatic binding)

  
• Data representation across systems


  • Different CPUs represent data structures differently (Ex: bigendian Vs little endian)
  • RPC must provide some level of data format translation across systems
  • Sun RPC requires that clients convert their data to a neutral canonical format using the External Data Representation (XDR) APIs
  • DCE's Network Data Representation (NDR) service is multicanonical, meaning that it supports multiple data format representations
  • The client chooses one of these formats, tags the data with chosen format, and then leaves it up to the server to transform the data into a format it understands (the server makes it right)
  • With Sun, all clients look the same to the server: The Client makes it right

  
• Peer-to-peer communications


  • Indicates that the two sides of a communication link use the same protocol interface to conduct a networked conversation
  • The protocol is symmetrical, and it is sometimes called "program-to-program"
  • The peer-to-peer interface not fully mask the underlying network from the programmer
  • Programmer have to handle the transmission timeouts, race conditions, and other network errors
  • The peer-to-peer protocols started as stack-specific APIs
• Sockets


  • Introduced in 1981 as the UNIX BSD 4.2 generic interface that would provide Unix-to-Unix communications over network
  • Supported on virtually every OS
  • The windows socket API, known as WinSock, is a multivendor specification that standardizes the use of TCP/IP under windows
  • In BSD Unix System, sockets are part of the Kernel and provide both a standalone and networked IPC service
  • Socket = Net_ID . Host_ID . Port_ID = IP Address + Port Address
  • The three most popular socket types are Stream, Datagram, and Raw