Return to concepts.tex CVS log

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

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

1.1     ! root        1: % run this through LaTeX with the appropriate wrapper
        !             2: 
        !             3: \chapter      {Motivation and Concepts}\label{cook:concepts}
        !             4: Remote operations are a well understood technique for building distributed
        !             5: applications.
        !             6: Currently,
        !             7: OSI technology provides a powerful notation for specifying the external
        !             8: interactions of these systems.
        !             9: Remote operations in OSI are particularly attractive as they specify the
        !            10: homogeneous externally visible and verifiable characteristics needed for
        !            11: interconnection compatibility,
        !            12: while avoiding unnecessary constraints upon and changes to the heterogeneous
        !            13: internal design and the implementation of the information processing systems
        !            14: to be interconnected.
        !            15: Many feel
        !            16: that this capability is likely to be a key factor in the overall success of
        !            17: OSI standardization.
        !            18: 
        !            19: In \cite{ECMA.ROS},
        !            20: a methodology for remote operations is presented which aims to package this
        !            21: technology concisely.
        !            22: Although the latter half of this document has been rendered obsolete by more
        !            23: recent work in the standards bodies
        !            24: (e.g., \cite{ISO.ROS.Service,ISO.ROS.Protocol})
        !            25: The aim of this volume, {\sl The Applications Cookbook},
        !            26: is to provide programming support for this methodology.
        !            27: 
        !            28: \section      {A Model for Distributed Applications}
        !            29: Remote operations are viewed as part of a methodology for building
        !            30: distributed applications.%
        !            31: \footnote{This section presents a (hopefully) simplified version of the
        !            32: information presented in the first half of \cite{ECMA.ROS}.
        !            33: Interested readers should consult this original work for further details.}
        !            34: In order to understand the role remote operations play in this programming
        !            35: model,
        !            36: one other notion must be explained first.
        !            37: 
        !            38: \subsection    {Abstract Data Types}
        !            39: An {\em abstract data type\/} is a concept for describing a data structure
        !            40: which is accessed in a well-defined manner.
        !            41: This has several implications:
        !            42: \begin{itemize}
        !            43: \item  Although the data structure may have a {\em concrete representation\/}
        !            44:        on a given local system (e.g., a {\em C\/} \verb"struct"),
        !            45:        its corresponding abstract data type is defined in an
        !            46:        implementation-independent fashion,
        !            47:        termed its {\em abstract syntax}.
        !            48: 
        !            49: \item  A well-defined set of rules,
        !            50:        defined by an {\em abstract transfer notation},
        !            51:        is used to serialize the abstract syntax so that a data structure
        !            52:        corresponding to the abstract data type may be unambiguously
        !            53:        transmitted on the network.
        !            54:        There are actually two mappings here:
        !            55:        \begin{itemize}
        !            56:        \item   First, the data structure is mapped to the abstract syntax
        !            57:                for the abstract data type.
        !            58:                This is an implementation-dependent mapping.
        !            59: 
        !            60:        \item   Second, the abstract syntax is mapped to the concrete
        !            61:                syntax.
        !            62:                This is a serializing activity resulting in a stream of octets
        !            63:                (although some concrete syntaxes produce bit-aligned,
        !            64:                rather than octet-aligned, streams).
        !            65:                Do not confuse the concrete representation described above
        !            66:                (which deals with programming languages), with the concrete
        !            67:                syntax (which deals with transmission properties).
        !            68:        \end{itemize}
        !            69: 
        !            70: \item  Access to an abstract data type is defined by a set of unitary actions
        !            71:        termed {\em operations},
        !            72:        which define the complete behavior of an instance of the abstract data
        !            73:        type.
        !            74: 
        !            75: \item  {\em Strong typing\/} results when operations are the only permitted
        !            76:        means of accessing an abstract data type.
        !            77: 
        !            78: \item  An {\em object model\/} for programming follows from the use of
        !            79:        abstract data types rather than concrete data structures.
        !            80:        Since operations are used to ultimately manipulate the data structures,
        !            81:        an important level of indirection has been introduced:
        !            82:        data structures may be accessed without regard to their actual
        !            83:        implementation.
        !            84: \end{itemize}
        !            85: 
        !            86: \subsection    {Operations}
        !            87: Having described the relationship between data structures,
        !            88: abstract data types,
        !            89: and operations,
        !            90: consider the generic structure of an operation.
        !            91: An {\em operation}, in its most primitive form,
        !            92: is a simple request/reply interaction.
        !            93: The interaction takes the following form:
        !            94: \begin{itemize}
        !            95: \item  The operation is {\em invoked}.
        !            96:        An invocation consists of:
        !            97:        \begin{itemize}
        !            98:        \item   an {\em operation number},
        !            99:                which uniquely identifies the operation to be performed;
        !           100: 
        !           101:        \item   an arbitrarily complex {\em argument\/};
        !           102: 
        !           103:        \item   an {\em invocation identifier},
        !           104:                which is used to distinguish this invocation from other
        !           105:                previous invocations;
        !           106:                and,
        !           107: 
        !           108:        \item   possibly a {\em linked invocation identifier},
        !           109:                which is used to indicate that this invocation results
        !           110:                during the processing of a previous invocation.
        !           111:        \end{itemize}
        !           112: 
        !           113: \item  If the operation succeeds, then a {\em result\/} may be returned.
        !           114:        A result consists of:
        !           115:        \begin{itemize}
        !           116:        \item   an invocation identifier corresponding to the operation
        !           117:                which succeeded;
        !           118:                and,
        !           119: 
        !           120:        \item   (possibly) an arbitrarily complex {\em result}.
        !           121:        \end{itemize}
        !           122: 
        !           123: \item  If the operation fails, then an {\em error\/} is returned.
        !           124:        An error consists of:
        !           125:        \begin{itemize}
        !           126:        \item   an invocation identifier corresponding to the operation
        !           127:                which failed;
        !           128: 
        !           129:        \item   an {\em error number},
        !           130:                which uniquely identifies the error that occurred;
        !           131:                and,
        !           132: 
        !           133:        \item   (possibly) an arbitrarily complex {\em parameter}.
        !           134:        \end{itemize}
        !           135: 
        !           136: \item  If the operation was not performed for some reason
        !           137:        (e.g., an unknown operation number, mistyped arguments for
        !           138:        the operation, and so on), then a {\em reject\/} is returned.
        !           139:        A reject consists of:
        !           140:        \begin{itemize}
        !           141:        \item   an invocation identifier corresponding to the operation
        !           142:                which was performed
        !           143:                (in degenerate cases this information may not be available);
        !           144:                and,
        !           145: 
        !           146:        \item   a {\em reason},
        !           147:                which describes, in general terms, the rejection which
        !           148:                occurred.
        !           149:        \end{itemize}
        !           150: \end{itemize}
        !           151: Note that in all cases,
        !           152: operations are seen as being {\em total}.
        !           153: This means that for any given operation,
        !           154: the normal outcome (the result)
        !           155: and all exception outcomes (the errors) are well-defined and mutually
        !           156: exclusive (unambiguously distinguished).
        !           157: 
        !           158: \subsection    {Associations}
        !           159: Thus far, we have implicitly assumed some communications relationship
        !           160: (i.e., a {\em binding\/}) between the entity invoking operations,
        !           161: the {\em invoker},
        !           162: and the entity performing them,
        !           163: {\em performer}.
        !           164: It is necessary formalize these notions somewhat.
        !           165: 
        !           166: An {\em association\/} is a binding between two entities,
        !           167: which are referred to as
        !           168: the {\em initiator\/} and the {\em responder}.
        !           169: Although this sounds straight-forward,
        !           170: there is actually one level of indirection present:
        !           171: the initiator does not directly select a responder for binding,
        !           172: but rather selects a {\em service\/} that it wishes to use.
        !           173: During this process a responder is located and the binding established.
        !           174: 
        !           175: The binding process is actually two-step:
        !           176: first,
        !           177: the initiator determines which service it requires and asks to have this
        !           178: service mapped onto the entities available on the network;
        !           179: second,
        !           180: based on the initiator's communications requirements,
        !           181: an association will be bound to one of those entities,
        !           182: which becomes the responder.
        !           183: 
        !           184: Note that there is no requirement that the initiator of an association be the
        !           185: entity which requests operations to be invoked
        !           186: (i.e., the initiator need not be an invoker),
        !           187: nor that the responder of an association be the entity which performs the
        !           188: operations
        !           189: (i.e., the responder need not be a performer).
        !           190: 
        !           191: \section      {Design Guidelines}
        !           192: Although the characteristics of operations will vary between applications,
        !           193: there are certain guidelines which should be of universal interest.
        !           194: 
        !           195: \subsection    {Reliability Characteristics}
        !           196: When executing an operation in a distributed environment,
        !           197: there is always an element of uncertainity with regards to the occurrence of
        !           198: remote events,
        !           199: particularly when failures occur.
        !           200: One classification of reliability might be as follows:
        !           201: for a given invocation,
        !           202: a guarantee is given that it occurs {\em exactly once},
        !           203: {\em at least once}, or {\em at most once}.
        !           204: 
        !           205: The first two guarantees require an end-to-end confirmation,
        !           206: with the proviso that the semantics of {\em exactly once\/} require a
        !           207: recovery scheme in the event of failures.
        !           208: When an operation has the semantics of {\em at least once},
        !           209: it is called {\em idempotent}.
        !           210: These are operations which read information,
        !           211: but do not modify the remote state.
        !           212: 
        !           213: In practice,
        !           214: implementing these semantics can be surprisingly straight-forward,
        !           215: given the judicious use of invocation identifiers:
        !           216: \begin{describe}
        !           217: \item[exactly once:] The invoker repeatedly requests the operation
        !           218: (using the same invocation identifier)
        !           219: until either a confirmation (result or error) is received
        !           220: or a rejection of ``duplicate operation'' is received.
        !           221: The performer keeps track of the invocation identifiers of all
        !           222: performed operations requested by an entity from an epoch date.
        !           223: If the performer finds an invocation identifier being repeated,
        !           224: rather than perform the operation,
        !           225: it rejects the operation as a ``duplicate operation''.
        !           226: 
        !           227: \item[at least once:] The invoker repeatedly requests the operation
        !           228: (with any invocation identifier)
        !           229: until a confirmation (result or error) is received.
        !           230: The performer has no state information regarding previously used invocation
        !           231: identifiers.
        !           232: 
        !           233: \item[at most once:] The invoker requests the operation exactly once with any
        !           234: invocation identifier.
        !           235: The performer has no state information regarding previously used invocation
        !           236: identifiers.
        !           237: \end{describe}
        !           238: 
        !           239: \subsection    {Keeping Total Operations Total}
        !           240: An operation may be thought of as {\em confirmed\/} when either a result or
        !           241: error is returned by the performer.
        !           242: However,
        !           243: under the OSI framework for remote operations,
        !           244: it is possible to have an operation which may only return a result,
        !           245: or may only return errors.
        !           246: This is a subtle point,
        !           247: but one worth emphasizing:
        !           248: in the past some operations have been defined which on success do not return
        !           249: a result,
        !           250: this lead to ambiguity in as much as the invoker could not determine the
        !           251: ``correct'' time to terminate the association,
        !           252: since ``silence'' on the part of the performer could mean that the operation
        !           253: completed successfully or that the operation was still in progress and an
        !           254: error return might be forthcoming.
        !           255: In keeping with the philosophy of total operations,
        !           256: it is important to have an operation return a result,
        !           257: even if the information is \verb"NULL".
        !           258: 
        !           259: \section      {For Further Reading}
        !           260: The first half of \cite{ECMA.ROS} is the most authoritative reference on
        !           261: using remote operations.
        !           262: In particular, Section~4.4
        !           263: presents a simple template methodology for using remote operations.
        !           264: As mentioned earlier,
        !           265: Section~5 and beyond have been obsoleted by work in ISO and CCITT.
        !           266: 
        !           267: In as much as the standards from these bodies deal with the remote operations
        !           268: service and protocol,
        !           269: they are not particularly germane here.
        !           270: The ISO work on remote operations is presented in
        !           271: \cite{ISO.ROS.Service} and \cite{ISO.ROS.Protocol}.
        !           272: The corresponding CCITT work is
        !           273: described in \cite{CCITT.ROS.Service} and \cite{CCITT.ROS.Protocol}.
        !           274: The native interface to these services are discussed in
        !           275: Chapter~\ref{librosap} of \volone/.

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