DISTRIBUTED COMPUTING:DISTRIBUTED COMPUTING:AN OVERVIEWAN OVERVIEW

presented by

Ronald J. Norman, Ph.D., CCPProfessor of Information & Decision Systems

San Diego State UniversitySan Diego, CA 92182-8234

619.594.3734 (office)619.594.3675 (fax)

E-MAIL: Ronald.Norman@sdsu.eduURL: http://rohan.sdsu.edu/faculty/rnorman

Copyright © 1999 Ronald J. Norman

All rights reserved. No part of this presentation may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of the author.

Presentation Presentation PurposePurpose

To Present an Overview

of Distributed [Object]

Computing Concepts.

Presentation AgendaPresentation Agenda

1. Overview of Distributed [Object]

Computing (DOC)

2. Software Development & Support for DOC

3. The Business Value & Risk of DOC

Presentation AgendaPresentation Agenda

1. Overview of Distributed [Object] Computing

(DOC)

2. Software Development & Support for DOC

3. The Business Value & Risk of DOC

• Object-Oriented Technology

* A way of thinking; a thought methodology

Object-Orientation is a school of thought*

that approaches software development as

collections of components called objects.

It covers their structure, communication

mechanisms, and inherent behaviors.

“In truth, this technology is nothing less than a grand attempt to redefine the entire process of software construction.” -- David Taylor

Distributed Object Computing*:The “View” From the 30,000 Foot Level

Server(s)Client

NETNET

* aka: Distributed Computing, Distributed Object Technology, N-Tier Computing...

Typical Business Application ArchitectureTypical Business Application Architecture

DataManagement

DataManagement

BusinessLogic/RulesBusiness

Logic/Rules

PresentationPresentation

Ap

pli

cati

on

Arc

hit

ectu

reA

pp

lica

tio

n A

rch

itec

ture

• Notice the Three (3) Types of Distinct “Services”

Traditional Platform ConfigurationsTraditional Platform Configurations

DataManagement

DataManagement

BusinessLogic/Rules

BusinessLogic/Rules

PresentationPresentationAp

pli

ca

tio

n A

rch

ite

ctu

reA

pp

lic

ati

on

Arc

hit

ec

ture

Main-Main-frameframe

TerminalTerminal

DataManagement

DataManagement

BusinessLogic/Rules

BusinessLogic/Rules

PresentationPresentationAp

pli

ca

tio

n A

rch

ite

ctu

reA

pp

lic

ati

on

Arc

hit

ec

ture

FileFileServerServer

PCPC

• Mainframe(aka: “thin client”)

• File Server(aka: “fat client”)

Today...Client/Server (2-tier) ComputingToday...Client/Server (2-tier) Computing

ServerServer

Data Management

Data Management

Business Logic/RulesBusiness

Logic/Rules

PresentationPresentation

ClientClient

1st Generation(aka: “fat client”)

PresentationPresentation

Business Logic/RulesBusiness

Logic/Rules

2nd Generation(aka: “thin client” and

Network Computer [NC])

Data Management

Data Management

Today...3-tier (n-tier) ConfigurationsToday...3-tier (n-tier) Configurations

Server(s)Server(s)

Data Management

Data Management

PresentationPresentationClientClient

Host(s)/Server(s)Host(s)/Server(s)

Business Logic/RulesBusiness

Logic/Rules

BIGBIGIRONIRON

Future Networks

Focus on Interoperability

• There will not be consensus on hardware platforms

• There will not be consensus on operating systems

• There will not be consensus on network protocols

• There will not be consensus on application formats

There must be

consensus on interoperability.

Distributed [Object] ComputingDistributed [Object] Computing

““Parts of an application run on Parts of an application run on multiple computers simultaneously.”multiple computers simultaneously.”

Definition:

...the software industry’s suggested approach to deliver on DOC is...

The “Services” ModelThe “Services” Model(for software development)(for software development)

• Reuse - same app or multiple apps

• Distributed deployment

• Service specification becomes a “contract” with a defined and published interface encapsulated to hide implementation details

A way of viewing applications as a set of features or services that are used to

fulfill consumer requests.

BBeenneeffiittss

The “Services” ModelThe “Services” Model• Object Technology is its foundation• 3-Tier Conceptual Architecture:

» Presentation Services (User) (PS)» Business Services (Logic/Rules & Metadata) (BS)» Data Management Services (Database) (DS)

• Conceptual Layers (not necessarily corresponding to physical locations on the network when deployed)

• Partitioning supports:» Different/Distributed Development Teams» Separation of Concerns» Iterative Development (RAD, Prototyping...)» Reusability, Modularity, Portability

• Deployment Flexibility:» User Accessibility & Transparency» Performance» Security» Ease of Maintenance

PS BS DS

The “Services” ModelThe “Services” Model

PS BS DS

Application #1

Application #2

Object

• PS = Presentation Services • BS = Business Services • DS = Data Mgmt. Services

The “Services” ModelThe “Services” Model PS BS DS

Service Type Service Characteristics

Presentation Presentation of information andfunctionality, navigation, protection ofuser interface consistency & integrity

Business Shared business policies, generation ofbusiness information from data,protection of business integrity

Data Definition of data, storage and retrievalof persistent data, protection of dataintegrity

DOC “Mental Image”DOC “Mental Image”

Database Servers

Shared Business ObjectsClients• Forms/Panels preparation• Active/Dynamic Web Pages• Executable Content• Web Servers• Etc...

• Presentation Services • Business Services • Data Mgmt. Services

NETNET

Paradigm• An acquired way of thinking about something

that shapes thought and action in ways that are

both conscious and unconscious

• Paradigms are essential because they provide a

culturally shared model for how to think and act

• They can present major obstacles to adopting

newer, better approaches

Paradigm Shift

• A transition from one paradigm to another

• Paradigm shifts typically meet with considerable

resistance followed by gradual acceptance as the

superiority of the new paradigm becomes apparent

• Object-Oriented technology is regarded by many

of its advocates [and adversaries] as a paradigm

shift in software development

Paradigm Shift Examples• Horse & Buggy to Automobile

• Trains to Planes

• The 1960’s

• Ice Cream to Frozen Yogurt :-)

• Hand-Crafting to Automation & Robotics

• Unstructured Software Development to Formal Methods with

Measurement Metrics

• Functional Perspective to a Data Perspective to an Object

Perspective of a Problem Domain

• A “better” shoe-tying approach :-)

Presentation AgendaPresentation Agenda

1. Overview of Distributed [Object] Computing

(DOC)

2. Software Development & Support for DOC

3. The Business Value & Risk of DOC

Video Store - Problem Domain (PD) Object ModelInventory

StoreLocationEmployeeTransaction

ConcessionItemVideo Game VCR

SaleItem RentalItem

1 1

1*

11..*

Member

SalesTransaction RentalTransaction

Vendor

PurchaseOrder

*

0..1

*

1

*

*

1

POLineItem*

1

1..*

SaleRentalLineItem

1

1..* 1..n

1

A Simple OO Model to Software Example

Shape

Circle Rectangle etc...

perimeter()area()

radius widthheightperimeter()

area() perimeter()area()

2.0 * PI * radius PI * radius * radius (2 * width) + (2 * height) width * height

perimeter() area() perimeter() area()Circle Rectangle

/****************************************************************************** ShapeLibrary.java ** This is a little library of shapes; the classic example of object-oriented programming. ******************************************************************************/abstract class Shape

{ public abstract double perimeter(); public abstract double area(); public abstract String toString();}

class Circle extends Shape{ protected double radius; public Circle(double r) {radius = r;} public double perimeter() {return 2.0 * Math.PI * radius;} public double area() {return Math.PI * radius * radius;} public String toString() {return "[Circle with radius " + radius + "]";}}

class Rectangle extends Shape{ protected double width, height; public Rectangle(double w, double h) {width = w; height = h;} public double perimeter() {return 2 * width + 2 * height;} public double area() {return width * height;} public String toString() { return "[" + width + " x " + height + " Rectangle]"; }}

Java O-O ExampleJava O-O Example

/****************************************************************************** ShapeTester.java ** This application generates an array of random shapes and exercises several of the operations on them. ******************************************************************************/public class ShapeTester{ public static void main(String[] args) { // Declare and create an array of shapes. Shape[] myShapes = new Shape[5];

// Fill the array (yes, I should have used an aggregate). myShapes[0] = new Rectangle(6, 5); myShapes[1] = new Circle(5); myShapes[2] = new Rectangle(6, 5); myShapes[3] = new Rectangle(6, 8); myShapes[4] = new Circle(1);

// Display the shapes in the list with their properties. for (int i = 0; i < myShapes.length; i++) { System.out.print(myShapes[i] + ", area = " + myShapes[i].area()); System.out.println(", perimeter = " + myShapes[i].perimeter()); } }}

Java O-O ExampleJava O-O Example

“...In the Beginning...”

Caller

Callee

Begin “Caller” Program Init x,y,z... Open (files/database) Read... Compute...

DO “Callee” with x,y,z

Update (files/database) Close (files/database) End Main Program

Procedure Callee Parameters x,y,z Compute... End Procedure

End Program...Code was “bound” together

“...where we are (going)...”

Callee

Caller

Stub

Skeleton

Some Network

Program Callee Parameters x,y,z Compute...End Program

Begin “Caller” Program Init x,y,z... Open (files/database) Read... Compute...

DO “Callee” with x,y,z

Update (files/database) Close (files/database)

End Program

Note: Stub/Skeleton = CORBA jargon; Proxy/Stub = Microsoft COM/DCOM jargon

...some of the Code is on another computer

“...where we are (going)...”

Callee

Caller

Stub

Skeleton

Some Network

Note: Stub/Skeleton = CORBA jargon; Proxy/Stub = Microsoft COM/DCOM jargon

Object “A”

Object “B”

Why do we need Object-Oriented Stuph?

Push

The task of the software development team is to engineer the illusion of simplicity

....all I haveto do is simplypush thisbutton andthe world willbe perfect!

Our “user” (customer, client, etc…)

People-Soft

Database

PeopleSoft Database

Server

Unix/NT Server

PeopleSoftApplicationProcessor

(Java based)

PeopleSoftWeb Server

NetScapeServerwww

Web-BasedPeopleSoft Users

(Access via any NetScape- Compatible Web Browser)

Tuxedo(Synch-ronous)

Messaging

PeopleSoftApplicationProcessor(thin client)

Tuxedo(Synch-ronous)

Messaging

Win95 or WinNT Desktop NT Server

PeopleSoftApplicationProcessor(Mid Tier)

PeopleSoftApplicationServer(s)

Tuxedo (Synch-ronous)

Messaging

Desktop PC

LAN-basedPeopleSoft Users (Thin Client) T

ux

ed

o M

es

sa

ge

Bu

s

SQL*Net

Ora

cle

7R

DB

MS

SQ

L*N

et

PeopleSoftServer Apps,

Cobols, SQRs, etc.

PeopleSoftApplicationProcessor(fat client)

SQ

L*N

et

Win95 or WinNT Desktop

Desktop PC

LAN-basedPeopleSoft Users (Fat Client)

...

...

...DB I/F Agents

NT Server

PeopleSoftExternalInterfaceServer(s)

PeopleSoft(PSTOOLS.EXE)

Msg

Ag

ent

Msg

Ag

ent

. .

.

Msg AgtAPI

MiddlewareI/F Agent &“Wrapper”

SQL*Net

Unix/NT Server

Third PartyBusiness

Application

Third Party Applications/

Servers(QBS, Clarify,

ExpoSoft AES, Evcor?, etc.) 3rd Party

API

MiddlewareI/F Agent &“Wrapper”

3rd PartyApp.

Database DB I/F Agents

RDBMS

...

Unix/NT Server

Unix/NT Server

CentralInterfaceManagmt.

Server

Staging/Admin/Mgmt

DatabaseRD

BM

S

CentralInterfaceManagers

DB I/F Agents

Mid

dle

war

e“W

rap

per

s”

PeopleSoft7/Third Party Application Deployment Architecture - An EXAMPLE

Key: Data FlowControl Flow

Bus.Docs.

Red Pepper

PeopleSoftMRP Server

Sun/Solaris

EDITrans.(Har-

binger)

Sun/Solaris

EDI VAN

People-SoftEDI Server

MRPDB

Five Attributes of Complex Systems Complex systems often take the form of a hierarchy

[Courtois, 1985]

System component primitives are relatively arbitrary

[Simon, 1982]

Intracomponent linkages are generally stronger than

intercomponent linkages [Simon, 1982]

A complex system that “works” is invariably found to

have evolved from a simple system that “worked”

[Gall, 1986]

Architecture dominates materials when addressing

complexity [Alan Kay]

SOME Object-Oriented MYTHS

• This stuph is new; it has no history...

• I will have to throw out everything that I already know about systems

development and start over...

• The learning curve is very steep...

• There are so many....I just can’t decide which one...

• It’s just another fad....like CASE...

• Objects are systems development’s final resting place...

• O-O will replace all other methodologies...

SOME Object-Oriented TRUTHS

• One integrated model from “womb to tomb” which allows for

“round-trip” engineering

• Builds on what developers already know

• Abstraction, Encapsulation and Inheritance

• Common organization methods

• Polymorphism

• Modularity via Message Communication

• Reuse

• Higher quality systems - more maintainable (“The fitness for use of the total

software product.” [Schulmeyer & McManus, 1992])

• Long-run productivity improvement

Object Technology Principles

• Abstraction

• Encapsulation (Information Hiding)

• Inheritance

• Associations

• Polymorphism

• Common Methods of Organization

• Reuse

Object-Oriented Technology Terms

• Object

• Class

• Properties/Attributes/Variables

• Relationships

• Methods/Operations/Services/Behavior

• Messages

• Persistence

• State

Presentation AgendaPresentation Agenda

1. Overview of Distributed Object Computing

(DOC)

2. Software Development & Support for DOC

3. The Business Value & Risk of DOC

The Business Value of DOC$ Significantly improved performance and flexibility

$ Simplified maintenance

$ Reduced development time

$ Improved potential for scalability

$ Improved quality, reliability and fault tolerance

Database Servers

Shared Business ObjectsClients

The Business Risk of DOC

$ Software development/support paradigm shift costs

$ Integration costs (15%-40% of application cost)

$ Management costs to support DOC

$ Relatively immature technology when coupled across

heterogeneous computing platforms

$ Need more implemented Standards

$ Performance Issues

Database Servers

Shared Business ObjectsClients

Distributed Object Market Values*

$0

$500,000,000

$1,000,000,000

$1,500,000,000

$2,000,000,000

$2,500,000,000

$3,000,000,000

96' 97' 98' 99'

300 million

500 million

750 million

1 billion

1.5 billion

3 billion

* Source: Object Management Group, Presentation at Object World, Boston, March 1997

S I M

Thank you for attending!

Me Clapping For YOU!