DOC Lecture

8/9/2019 DOC Lecture

1/43

DISTRIBUTED COMPUTING:DISTRIBUTED COMPUTING:

AN OVERVIEWAN OVERVIEWpresented by

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

San Diego State UniversitySan Diego, CA 92182-8234619.594.3734 (office)

619.594.3675 (fax)E-MAIL: [email protected]

URL: 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.


2/43

PresentationPresentation

PurposePurpose

To Present an Overview

of Distributed [Object]

Computing Concepts.


3/43

Presentation AgendaPresentation Agenda

1. Overview of Distributed [Object]

Computing (DOC)

2. Software Development & Support for DOC

3. The Business Value & Risk of DOC


4/43


1. Overview of Distributed [Object]

Computing (DOC)




5/43

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 calledobjects.

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


6/43

Distributed Object Computing*:

The View From the 30,000 Foot Level

Server(s)Client

NETNET

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


7/43

Typical Business Application ArchitectureTypical Business Application Architecture

Data

Management

Data

Management

Business

Logic/Rules

Business

Logic/Rules


A

pplicationA

rchitec

ture

A

pplicationA

rchitec

ture

Notice the Three (3) Types of Distinct Services


8/43

Traditional Platform ConfigurationsTraditional Platform Configurations

DataManagement

DataManagement

Business

Logic/Rules

Business

Logic/Rules

PresentationPresentationApp

licatio

nArchitec

ture

App

licatio

nArchitec

ture

Main-Main-frameframe

TerminalTerminal

Data

Management

Data

Management

Business

Logic/Rules

Business

Logic/Rules

PresentationPresentationApplicationArchitec

ture

ApplicationArchitec

ture

FileFileServerServer

PCPC

Mainframe

(aka: thin client)

File Server

(aka: fat client)


9/43

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

ServerServer

Data

Management

Data

Management

BusinessLogic/Rules

BusinessLogic/Rules


ClientClient

1st Generation

(aka: fat client)


BusinessLogic/Rules

BusinessLogic/Rules

2nd Generation(aka: thin client and

Network Computer [NC])

DataManagement

DataManagement


10/43

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

Server(s)Server(s)

DataManagement

DataManagement


ClientClient

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

BusinessLogic/Rules

BusinessLogic/Rules

BIGBIG

IRONIRON


11/43

Future Networks


12/43

Focus on Interoperability

There will notbe consensus on hardware platforms

There will notbe consensus on operatingsystems

There will notbe consensus on network protocols

There will notbe consensus on application formats

There mustbe consensuson interoperability.


13/43

Distributed [Object] ComputingDistributed [Object] Computing

Parts of an application run onParts of an application run on

multiple computers simultaneously.multiple computers simultaneously.

Definition:

...the software industrys suggested approach to deliver on DOC is...


14/43

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 setof features or services that are used to

fulfill consumer requests.

BB

ee

nn

eeff

ii

tt

ss


15/43

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 whendeployed)

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


16/43

The Services ModelThe Services Model

PS BS DS

Application #1

Application #2

Object

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


17/43

The Services ModelThe Services Model PS BS DS

Service Type Service Characteristics

Presentation Presentation of information and

functionality, navigation, protection of

user interface consistency & integrity

Business Shared business policies, generation of

business information from data,

protection of business integrity

Data Definition of data, storage and retrieval

of persistent data, protection of data

integrity


18/43

DOC Mental ImageDOC 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


19/43

Paradigm

An acquired way of thinkingabout 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


20/43

Paradigm Shift

A transition from one paradigm to another

Paradigm shifts typically meet with considerable

resistance followed bygradual acceptance as the

superiorityof the new paradigm becomes apparent

Object-Oriented technology is regarded by many of its

advocates [and adversaries] as a paradigm shift in

software development


21/43

Paradigm Shift Examples

Horse & Buggy to Automobile

Trains to Planes

The 1960s

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 :-)


22/43


1. Overview of Distributed [Object] Computing

(DOC)



Video Store Problem Domain (PD) Object Mo


23/43

Video Store - Problem Domain (PD) Object Mo

Inventory

StoreLocationEmployeeTransaction

ConcessionItem

Video Game VCR

SaleItem RentalItem

1 1

1

*1

1..*

Member

SalesTransaction RentalTransaction

Vendor

PurchaseOrder

*

0..1

*

1

*

*

1

POLineItem*

1

1..*

SaleRentalLineItem

1

1..* 1..n

1


24/43

A Simple OO Model to Software Example

Shape

Circle Rectangle etc...

perimeter()

area()

radius width

heightperimeter()

area() perimeter()

area()

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

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

/*****************************************************************************


25/43

/*****************************************************************************

* 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 Rectangleextends 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

/*****************************************************************************


26/43

/*****************************************************************************

* 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


27/43

...In the Beginning...

Caller

Callee

Begin Caller ProgramInit x,y,z...

Open (files/database)

Read...

Compute...

DO Callee with x,y,z

Update (files/database)

Close (files/database)

End Main Program

Procedure CalleeParameters x,y,z

Compute...

End Procedure

End Program

...Code was bound together


28/43

...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


29/43

...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


30/43

Why do we need

Object-Oriented Stuph?

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


31/43

Push

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

....all I have

to do is simplypush this

button and

the world will

be perfect!

Our user (customer, client, etc)


32/43


33/43

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]


34/43

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 cant decide which one...

Its just another fad....like CASE...

Objects are systems developments final resting place...

O-O will replace all other methodologies...


35/43

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 totalsoftware product. [Schulmeyer & McManus, 1992])

Long-run productivity improvement


36/43

Object Technology Principles

Abstraction

Encapsulation (Information Hiding)

Inheritance

Associations

Polymorphism

Common Methods of Organization

Reuse


37/43

Object-Oriented Technology Terms

Object

Class

Properties/Attributes/Variables

Relationships

Methods/Operations/Services/Behavior

Messages

Persistence

State


38/43


1. Overview of Distributed Object Computing

(DOC)




39/43

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


40/43

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


41/43

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


42/43

S I M


43/43

Thank you for attending!

Me Clapping For YOU!

Documents

DOC Lecture