Transparencies on CBSD

1
Transparencies on CBSD

• Component-Based Software Development
• Juan Carlos Guzmán
• SPSU

2
Interfaces

• Set of named operations that can be invoked by
  clients
• It provides semantics to the operations (without
  showing implementation)
• Can be considered as a specification of what
• the implementation must adhere to
• the client can expect
• It is a contract

3
Interface as a Contract

• Establishes pre and postconditions for each
  operation
• Preconditions
• established by the client
• demanded by the interface
• required by the provider
• Postconditions
• established by the provider
• guaranteed by the interface
• expected by the client

4
Polymorphism

• The ability of a context to accept elements of
  different properties without distinction

5
Types, subtypes, and type checking

• Arbitrary pre and postcondition contract checking
  is not feasible
• Typing and subtyping is feasible
• A simplified contract
• can be checked

6
Subtyping

• Follows the contravariance rule
• implementations can always be stronger than the
  contract
• clients requests can always be weaker than the
  contract

7
Independent Extensibility

• A system is independently extensible if
• it is extensible
• its extensions can be combined
• the extensions are components
• Modern O/S are extensible
• microkernel
• bunch of components

8
Problem

• Each component has its own context
• Cross-context calls are expensive
• The system must ensure that
• the call is authorized
• context switch is handled
• parameters are passed caller to callee
• Cross-context returns are also expensive

9
Solution

• Create safe components
• compile away, or strongly simplify authorization
• certify good components
• Just how safe can the components be?

10
Evolution vs Immutability

• Can a contract evolve, or must it remain
  immutable?
• How can you change a public contract?
• Syntactic vs semantic changes
• Two ways out
• expiration
• overriding law

11
Inheritance

• One kind of inheritance?
• No, Three kinds
• subclassing (implementation)
• subtyping (contract/interface)
• substitutability
• What about multiple inheritance?
• mixins

12
Fragile Base Class Problem

• When I modify a base class
• do I have to recompile its derived classes?
• do I have to modify them?

13
Syntactic FBC Problem

• Are derived classes compatible with newer
  releases of super classes, where appropriate
  interface (and semantics) have not changed, but
  the interface has been rearranged?
• Trivial changes to the interface
• new methods or properties
• new classes have been incorporated to the
  hierarchy
• methods have been moved to other places within
  the inheritance path (still visible)

14
Semantic FBC Problem

• Changes in appropriate interface or semantics
• change of parameter order/number/etc of a method
• change of semantics of a method

15
Issues with Inheritance

• Method override
• Methods calling subclasses methods
• Abstraction layers may be broken
• Class interfaces
• Client interface
• public
• Specialization interface
• protected

16
Object Composition

• Also reuses code
• the reuse has to be made explicit via
  forwarding
• Lack of a common self
• has-a vs is-a
• Can introduce delegation

17
Granularity

• Partitioning into components
• Modularization of the system

18
Dividing the System in Units

• Abstraction
• Accounting
• Analysis
• Compilation
• Delivery
• Deployment
• Dispute
• Extension

• Fault containment
• Instantiation
• Installation
• Loading
• Locality
• Maintenance
• System management

19
Design Level Reuse

• Design Reuse attempt to share certain aspects of
  an approach across projects

• To Share
• consistency
• concrete solution fragments
• contracts
• indiv. interaction fragments
• interaction architectures
• subsystem architectures
• overall structure

• Use
• programming languages
• libraries
• interfaces
• messages protocols
• patterns
• frameworks
• system architectures

20
Programming Languages

• Encode dogmas of how things should be done
• Enforce static safety properties
• Cannot verify the program against its specs

21
Libraries

• Hold the proven functionality for a domain

22
Interfaces

• Smallest contractual units in a system
• Minimal basis for interaction between client and
  provider
• These characterize the end points

23
Messages and Protocols

• Messages communication between endpoints
• Protocols valid sequences of messages between
  endpoints

24
Patterns

• A set of ideas that can be applied in many
  situations
• Microarchitectures
• describe abstract interaction between objects
  collaborating to solve a particular problem

25
Frameworks

• Sets of cooperating classes (some may be
  abstract) that make a up a reusable design for a
  specific class of software

26
System Architecture

• Layering
• Extensibility
• High-level design

27
Programming

• Paradigm shift
• from
• composition of procedural abstractions
• caller driven
• interfaces are entry points
• to
• connection oriented
• binding caller/callee
• incomming interfaces
• outgoing interfaces

28
Connection-Oriented Prog.

• Connections to glue components
• Pull vs. push way of programming
• direct calls
• calls resulting from events
• Notification (event propagation)
• Usual procedure calls pull model
• Being notified calls push model

29
Connection-Oriented Prog.

• Incoming interfaces
• aka provided interfaces
• events and messages received by the component
• Outgoing interfaces
• aka required interfaces
• events and messages the component may emit

30
Connection-Oriented Prog.

• Incoming interface
• the call through the interface originated from
  outside the component
• Outgoing interface
• the call through the interface originated from
  inside the component
• The communication can be either way (or both
  ways) through these interfaces

31
Connection-Oriented Prog.

• Channels (or groups)
• Abstractions through which callers (sources)
  communicate to callees (sinks)
• Channels allow multiple sources and multiple
  sinks, and allow endpoints to be dynamically
  added and deleted
• They may also provide additional services

32
Communication

• 1.- Create a message object
• initialize its fields
• 2.- Send the message
• to the sinks
• (or to the channel)

33
Problems with Message Objects

• First class event objects can be expensive
• Event objects of the wrong type can be passed
• Not properly initialized event objects can be
  passed

34
Difference Between Messages and Objects

• Objects encapsulate state and behavior
• Messages package data
• no reference to other messages
• usually no behavior
• if object reference is needed, use indirection
• So messages are simpler

35
Ordering of Events

• Causalty
• Relative order of events being fired and received
• Races
• when two events can arrive at a target in
  different relative ordering
• Glitches
• temporary state inconsistency

36
Metaprogramming

• Programming oneself
• Using the information about the system to program
  the system itself
• some of this can be useful
• extending the kind of messages that a component
  can handle
• not all
• Need very late binding

37
Wiring Standards

• What is wiring
• Why we need standards for it
• What are the standards

38
Interprocess Communication

• Communicating Information
• Files
• Pipes
• Sockets
• Shared Memory
• All in binary format

39
Remote Procedure Calls

• Caller callee on different computers
• From the callers point of view, the callee is
  local
• From the callees point of view, the caller is
  local
• RPC will handle the communication, back and forth
• Arguments, and result, need to be transmitted
  through the network

40
How Much Does It Cost?

• In-process calls
• Interprocess calls
• Intermachine calls

41
On Interfaces

• Type signatures?
• How to translate data from the caller to the
  callee, and back?
• Universally unique identifiers UUID

42
How About Objects?

• When sending a message, the method executed can
  be dependent on the actual object to which this
  message is sent
• The object always knows its self
• But O/Ss work on processes, not objects
• Need a way to generate method calls

43
XML

• Extensible Markup Language
• Useful to represent structured data
• General enough to be extensible
• Specific enough to be usable
• A document is a tree, in textual form
• These trees can be characterized -- use schemas

44
SOAP

• Remote object invocation
• Uses XML to transmit messages

45
XML Web Services

• Services geared towards automated clients
• How to describe them
• Need description capabilities (metalevel)

46
Web Service Discovery

• A web service that discovers other services and
  keeps them in a directory
• UDDI