Recap

1
Recap

• Layered Protocols
• OSI Reference Model, 7 protocol layers
• Distributed systems live in the highest layer
• POSIX Sockets
• Multiplatform API for communication
• RPC
• Location transparency for computation on remote
  systems

2
Today

• TCP Socket Communication Pattern
• Distributed Computing Environment (DCE)
• Sun RPC Programming Examples
• Intro to Object-Oriented Software Engineering

3
TCP SocketsCommunication Pattern

• Usage sequence for calls presented last class
• Not shown DNS lookup

4
Distributed Computing Environment

• Usually abbreviated DCE
• Developed by the Open Software Foundation (now
  called The Open Group) in late 80s
• Highly representative of RPC systems in general
• Specifications and some implementation
  incorporated into Microsofts base system for
  distributed computing (DCOM 1.0)
• Implemented as middleware, runs on most major
  OSs including Windows

5
Distributed Computing Environment

• Distributed applications can run on top of DCE
  without disturbing existing nondistributed
  applications
• Nearly all of the DCE package runs in user space
  - on some platforms, there is a kernel module
  related to DCEs distributed file system
• Currently sold and supported by Transarc (a
  division of IBM) - http//www.transarc.ibm.com/

6
Distributed Computing EnvironmentServices

• Distributed File Service (DFS)
• Transparent access to files in a worldwide file
  system
• Built on top of network OS filesystems, or can be
  used instead of them
• Second generation of AFS (Andrew File System,
  Carnegie Mellon) - more detail on AFS later in
  the term
• Directory Service
• Track location of all system resources (machines,
  printers, data, etc)

7
Distributed Computing EnvironmentServices

• Security Service
• Protects resources by restricting access to
  authorized users
• Key-based infrastructure, but also Kerberos for
  integration with other services
• Distributed Time Service
• Keeps clocks on various machines synchronized
  with each other
• Predates the Network Time Protocol (NTP)
• Global time makes it much easier to maintain
  consistency in any distributed system - more on
  that later in the term when we discuss time
  synchronization protocols

8
Distributed Computing EnvironmentServices

• Most DCE systems have at least 3 machines, to
  avoid a single point of failure
• Directory Server
• Time Server
• File Server
• Usually the services are replicated on multiple
  machines for reliability

9
Distributed Computing EnvironmentGoals

• Enable transparent access to remote services
• Allow client applications to be written using
  familiar programming techniques
• Make existing non-distributed code run in a
  distributed environment with minimal changes
• Client and server independence - can be written
  in different languages, run on different
  platforms, etc.
• Platform-independent thread library

10
Distributed Computing EnvironmentWriting Clients
and Servers

• The entire process of writing a DCE client and
  server
• uuidgen generates a 128-bit unique ID for each
  RPC interface

11
Distributed Computing EnvironmentClient-Server
Binding
12
Sun RPC Example

• IDL for a remote procedure to calculate the area
  of a rectangle (rectangle.x)
• struct rectangle
• long length
• long width
• program RECTANGLE_PROG
• version RECTANGLE_VERS
• long RECTANGLE_AREA(rectangle) 1 /
  procedure number /
• 1 / version number /
• 0x20020114 / program number /

13
Sun RPC ExampleIDL Compilation

• Command Line rpcgen -C -a rectangle.x
• Generated Files
• rectangle.h - header file used by both client and
  server
• rectangle_clnt.c - client stub
• rectangle_svc.c - server stub
• rectangle_xdr.c - XDR data structure code
• rectangle_client.c - sample client code
• rectangle_server.c - sample server code

14
Sun RPC Examplerectangle.h

• define RPCGEN_VERSION 199506
• include ltrpc/rpc.hgt
• struct rectangle
• long length
• long width
• typedef struct rectangle rectangle
• extern bool_t xdr_rectangle(XDR , rectangle )
• define RECTANGLE_PROG ((u_long)0x20020114)
• define RECTANGLE_VERS ((u_long)1)
• define RECTANGLE_AREA ((u_long)1)
• extern long rectangle_area_1(rectangle , CLIENT
  )
• extern long rectangle_area_1_svc(rectangle ,
  struct svc_req )

15
Sun RPC Examplerectangle_clnt.c

• static struct timeval TIMEOUT 25, 0
• long rectangle_area_1(rectangle argp, CLIENT
  clnt)
• static long clnt_res
• memset((char )clnt_res, 0, sizeof(clnt_res))
• if (clnt_call(clnt, RECTANGLE_AREA,
  xdr_rectangle, argp,
• xdr_long, clnt_res, TIMEOUT) !
  RPC_SUCCESS)
• return (NULL)
• return (clnt_res)

16
Sun RPC Examplerectangle_svc.c

• Far too long to put on one or two slides
• 4711 bytes, by far the largest generated file
  (all others are less than 1200 bytes, most less
  than 500)
• Contents
• main() - registers the RPC service
• rectangle_prog_1() - handles incoming procedure
  calls
• closedown() - shuts down the RPC service

17
Sun RPC Examplerectangle_xdr.c

• bool_t xdr_rectangle(XDR xdrs, rectangle objp)
• if (!xdr_long(xdrs, objp-gtlength))
• return (FALSE)
• if (!xdr_long(xdrs, objp-gtwidth))
• return (FALSE)
• return (TRUE)

18
Sun RPC Examplerectangle_client.c (part 1)

• void rectangle_prog_1(char host)
• CLIENT clnt
• long result_1
• rectangle rectangle_area_1_arg
• clnt clnt_create(host, RECTANGLE_PROG,
• RECTANGLE_VERS, "udp")
• if (clnt NULL)
• clnt_pcreateerror(host)
• exit(1)

19
Sun RPC Examplerectangle_client.c (part 2)

• result_1
• rectangle_area_1(rectangle_area_1_arg, clnt)
• if (result_1 NULL)
• clnt_perror(clnt, "call failed")
• clnt_destroy( clnt )

20
Sun RPC Examplerectangle_server.c

• long rectangle_area_1_svc
• (rectangle argp, struct svc_req rqstp)
• static long result
• / insert server code here /
• return(result)

21
Software Engineering Process

• The software engineering process consists of
  multiple phases
• Analysis - determination of what the software
  needs to do and what is necessary to do it
• Design - detailed specification of the
  architecture and interactions of the software
  components
• Implementation - translation of the design into
  code
• Testing - verifying that the implementation
  matches the design
• Maintenance - ensuring that the software
  continues to work and be understood as time goes
  by

22
Object-Oriented Software Engineering

• Focus is on implementation of reusable
  components, not on implementation of individual
  systems
• Three main characteristics of object-oriented
  software engineering
• Seamlessness
• Reversibility
• Software Contracting

23
Object-Oriented Software EngineeringSeamlessness

• Analysis, design, and implementation can all use
  the same abstraction the class
• Can preserve essential aspects of the system
  throughout the process
• Class identities/contents
• Class behaviors
• Relationships among classes

24
Object-Oriented Software EngineeringReversibility

• Analysis and design notation often used only at
  the beginning of a project, ignored once
  implementation occurs
• Specifications lose their usefulness unless they
  reflect code changes
• This is not widely believed Its the code that
  determines whether a system works, not the
  specification.
• O-O systems are inherently reversible

25
Object-Oriented Software EngineeringSoftware
Contracting

• Reusable software must be exceptionally reliable
• Software Contracting (Meyer, 1992) uses
  assertions to define class semantics
• Preconditions and postconditions for every
  operation
• Class invariants to ensure consistency
• These form a semantic specification, or contract
• Assertions can be checked at runtime, violations
  can then be handled appropriately

26
Business Object Notation

• Developed explicitly to enable seamless,
  reversible specification of object-oriented
  software with contracts
• Documented in Seamless Object-Oriented Software
  Architecture, Kim Waldén and Jean-Marc Nerson,
  1994. Available in PDF format from the CS 141
  home page.
• Usually abbreviated BON

27
Characteristics of BON

• Generality - not restricted to any particular
  application domain or programming language
• Seamlessness - specification uses object-oriented
  abstractions
• Reversibility - core concepts all map directly to
  and from an executable object-oriented language
• The reference language for BON is Eiffel

28
Characteristics of BON

• Scalability - useful not just for toy examples,
  but also for large systems
• Class cluster - groups of classes chosen
  according to some criterion
• Nesting - clusters can contain other clusters
• Element compression - design elements can be
  replaced with compressed forms (icons, small
  textual elements) for different views of the same
  design

29
Characteristics of BON

• Statically typed interface descriptions - allows
  for early type checking and clearer
  specifications
• Support for software contracting - semantic as
  well as syntactic specification
• All contracts in terms of public operations on
  classes (queries), to avoid dependence on
  internal structures

30
Characteristics of BON

• Simplicity - number of concepts is minimal
• Two basic relations between classes inheritance
  and client
• Space economy - compressed forms for graphical
  layouts, so that as much system structure as
  possible can be viewed simultaneously and
  understood

31
Characteristics of BON

• Basis for tool support - increased semantic
  content in specifications makes writing tools
  easier
• The Extended BON Toolsuite, one of Joes many
  projects, will generate Eiffel code skeletons
  directly from textual EBON specifications.
  http//ebon.sourceforge.net/

32
Next Class

• Software Contracting in Java
• More BON
• Lab 2