![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to discipline.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 discipline.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 {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.