dbde persistentdbrev.ppt - 1 copyright 97/5/4 - rjlechner iii: dbde database issues lsession...

DBDE PersistentDbRev.ppt - 1 Copyright 97/5/4 - RJLechner

III: DBDE Database IssuesIII: DBDE Database Issues

Session Management Data Model Client/Server Requests Expanded Data Model Passive Client Responsibilities Active Client Responsibilities Composite Object Data Model Event/Message Terminology Client State-Event Model Broadcast Message Format Update Conflict Resolution Broadcast Server Data Model


( represents a 1:1 to 0:M association)

Session Management Data ModelSession Management Data Model

PE Person SN Session

SI Session Interval DDE File*SC Session Client

AD Active Diagram

FV File Version

* DDE = Distributed Diagram editing (BDE-compatible); A DDE file may contain multiple block diagrams.

** This data model applies to all block diagrams types. *** Selections imply menu, cursor and highlight states.

joinersclients

DBA File

exclusive access

(based on this schema)

AP Auth-PE(authorization)

Composite Object Data Model (BDE)CT Client

Transaction

intervvals of time


Client/Server RequestsRequests

Planning Level:Schedule a session

Update session agendaCancel a sessionReserve [list of] filesInitialize participant list

Management Level:

Initiate a sessionPause a sessionResume a sessionEnd a sessionControl meeting displayChange access rights (of user to file)

Viewing Level (passive):

View CalendarView Active

Sessions (SN, SI)View File List (DF)View Diagram TitlesJoin a session

(active/passive) Leave a session Select Diagram to

view

Editing Level (active)

Create and delete objectsGet or set attribute

values Change ownMouse positionSelect/highlight/move an object

These will become class methods in the implementation.


Data Model with AttributesData Model with AttributesPE Person

username email_adr phone_no ...

SN Session

PEid //(manager) session_Title ...

SI Session Interval

Sched_TIStartSched_TIendactualStartactualEnd status ...

DF Diagram File

filename ...

SC Session Client

actualEntryTime actualExitTime localState mouseStatus

AD Active Diagram

accessMode (R/W/A) ...

CT Client Transaction transactionType argCount

To Nodes, Links, etc.

(FV FileVersion)

UP Update Parameter name type value

Merged sequence of transactions (per diagram).

Sub-sequence of atomic transactions from user

AP AuthPE access


Passive Client ResponsibilitiesResponsibilities

1. A passive client may not edit the diagram which is opened for viewing, although [s]he may point to objects and discuss them.

2. Each passive DDE client maintains all diagrams in his opened file, by applying updates received from the server's broadcast stream. The client may browse through these up-to-date copies.

3. Each time an active diagram is opened or re-opened locally, it is redrawn from scratch using the copy in the client's diagram file.

4. An active diagram display which gets too far out of sync with the server's master copy may be refreshed from the master copy.

5. A projection display may be used in a meeting setting. Typically this display shows some active diagram under discussion by meeting participants.

6. The projection screen is managed as a passive client. It is capable of displaying the current state of any active diagram.


Active Client ResponsibilitiesActive Client Responsibilities1. The client SW maintain a local database containing one file of diagrams

during each session interval. A new interval starts when the file changes. Each file is downloaded from the server's repository.

2. The client may view and update one active diagram at a time in the active file. Other clients may also be editing this diagram (text or drawing)

3. The client SW updates the local active diagram copy by merging two update streams: this client’s local mouse-controlled edits and the merged update stream of remote edits applied by the server.

4. The client SW originates local updates and applies them immediately, without waiting for the server to confirm their acceptability and order of arrival. The editor will prevent selection of objects already selected by other clients, but may permit selection of related components.

5. The server's broadcast update stream contains a redundant copy of each client's local updates, which may be interleaved with updates to the same diagram from other clients. Each composite transaction is tagged by the server as accepted, deferred, or rejected, based on a serializability rule base (TBD).

6. The client is responsible for undo-ing rejected transactions and for undoing and re-applying deferred transactions in the proper sequence.


Event/Message TerminologyEvent/Message Terminology

Assumptions

Messages are relayed between server and client in the form of events of predefined types. Message data is passed in event parameter lists.

A communication layer encapsulates bandwidth and routing differences between a single broadcast server and multiple clients.

Notation

Event instances have a unique key EIid and an Event Type identifier (ETid) which determines the parameter types (signature) passed from client to server to be used during state model interpretation or code generation.

ETid = global Event Type identifierEIid = global Event Instance identifier

The mnemonic abbreviations CS = Client to server, SC = Server to Client are prefixed to each message or event type name to show flow directon.

Event instance identifiers (EIid) are sequentially ordered by their originator (client or server) using a site-identification prefix to preserve uniquenes


Reply Events and ForwardingReply Events and Forwarding

Reply Event Types

A client may pass a second Event Type id (RTid) as a 'reply type' argument. The server may use this event type to reply to the client.

Event Forwarding to a Third Party::

A client may pass an optional third Active Instance id (AIid3) in addition to sender/client AIid1 and receiver/server AIid2.

The server can then forward the reply message type RTid to a client-specified third party AIid3 instead of or in addition to the client.


Client State-Event Model

LEAVE MTG

GET INFO

VIEW INFO

CATCH-UP

READ

EDIT HOLD

UPLOAD

JOIN MTG

SCREAD

SCHOLD

SCCONT

SCEDIT

SCSYNC

DOWNLOAD

SCDATA

EOF

EOFSCULOK

SCDLOK

CSDATA

SCULOK

Passive DIsplay Monitorig

Active graphic editing

SCJOIN

EOF

Link labels identify event types which enable state transitions.SC => Server to Client; CS => Client to Server


Broadcast Message Broadcast Message FormatFormat• A message is an event instance with parameters.

• Every message broadcast by the server has an Event Type name starting with SC (Server-to-Client).

• The first 3 arguments of each message are standardized as follows:

SCEIid: The server's event instance identifier EIid.SCETid: A globally-scoped identifier of the event type

which holds the generic message name. SCTR#: A global broadcast transaction sequence#.

• Server broadcast updates have a fourth generic argument:

CSRTid: Event type identifier for the client reply (if any).CLNTid_orig: The originating client's id (for echo recognition).

• Local clients are synchronized to broadcast updates and reply with standard ack/nack replies. Remote clients do not reply to broadcast messages.

• Additional arguments depend on the event type SCETid. For example, Set_Field requires an instance-id, field name and value.

• Control state-changing and synchronization messages usually need no additional arguments.


Update Conflict ResolutionUpdate Conflict Resolution

1. The server will stamp each broadcast message with a global server transaction sequence number SCTR# and the originating client's CLNTid and sequence number CSTR#.

2. Each update request from a client will include CLNTid, client transaction number CSTR#, and last received broadcast transaction number SCTR#.

3. From these, the originating client or the server can each detect all remote transactions which intervene between two locally originated ones.

4. The originating client retains a local audit trail or window of prior broadcast transactions and may use this to cancel local work-aheads and reject or reapply them in the order broadcast by the server.


Broadcast Server Data Broadcast Server Data ModelModel

DDE FileAC Active Client AD Active Diagram

CT Client Transaction

* Status includes menu, cursor and highlight states. ** Text may be a symbol or a tokenized line. *** Local copy of active diagram (line drawing).

GG Client Drawing ***

GG Generic Graph

CSClient Status *

(represents a 1:1 to 0:M association)

GX Generic Text

CX Client Text **

server orderingclient ordering

(multiple diagrams)

Node and link text and geometry - see graphic data model.

(one diagram)( file symbol table)

(represents a 1:1 super-to-subclass relationship)

Transaction sequence


Composite Object Data ModelComposite Object Data Model

GG Generic GraphXB Text Block

SY Symbol

TK TokenGC GraphCaption

Graph Class

GL Graph Link

GI Link Identifier GP Link Bendpoint

Link Class

GN Graph Node

GA Node Attribute

Node Class

CX Caption Text

Generic Text Class

FV File VersionClasses are shadowed and contain nested tables)

dbde persistentdbrev.ppt - 1 copyright 97/5/4 - rjlechner iii: dbde database issues lsession...

Documents