![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to concepts.tex CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / doc / manual|
Return to concepts.tex CVS log | Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / doc / manual |
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.