marketplace-2014/marketplace/scribblings/concepts.scrbl

84 lines
2.6 KiB
Plaintext
Raw Normal View History

2013-04-23 00:55:07 +00:00
#lang scribble/manual
@require[racket/include]
@include{prelude.inc}
2013-04-25 21:12:17 +00:00
@title{Concepts}
2013-04-23 00:55:07 +00:00
2013-05-08 11:22:34 +00:00
We integrate ideas from both distributed systems
2013-04-23 00:55:07 +00:00
and virtualized operating system designs to obtain a novel
architecture of nested virtual machines. Each nested layer is equipped with
its own publish/subscribe network that also propagates information
2013-05-08 11:22:34 +00:00
about the (dis)appearance of services.
2013-04-23 00:55:07 +00:00
2013-05-08 11:22:34 +00:00
The result suggests a @emph{
2013-04-23 00:55:07 +00:00
marketplace} metaphor, where communicating programs exist in a
noisy, crowded, even chaotic context, rather than in a quiet place
systematically going through their inboxes.
2013-04-25 21:12:17 +00:00
@section{What is a process, what are event handlers?}
2013-04-26 20:32:41 +00:00
@deftech[#:key "process"]{Processes} are ...
2013-04-26 21:43:31 +00:00
@deftech{Process State} is ...
@deftech{Events} ...
@deftech{Actions} ...
2013-04-25 21:12:17 +00:00
@section{What is a VM?}
2013-04-26 20:32:41 +00:00
@deftech[#:key "vm"]{Virtual Machines (VMs)} are ...
@section{Endpoints: Subscription and Advertisement}
2013-04-26 21:43:31 +00:00
The Marketplace operating system's inter-process communication
facility is structured around @deftech[#:key
"pub/sub"]{publish/subscribe (pub/sub)} messaging.@note{For a survey
of pub/sub messaging, see
@hyperlink["http://www.cs.ru.nl/~pieter/oss/manyfaces.pdf"]{"The Many
Faces of Publish/Subscribe"}, ACM Computing Surveys, Vol. 35, No. 2,
June 2003, pp. 114131. There's also plenty out there on the Internet;
a good starting point is to google for
@hyperlink["https://www.google.com/search?q=pub/sub message-oriented middleware"]{pub/sub message-oriented middleware}.}
2013-04-26 20:32:41 +00:00
2013-04-26 21:43:31 +00:00
@deftech{Endpoints} are ...
2013-04-26 20:32:41 +00:00
2013-04-26 21:43:31 +00:00
A @deftech{role} describes the role some process is playing in a
conversation. Concretely, roles are represented by @racket[Role]
structures. A role can be used by the currently-running process to
describe some role it wishes to play, or can be carried in some
2013-04-26 20:32:41 +00:00
@racket[EndpointEvent] to describe the role some @emph{peer} process
is playing in a conversation.
2013-04-26 21:43:31 +00:00
Roles have three parts:
@itemlist[
@item{An @deftech{orientation} (type @racket[Orientation]) describes
whether this role is concerned primarily with @emph{producing} or
@emph{consuming} messages.}
@item{A @deftech{topic} is a @deftech{pattern} over messages. Topics
perform double duty: they both scope conversations and filter
incoming messages. More on topics below.}
@item{An @deftech{interest-type} (type @racket[InterestType])
determines whether the endpoint playing the given role is genuinely
a participant in matching conversations or is simply observing the
real participants. More on interest-types below.}
]
@deftech{Messages} are ...
@subsection{Topics}
As mentioned above, topics ...
@subsection{Interest Types}
...
2013-04-25 21:12:17 +00:00
@section{Presence}
@section{Nesting, relaying, and levels of discourse}