OOFwDPfBDIS

• O-O Frameworks with Design Patterns for Building Distributed Information Sharing

– Dissertation by Björn Eiderbäck– NADA/KTH, 3/2001

– Presentation by Stephen Travis Pope (stp@create.ucsb.edu)

Outline

• Overview• Goals & Definitions• The Problems with Patterns• Distributed Processing Systems• UI Builders• The MultiGossip Patterns &

Framework• Evaluation, Comments & Questions

Overview of the Work

• Background of the team and project• IPLab, MultiG• COMIC: Shared Obj. Svc, Interface Svc.• MMProg Project (DMIB?)• OOP & OOD Patterns• Distributed Processing for CSCW (a

natural combination)• The MultiGossip Framework

The Thesis

• Three components:– Survey and R&D questions (70 p)– Solutions and implementations (100 p)– Evaluation and conclusions (24 p)

• Topical focus:– OOP, CSCW, design patterns, GUI

Frameworks, DPE, UIBs

Goals of this Work

• Integrated framework for information sharing

• Distribution and cooperation via agents

• Reflexive environment• Information sharing techniques• New design patterns• Use of OO techniques

My Comments

• Pick fights with Björn’s quotes and abuse of basic definitions

• Complain about the state of the current “pattern frenzy”

• Sell you all CORBA ORBs• Evangelize for Smalltalk• Generally know it all better...

Basic Definitions

• Problems: Object, Actor, and Agent• Object: encapsulated state and behavior

– Has: identity, well-known behavioral interface, possible class relationship

• Agent: Object with a “thread”– Implies self-directed action, dependency– E.g., Observer, blackboard, Cellular

Automaton

Service/Object/Agent Semantics

• Task service

• Resource manager

• Method servers(?)

• Project (meta) agents

• Weak vs. strong agency a la

Kendall

Design Patterns

• Pattern history– Architecture, Eiffel/Smalltalk OOD (reverse

architecture or pattern mining)

• “Pattern describes an abstract problem and the basic structure of a solution”

• Ways of describing OO design patterns (formally)

• Wegner: “Objects, components, and frameworks cannot be specified by algorithms.” (hogwash!)

The GO4 Pattern Template

• Several formats:– Name– Intent– AKA– Problem/Motivation– Solution/Applicability– Structure/Participants– Known Uses– Consequences– See also (relatives)

• Augmented by:– Free text– UML Diagrams

• Class relationships• Action sequences• E/R diagrams

– Code examples

Example: Dependency

• Name/AKA: Observer, constraint, publish/subscribe, data-flow

• Context/Intent: dist. systems• Motivation : indep. objects + constraint• Forces: loose coupling• Solution/Structure/Applicability:

dependency mechanism• Known Uses: MVC, Observer/-able

GO4 Pattern Relationships

PurposeCreational Structural Behavioral

Class Factory Method Adapter Interpreter

Scope Template Method

Object Abstract Factory Adapter Resp. Chain

Scope Builder Bridge CommandPrototype Composite IteratorSingleton Decorator Mediator

Façade MementoFlyweight Publish/SubscribeGlue StateProxy StrategyVisitor

Structure of Patterns & Pattern Decomposition

• Dependency/Observer/P-S/Constraint– Model is-a observable (has-a dependents)– View implements updating– Transparent forwarding between Model and (0-n) (1-n)

Views

• Adaptor/Holder/DynamicValue/Wrapper/ Proxy/Bridge– Holder implements external protocol (has-a value)– Value does something else– Transparent forwarding between Holder and (0-n) (1)

Values

• Does this help to differentiate them?

Pattern Issues

• Q: Is call-back a pattern? What about dependency or adaptation?

• Q: What’s the (formal) difference between tool kits, libraries, and frameworks?

• Q: Is MVC a pattern or a framework? (p. 75)

• Q: Are all frameworks architectural?

Pattern Hierarchies and Primitives

• Are there primitives and notations that we could use to formally describe the construction and composition of patterns and the relationships between them?

• Well, are there?

Distributed Processing Defined

• Multiple processors without shared memory(?)

• Communicate by sending messages via some network

• Focus on behavioral interfaces

Distributed Processing “Light”

• Managing concurrency, multi-processing, and physical distribution

• Requirements– Network, low-level protocols (assumed)– XDR: external data representation– RPC/RMI: remote method invocation

• These may be described in an IDL

– A few basic services (naming, 1:n events)

Distributed Processing Issues

• XDR and marshalling (pass-by-reference supported?)

• RMI modes: sync, blocking, 1:n, call-back, etc.

• IDL: fcn. prototypes, exceptions, interface class hierarchy, QoS

• Run-time configuration and management

DPE Systems & Semantics

• Actors & Laws of Parallel Processing

• Concurrent OO Languages– ABCL/1– ConcurentSmalltalk

• DST/CORBA– Heavy-weight– Possibly transparent

Required Services (BE)

• Required– Naming– Messaging (RMI)– Life-cycle

• Optional– User registration– Trading– Transactions/concurrency– Events– Persistency

The Problems with Sharing

• Concurrency and threading

problems

• Session state and persistency

problems

• Distributed garbage collection

• Fault-tolerance

The Goal of DPE

• Transparency across– Access– Location– Concurrency*– Replication*– Faults– Migration*– Performance– Scaling

Architectural Style in DPE

• Information issues– Centralized vs. replicated

• Communication Issues– Host-terminal– Client-server– Broadcast data– Batch communication– Peer-to-peer?– Others?

OOP and DPE

• Natural mix– Data-hiding and encapsulation– Behavior via message-passing– Focus on interfaces and shared behavior– Various “transparencies”

• But:– No explicit call-by-reference– No answers for concurrency,

distribution, 1:n events, etc.

GUIs and Frameworks

• GUI Architecture and OO patterns• Impact on the design of widget sets• UI Builders and GUI construction• VisualWorks:

– Merge of display list graphics and view layout

– All connections via adaptors– All “adornment” via wrappers– Run-time GUI construction

UI Builder Semantics

• Graphical configuration• “Wiring”• Complexity and scaling• VisualWorks:

– Layout and graphical constraints– Dialogs for complex connections,

pre/post-conditions, etc.– Too complex for simple tasks, but

scales well to very complex GUIs

CSCW

• Collaboration across place (physical/geographical distribution)

• Collaboration across time (off-line partnering)

• Many terms: messaging, conferencing, co-authoring, etc.

• Special vs. custom tools

Information Sharing Patterns• Viewing patterns• Shared access patterns• Transport patterns• Extension patterns• Migration patterns• Distribution patterns

Issues: location, access, replication, consistency, views and interfaces, etc.

Viewing patterns

• Multiviewing – separate semantics and presentation (MVC, etc.)

• Shared view – identify shared state as semantic (tight coupling, WYSIWIS)

• Partly-shared view – divide semantics and presentation, I and O (WYSIWIMS)

• Different outfits – configurable presentations (medium coupling)

• Sharing through objects – shared state as separate object (loose coupling)

(Fig p. 87)

Shared access techniques

• Transparent distribution (the goal)• Transparent object locations (using a

mediator/adaptor)• Two-tier architecture (but no implied

hierarchy, may be P2P)• Three-tier architecture (“shared

business objects”)• Splitting semantics from presentation

(many options)

Transport patterns

• Communicating changes to replicates – several approaches, standard fare

• Message-passing – loose coupling• State-poking – abstract/composite

setters• Meta-model – just an object! (or a

component)

(Fig p. 95)

Distribution patterns

• Marshalling – serialization, streaming• Messenger – proxy, forwarder• Low-level connection – ORB + IIOP• High-level connection – API based on LLC• Arriving back at the origin – blocking calls• Mother – DPE Manager

• Coping with errors – exception propagation• Providing undoable actions – no solution!

Extension patterns

• Template method – pluggable (or parameterized) behavior, see pluggable MVC

• Aggregation with black box – COM composites, JavaBeans

Migration patterns

• Proxy – adaptor? forwarder? wrapper?

• Adaptor for distribution – see above...

Architectural Guidelines

• Dynamic architecture• Indirect• Use metaclasses• Events and notifications• Use adaptors• Encapsulate• Migration and agents

• Are these patterns?

Architecture for Information-Sharing Applications• Technical/Design requirements

– OO aesthetics– Structured design rules

• Required services– Naming, trading, transaction, life-cycle– History, versioning, locking, persistency

• Applied patterns• Proposed architecture

Conceptual Components (p. 144)

• Comm. Infrastructure (L/HLC, RMI)

• Messaging system (sync)• Server & clients• Services (required services)• Agents, mobile objects• Client application

Architectural Guidelines

• Structural advice (malleable)• Recommended patterns (factory,

metaclass, adaptors, etc.)• Recommended design techniques

(transparency, mobility)• Central components (communication,

RMI, obj. manager, naming svc., transaction/migration, etc.)

Integration

•Easy!

(given a sophisticated enough OO development platform...)

MultiGossip: A DMIB

• Implementation Issues– Naming and identifiers– RMI mechanisms (Marshalling and

protocols)– Distributed instances– Syntax (ST80)

• Examples (p. 180 ff)

Remote Message Objects

• Message• ID• Receiver• Do reply• Acknowledge• Timestamp

Evaluation of MultiGossip

• Controllability• Support for Experimentation• Extensibility/Flexibility• Active services• Malleability• Support for various media• Smooth integration into programming

environment

Assessment

• Useful for prototyping• Scalable• Transparent• Controllable• Safe and reliable• Development speed• Performance and latency• Coverage• Expressive• Useable

Evaluation Criteria

• Object sharing• Distributed error handling• Extension• Port to new version of platform• IB adaptation• Core extension

Building tools

• Chat• Browsers• Paint• Pong• IP (video) phone• Window copying• Async. Tools

Discussion

• Server vs. loose-coupling• Homogeneous protocols• Casual vs. server-based connections• Persistency• Integration with environment• MM object integration• Extending ST interaction techniques

Who Cares?• Who needs this? (We do!)

– Internet since 1980, WWW since 1992…– Still depressing scarcity of new applications.– CORBA, COM, etc. are still hard to use for

building truly novel (MM) applications (see, e.g., our work at CREATE)

• What’s the contribution of this work?– Important new patterns and their impact on

architecture analyzed– Design and implementation alternatives assessed

and MG decisions justified

Goals of this Work

• Integrated framework for information sharing

• Distribution and cooperation via agents

• Reflexive environment• Information sharing techniques• New design patterns• Use of OO techniques

If he started today…

• CORBA (??)• Java?• Squeak/Nebraska• VR frameworks• HPDM/DPE/VRUT framework• Other relevant technologies

Conclusions

• This work is relevant.• It makes significant contributions to

the field.• I suggest a series of articles based

on the pattern formalisms, concrete patterns, architectural comments, and system overview.

• Bravo, Björn!