Return to discipline.tex CVS log

Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / doc / manual

Annotation of 43BSDReno/contrib/isode-beta/doc/manual/discipline.tex, revision 1.1

1.1     ! root        1: % run this through LaTeX with the appropriate wrapper
        !             2: 
        !             3: \chapter      {A Discipline for Meal Preparation}\label{cook:discipline}
        !             4: The previous chapter
        !             5: presented a methodology for building distributed applications,
        !             6: based on two key aspects:
        !             7: {\em abstract data types}, and {\em remote operations}.
        !             8: During the exposition of these abstract terms,
        !             9: they were related to their more concrete realization in an OSI architecture,
        !            10: namely: abstract syntax, association control, and remote operations.
        !            11: 
        !            12: In the chapters that follow,
        !            13: this volume will introduce the utensils (programming tools)
        !            14: and various recipes (boilerplate routines)
        !            15: which can be used to cook-up OSI applications.
        !            16: Future editions of this volume will no doubt detail how one can prepare
        !            17: either fast food, nouvelle cuisine, or gourmet cooking.
        !            18: Given the raw power of remote operations in OSI,
        !            19: the cooking analogy is actually quite appropriate:
        !            20: some features of the remote operations service will be restricted in order to
        !            21: make the programming work more digestable!
        !            22: 
        !            23: In this chapter,
        !            24: the steps described in the following chapters are introduced and placed in
        !            25: perspective.
        !            26: Throughout the remaining chapters,
        !            27: an extended example is presented to illustrate, step-by-step,
        !            28: the use of remote operations.
        !            29: 
        !            30: \section      {Defining A New Service}\label{service:define}
        !            31: A collection of remote operations forms {\em only\/} a partial definition of a
        !            32: service.
        !            33: Other parts of this definition include naming and addressing information.
        !            34: Chapter~\ref{services} of \volone/ describes fully how a service is defined
        !            35: in these terms.
        !            36: Rather than reproduce that chapter in this volume,
        !            37: let us consider the essential points.
        !            38: At first reading,
        !            39: this seems complicated.
        !            40: In point of fact,
        !            41: the first definition of a service is challenging,
        !            42: defining later services is straight-forward and only marginally tedious!
        !            43: 
        !            44: Here are the ones we are interested in:
        !            45: \begin{describe}
        !            46: \item[abstract syntax:]        this describes the data structures being exchanged by
        !            47: the service;
        !            48: 
        !            49: \item[application context name:] this describes the protocol being used by
        !            50: the service;
        !            51: 
        !            52: \item[application-entity information:] this uniquely names an entity in the
        !            53: network;
        !            54: 
        !            55: \item[presentation address:] this locates an entity in the network;
        !            56: and,
        !            57: 
        !            58: \item[local program:] this identifies the program on the local system which
        !            59: implements the service.
        !            60: \end{describe}
        !            61: 
        !            62: We now begin the example which will be repeatedly extended in the chapters
        !            63: which follow.
        !            64: Let us suppose that we are defining the {\em ISODE Image Service},
        !            65: which offers a simple image database service.
        !            66: 
        !            67: Although Chapter~\ref{services} of \volone/ defines several approaches,
        !            68: we will take the ``standard'' approach for our example:
        !            69: \begin{describe}
        !            70: \item[abstract syntax:]        defined in the \man isobjects(5) file as:
        !            71: \begin{quote}\small\begin{verbatim}
        !            72: "local service pci"      1.17.2.n.1
        !            73: \end{verbatim}\end{quote}
        !            74: If we select \verb"n" as the lowest unassigned number in the \verb"1.17.2"
        !            75: subtree, e.g., \verb"7", we might have:
        !            76: \begin{quote}\small\begin{verbatim}
        !            77: "isode image pci"      1.17.2.7.1
        !            78: \end{verbatim}\end{quote}
        !            79: 
        !            80: \item[application context name:] defined in the \man isobjects(5) file as:
        !            81: \begin{quote}\small\begin{verbatim}
        !            82: "local service"          1.17.2.n.2
        !            83: \end{verbatim}\end{quote}
        !            84: Similarly, for a value of \verb"7" for \verb"n", we have:
        !            85: \begin{quote}\small\begin{verbatim}
        !            86: "isode image"          1.17.2.7.2
        !            87: \end{verbatim}\end{quote}
        !            88: 
        !            89: \item[{\small application-entity information/presentation address:}]
        !            90: defined with:
        !            91: \begin{quote}\small\begin{verbatim}
        !            92: default servicestore    1.17.4.1.n  ""  ""  #p
        !            93: \end{verbatim}\end{quote}
        !            94: in the \man isoentities(5) file
        !            95: (we say that \verb"servicestore" is the ``qualifier'' portion of the service).
        !            96: If we select \verb"p" as the lowest unassigned TSAP ID between \verb"1024"
        !            97: and \verb"2047" inclusive, e.g., \verb"1040", we might have:
        !            98: \begin{quote}\small\begin{verbatim}
        !            99: default imagestore     1.17.4.1.7  ""  ""  #1040
        !           100: \end{verbatim}\end{quote}
        !           101: 
        !           102: \item[local program:] defined in the \man isoservices(5) file as:
        !           103: \begin{quote}\small\begin{verbatim}
        !           104: "tsap/servicestore"    #p  program arg1 arg2 ... argN
        !           105: \end{verbatim}\end{quote}
        !           106: If we select \pgm{ros.image} as the \unix/ program implementing the {\em ISODE
        !           107: Image Service},
        !           108: we might have something like:
        !           109: \begin{quote}\small\begin{verbatim}
        !           110: "tsap/imagestore"    #1040  ros.image
        !           111: \end{verbatim}\end{quote}
        !           112: \end{describe}
        !           113: By convention,
        !           114: the names of responder programs start with \verb+"ros."+.
        !           115: 
        !           116: In future releases of the software,
        !           117: a facility might be added to determine most of this information directly
        !           118: from the formal definition of the service
        !           119: (i.e., from the remote operations module described momentarily).
        !           120: 
        !           121: The definition of this naming and addressing information is an administrative
        !           122: necessity.
        !           123: With this out of the way,
        !           124: let's consider the actual work that goes into building a distributed
        !           125: application which uses remote operations.
        !           126: 
        !           127: \section      {Defining A Remote Operations Module}
        !           128: A {\em remote operations module\/} defines the operations
        !           129: (and associated errors) along with the abstract syntax of the data structures
        !           130: exchanged by the service.
        !           131: The \man rosy(1) program reads a description of the module and produces the
        !           132: corresponding {\em C\/} stubs and definitions used in accessing the service.
        !           133: 
        !           134: In simple terms,
        !           135: what this means is that \pgm{rosy} will produce routines that
        !           136: the invoker calls that will request the operation by the performer.
        !           137: 
        !           138: \section      {Defining Concrete Data Structures}
        !           139: An {\em abstract syntax module\/} defines the data structures being exchanged
        !           140: by the service.
        !           141: In many senses,
        !           142: it is equivalent to a remote operations module with the definitions of the
        !           143: operations removed.
        !           144: The \man posy(1) program reads a description of the module and produces the
        !           145: corresponding {\em C\/} structure definitions along with an augmented module
        !           146: that is read by the \pgm{pepy} compiler.
        !           147: The {\em C\/} structure definitions are used by the invoker and the
        !           148: performer,
        !           149: the run-time environment is responsible for mapping these data structures to
        !           150: the abstract syntax and then for mapping the abstract syntax to the concrete
        !           151: syntax.
        !           152: 
        !           153: In simple terms,
        !           154: what this means is that the invoker and performer worry about only the
        !           155: native machine {\em C\/} structures,
        !           156: and the open systems interface is handled entirely automatically.
        !           157: 
        !           158: \section      {Building An Initiator}
        !           159: In general,
        !           160: an initiator might take one of two implementational forms:
        !           161: \begin{describe}
        !           162: \item[interactive:] the user runs a program and interactively directs the
        !           163: invocation of operations;
        !           164: or,
        !           165: 
        !           166: \item[embedded:] as a part of its running,
        !           167: the program automatically forms an association and invokes operations as
        !           168: required.
        !           169: \end{describe}
        !           170: The choice of form is up to the implementor.
        !           171: Note that in both cases, the initiator is also acting as the invoker.
        !           172: 
        !           173: In order to speed development,
        !           174: complete boilerplate for an interactive initiator,
        !           175: along with partial boilerplate for an embedded initiator is provided.
        !           176: 
        !           177: \section      {Building A Responder}
        !           178: In general,
        !           179: a responder may also take on of two implementational forms:
        !           180: \begin{describe}
        !           181: \item[single association:] each time the service is requested,
        !           182: a new instantiation of the program implementing the service is executed
        !           183: (this is termed the {\em dynamic\/} approach);
        !           184: or,
        !           185: 
        !           186: \item[multiple association:] each time the service is requested,
        !           187: the request is given to a single, already executing,
        !           188: instantiation of the program which implements the service
        !           189: (this is termed the {\em static\/} approach).
        !           190: \end{describe}
        !           191: Although Section~\ref{service:define} describes how to define addressing
        !           192: information for the dynamic approach,
        !           193: it is good practice to implement each responder to be capable of operating in
        !           194: either mode and then leaving the decision to the system administrator.
        !           195: 
        !           196: In order to speed development,
        !           197: complete boilerplate for a dual-approach responder is provided.
        !           198: 
        !           199: \section      {Putting It All Together}
        !           200: In addition to the skeletal information above,
        !           201: a set of consistent policies for file names, rules for \man make(1), and so on,
        !           202: are needed.
        !           203: These will be introduced at the appropriate time.
        !           204: 
        !           205: It is important to understand that this volume
        !           206: defines {\bf one\/} possible discipline for using remote operations.
        !           207: There are, of course, {\bf many\/} possible disciplines for accomplishing the
        !           208: same goal.
        !           209: (And some will most likely be vastly superior.)
        !           210: The particular discipline described in {\sl The Applications Cookbook} was
        !           211: chosen primarily for its balance of relative simplicity and extensibility.
        !           212: For some developers, it will still be too under done;
        !           213: if this is the case, you are encouraged to build further cooked interfaces
        !           214: on top of these facilities.

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.