Introduction to Object Oriented Programming, 3rd Ed

Timothy A. Budd

Chapter 26

Distributed Computing

Outline

  1. Roadmap
  2. An Object Oriented Community
  3. Relaxing the Rules
  4. Client-Server Computing
  5. Making it Easier to write Client Sever Systems
  6. Next Level of Complexity
  7. Object Serialization
  8. Asking an Object About its State
  9. The Future

Other Material

Intro OOP, Chapter 26, Outline

Roadmap

In this chapter we will explore some of the implications of programming in a distributed environment.
Intro OOP, Chapter 26, Slide 01

An Object Oriented Community

Recall that we have been asserting that an object-oriented program is properly thought of as a member of a community

if we relax the rules for membership in this community, we move the paradigm in different directions.

Intro OOP, Chapter 26, Slide 02

Relaxing the rules

What are some of the ways we can relax the rules? All of these are conceptually easy, but the devil is in the details.
Intro OOP, Chapter 26, Slide 03

Client-Server Computing

The simplest type of interaction is allowing objects to reside on different computers, but with known interfaces.

This is termed client/server computing.

The book describes a simple client/server system.

Intro OOP, Chapter 26, Slide 04

Making it Easier to Write Client Server Systems

Java simplifies the production of client/server systems by providing ready-made library routines for Doesn't mean it can't be done in other languages, but Java makes it a lot easier since they have spent a lot of time giving you simple interfaces for these activities.
Intro OOP, Chapter 26, Slide 05

Next Level of Complexity

The next level of complexity is a general server who is ready to accept connections from many clients, perhaps many at one time.

The book describes a system for this.

Intro OOP, Chapter 26, Slide 06

Object Serialization

Another useful feature (which should perhaps have been described in the metaprogramming chapter) is the ability to transfer objects across a network connection and regenerate them on the far side.

Called object serialization, sometimes marshalling.

Again, Java has a nice facility for this. Other langauges may as well, but I'm less familiar with them.

The book gives an example of object serialization.

Intro OOP, Chapter 26, Slide 07

Asking an Object About its State

Moving back to a single machine, there are systems that allow a program to dynamically inquire the capabilities of another class, and then add it into a running program.

A good example is Java Beans, which is not described in the book. Again, this is built on the reflection facilities described in the previous chapter.

The programmer collects a bunch of components, then assembles them into a new application. Often components have a visual interface, and can be assembled using a visual tool, without needing to write (much) programming.

Intro OOP, Chapter 26, Slide 08

Across a Network

The next level of complexity is to do the same sort of thing, but allow the components to exist across the network.

This is part of what MS is trying to do with its dot-net program. Allow the creation of components which can then be assembled even when they exist on widely separated computers.

Many parts of this problem:

Each of these steps is at the moment unstandarized, but a lot of effort is going into each. Expect a lot of work on this in the future.

Intro OOP, Chapter 26, Slide 09

The Future

I expect that in three years time this chapter will be a lot richer and a lot thicker. There is an awful lot of work going on in this area right now. Some of these ideas will be successful and continue, some will die out and be replaced.

You should expect to be hearing more about distributing / network / web based computing as time goes on.

Intro OOP, Chapter 26, Slide 10