⟦fb08838cb⟧

TextFile

% -*- LaTeX -*-		(really SLiTeX)

\f

\begin{bwslide}
\part	{A MODEL FOR DISTRIBUTED APPLICATIONS}\bf

\begin{nrtc}
\item	ABSTRACT DATA TYPES

\item	OPERATIONS

\item	ASSOCIATIONS

\item	DESIGN GUIDELINES

\item	IN PERSPECTIVE
\end{nrtc}
\end{bwslide}


\f

\begin{note}\em
this part of the presentation corresponds to chapter~2 in The Application
Cookbook

our focus is on the 1984--style of remote operations ([X.410])
and the newer joint-iso-ccitt work ([ISO~9072/1])
\end{note}


\f

\begin{bwslide}
\ctitle	{USE OF REMOTE OPERATIONS IN OSI}

\begin{nrtc}
\item	{}[ECMA~TR/31] PRESENTS A METHOD FOR USING REMOTE OPERATIONS TO:
    \begin{nrtc}
    \item	SPECIFY THE EXTERNALLY VISIBLE CHARACTERISTICS
		NEEDED FOR INTERCONNECTION

    \item	WHILE AVOIDING UNNECESSARY CONSTRAINTS UPON THE
		INTERNAL DESIGN OF THE SYSTEMS TO BE INTERCONNECTED
    \end{nrtc}

\item	ALTHOUGH THE LATTER HALF OF THIS DOCUMENT (THE PROTOCOL) IS NOW
	OBSOLETE, THE FIRST FOUR SECTIONS (THE METHOD) ARE QUITE RELEVANT

\item	{}[ECMA~TR/31] IS BASED ON [X.410],
	WE TERM THIS ``OLD-STYLE'' ROS

\item	{}[ISO~9072] IS THE NEWER JOINT ISO/CCITT WORK,
	WE TERM THIS ``NEW-STYLE'' ROS
\end{nrtc}
\end{bwslide}


\f

\begin{note}\em
note that ECMA documents are not standards,
though they may be used as contributions to the standards process
\end{note}


\f

\begin{bwslide}
\ctitle	{A BIT OF HISTORY}

\begin{nrtc}
\item	XEROX's COURIER WAS THE FIRST WELL-KNOWN SYSTEM TO USE THIS APPROACH

\item	BUT EVEN IN THE EARLY 70's, SIMILAR IDEAS WERE BEING EXPLORED
	ELSEWHERE (e.g., MIT)

\item	TODAY, SUN's RPC AND APOLLO's NCS ARE CONTINUING IN THIS VEIN
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\part*	{ABSTRACT DATA TYPES}\bf

\begin{nrtc}
\item	REMOTE OPERATIONS ARE A MECHANISM BY WHICH LOOSELY COUPLED SYSTEMS
	INTERACT

\item	BUT, REMOTE OPERATIONS ARE ONLY ONE PART OF A LARGER PICTURE HOWEVER

\item	THE FUNDAMENTAL CONCEPT IS THAT OF THE \emph{ABSTRACT DATA TYPE}
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{ABSTRACT DATA TYPES}

\begin{nrtc}
\item	PUT SIMPLY, AN ABSTRACT DATA TYPE DEFINES BOTH
    \begin{nrtc}
    \item	THE DATA STRUCTURE CONTAINED IN AN OBJECT (SYNTAX), AND

    \item	HOW THAT DATA IS INTERPRETED (SEMANTICS)
    \end{nrtc}

\item	THIS IS HARDLY A NEW CONCEPT
    \begin{nrtc}
    \item	e.g., SMALLTALK, SIMULA, and so on
    \end{nrtc}
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{PROPERTIES OF ABSTRACT DATA TYPES:\\ REPRESENTATION}

\begin{nrtc}
\item	DATA STRUCTURES IN PROGRAMMING LANGUAGES HAVE A \emph{CONCRETE}
	REPRESENTATION
    \begin{nrtc}
    \item	WHICH IS DEFINED BY THE PROGRAMMING LANGUAGE AND THE
		UNDERLYING HARDWARE

    \item	e.g., BYTE-ORDERING, WORD SIZE, etc.
    \end{nrtc}

\item	THE CORRESPONDING ABSTRACT DATA TYPE IS DEFINED IN AN
	IMPLEMENTATION-INDEPENDENT FASHION
    \begin{nrtc}
    \item	TERMED THE \emph{ABSTRACT SYNTAX}
    \end{nrtc}

\item	AN APPLICATION CAN EXPECT THIS TO BEHAVE CONSISTENLY REGARDLESS OF THE
	HARDWARE ON WHICH IT IS RUNNING
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{REPRESENTATION: EXAMPLE}

\vskip.15in
\begin{verbatim}
struct mail_address {
    char   *local;
    char   *domain;

    unsigned char options;
#define default_local 0x01
#define default_host  0x02
};
\end{verbatim}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{REPRESENTATION: EXAMPLE (cont.)}

\vskip.15in
\begin{verbatim}
Mail-Address ::=
        [APPLICATION 2]
            IMPLICIT SEQUENCE {
                local[0]
                    IMPLICIT GraphicString,

                domain[1]
                    IMPLICIT GraphicString,

                options[2]
                    IMPLICIT BITSTRING {
                        default-local(0), default-host(1)
                    }
                    DEFAULT { default-local, default-host }
            }
\end{verbatim}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{PROPERTIES OF ABSTRACT DATA TYPES:\\ SERIALIZATION}

\begin{nrtc}
\item	\emph{ABSTRACT TRANSFER NOTATION}:
    \begin{nrtc}
    \item	A WELL-DEFINED SET OF RULES USED TO DEFINE HOW ABSTRACT DATA
		TYPES ARE TRANSMITTED THROUGH THE NETWORK
    \end{nrtc}
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{SERIALIZATION (cont.)}

\begin{nrtc}
\item	CONCEPTUALLY, TWO MAPPINGS OCCUR

\item	FIRST, THE DATA STRUCTURE IS MAPPED TO THE ABSTRACT SYNTAX FOR ITS
	CORRESPONDING ABSTRACT DATA TYPE
    \begin{nrtc}
    \item	THIS IS A LOCAL ISSUE
    \end{nrtc}

\item	SECOND, THE ABSTRACT SYNTAX IS MAPPED TO THE CONCRETE SYNTAX,
	A STREAM OF OCTETS
    \begin{nrtc}
    \item	THE ABSTRACT TRANSFER NOTATION IS USUALLY [ISO~8825]

    \item	OTHER POSSIBILITIES INCLUDE COMPRESSION, ENCRYPTION, etc.
    \end{nrtc}

\item	NOTE THAT THE CONCRETE REPRESENTATION MENTIONED EARLIER FOR
	DATA STRUCTURES IS {\bf NOT\/} THE SAME AS THE CONCRETE SYNTAX
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{PROPERTIES OF ABSTRACT DATA TYPES:\\ OPERATIONS}

\begin{nrtc}
\item	ACCESS TO AN ABSTRACT DATA TYPE IS DEFINED BY A SET OF PRIMITIVE
	ACTIONS

\item	EACH PRIMITIVE ACTION IS TERMED AN \emph{OPERATION}

\item	THIS SET OF OPERATIONS DEFINES THE COMPLETE BEHAVIOR OF AN ABSTRACT
	DATA TYPE
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{PROPERTIES OF ABSTRACT DATA TYPES:\\ OBJECT MODEL}

\begin{nrtc}
\item	SINCE OPERATIONS INTRODUCE A LEVEL OF INDIRECTION,
	USING ABSTRACT DATA TYPES RATHER THAN CONCRETE DATA STUCTURES
	PERMITS ACCESS TO DATA STRUCTURES WITHOUT REGARD TO THEIR ACTUAL
	IMPLEMENTATION
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\part*	{OPERATIONS}\bf

\begin{nrtc}
\item	IN ITS PRIMITIVE FORM,
	AN \emph{OPERATION} IS A SIMPLE REQUEST/REPLY INTERACTION

\item	A \emph{INVOCATION} GENERATES ONE OF THREE OUTCOMES:
    \begin{nrtc}
    \item	A \emph{RESULT}, IF THE OPERATION SUCCEEDS;

    \item	AN \emph{ERROR}, IF THE OPERATION FAILED; or,

    \item	A \emph{REJECTION}, IF THE OPERATION WAS NOT PERFORMED
    \end{nrtc}

\item	OPERATIONS ARE SAID TO BE \emph{TOTAL}, AS THE NORMAL OUTCOME (RESULT),
	AND THE EXCEPTION OUTCOMES (THE ERRORS) ARE WELL-DEFINED AND
	UNAMBIGUOUS
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{PROPERTIES OF OPERATIONS:\\ INVOCATIONS}

\begin{nrtc}
\item	THE OPERATION IS \emph{INVOKED} WHEN IT IS REQUESTED

\item	AN INVOCATION CONSISTS OF:
    \begin{nrtc}
    \item	AN \emph{OPERATION NUMBER} IDENTIFYING THE OPERATION REQUESTED

    \item	AN ARBITRARILY COMPLEX \emph{ARGUMENT}

    \item	AN \emph{INVOCATION IDENTIFIER} DISTINGUISHING THIS INVOCATION
		FROM PREVIOUS INVOCATIONS

    \item	(POSSIBLY) A \emph{LINKED-INVOCATION IDENTIFIER}
    \end{nrtc}
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{LINKED INVOCATIONS}

\begin{nrtc}
\item	INTRODUCED IN THE NEWER JOINT ISO/CCITT WORK

\item	SOMETIMES REFERRED TO AS A ``CALLBACK'' OR A ``REMOTE UPCALL''
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{EXAMPLE:\\ LINKED INVOCATIONS}

\begin{nrtc}
\item	CONSIDER AN OPERATION \verb"Traverse", WITH TWO ARGUMENTS:
    \begin{nrtc}
    \item	THE NAME OF A REMOTE DIRECTORY IN A FILESYSTEM

    \item	THE NUMBER OF AN OPERATION TO INVOKE FOR EACH FILE
		(WITH A HANDLE TO THE FILE)
    \end{nrtc}

\item	TO LIST A REMOTE DIRECTORY:
\begin{verbatim}
Traverse (``directory-name'', ListFile)
\end{verbatim}

\item	TO PRINT EACH FILE IN A REMOTE DIRECTORY:
\begin{verbatim}
Traverse (``directory-name'', PrintFile)
\end{verbatim}
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{PROPERTIES OF OPERATIONS:\\ RESULTS}

\begin{nrtc}
\item	IF THE OPERATION SUCCEEDS, THEN A RESULT IS RETURNED

\item	A RESULT CONSISTS OF:
    \begin{nrtc}
    \item	AN INVOCATION IDENTIFIER CORRESPONDING TO THE OPERATION WHICH
		SUCCEEDED

    \item	(POSSIBLY) AN ARBITRARILY COMPLEX \emph{RESULT}
    \end{nrtc}
\end{nrtc}
\end{bwslide}


\f

\begin{note}\em
actually, on success a result \emph{may optionally} be returned as some
operations are defined to not return any result

this violates the totality principle, a solution is discussed later on
\end{note}


\f

\begin{bwslide}
\ctitle	{PROPERTIES OF OPERATIONS:\\ ERRORS}

\begin{nrtc}
\item	IF THE OPERATION FAILS, THEN AN ERROR IS RETURNED

\item	AN ERROR CONSISTS OF:
    \begin{nrtc}
    \item	AN INVOCATION IDENTIFIER CORRESPONDING TO THE OPERATION WHICH
		FAILED

    \item	AN \emph{ERROR NUMBER} IDENTIFYING THE ERROR ENCOUNTERED

    \item	(POSSIBLY) AN ARBITRARILY COMPLEX \emph{PARAMETER}
    \end{nrtc}

\item	NOTE THAT ERRORS DO NOT NECESSARILY INDICATE BAD BEHAVIOR!
    \begin{nrtc}
    \item	THEY CAN OCCUR AS A PART OF CORRECT AND NORMAL OPERATIONS

	\item	HENCE, THINK OF THEM AS EXCEPTIONS
    \end{nrtc}
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{PROPERTIES OF OPERATIONS:\\ REJECTIONS}

\begin{nrtc}
\item	IF THE OPERATION CAN NOT BE PERFORMED, THEN A REJECTION IS RETURNED

\item	A REJECTION CONSISTS OF:
    \begin{nrtc}
    \item	AN INVOCATION IDENTIFIER CORRESPONDING TO THE OPERATION WHICH
		WAS REJECTED

    \item	A \emph{REASON} EXPLAINING WHY THE OPERATION WAS REJECTED
	\begin{nrtc}
	\item	e.g., MISTYPED PARAMETERS
	\end{nrtc}
    \end{nrtc}

\item	SOME REJECTIONS ARE USER-INITIATED, OTHERS ARE PROVIDER-INITIATED
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\part*	{ASSOCIATIONS}\bf

\begin{nrtc}
\item	AN \emph{ASSOCIATION} IS A BINDING BETWEEN TWO ENTITIES,
	THE \emph{INITIATOR} AND THE \emph{RESPONDER}

\item	ASSOCIATIONS EXIST AT THE APPLICATION LAYER AND
	RELY ON AN UNDERLYING CONNECTION

\item	ASSOCIATIONS MAY BE SYMMETRIC, i.e., THEY DON'T HAVE TO FOLLOW A
	CLIENT/SERVER MODEL
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{ASSOCIATIONS (cont.)}

\begin{nrtc}
\item	THE BINDING OCCURS IN A TWO-STEP PROCESS

\item	FIRST, THE INITIATOR DETERMINES WHICH SERVICE IT REQUIRES,
	AND ASKS (DIRECTORY SERVICES) TO MAP THIS SERVICE ONTO
	ENTITIES AVAILABLE ON THE NETWORK

\item	SECOND, BASED ON THE INITIATOR'S COMMUNICATION NEEDS
	(QUALITY OF SERVICE), AN ASSOCIATION WILL BE BOUND TO ONE OF
	THOSE ENTITIES WHICH BECOMES THE RESPONDER
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\part*	{DESIGN GUIDELINES}\bf

\begin{nrtc}
\item	THE CHARACTERISTICS OF OPERATIONS WILL VARY WIDELY BETWEEN APPLICATIONS

\item	HOWEVER, THERE ARE TWO ISSUES OF UNIVERSAL INTEREST TO BE CONSIDERED
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{RELIABILITY CHARACTERISTICS}

\begin{nrtc}
\item	UNCERTAINTY DURING EXECUTION OF OPERATIONS IS ALWAYS PRESENT

\item	THIS IS PARTICULARLY TROUBLESOME IF THE NETWORK ``BREAKS''
	AFTER A REQUEST IS RECEIVED BY THE RESPONDER BUT BEFORE
	THE INITIATOR RECEIVES THE REPLY

\item	ONE SCHEME OF CLASSIFYING THE RELIABILITY REQUIREMENTS OF AN OPERATION
	IS:
    \begin{nrtc}
    \item	EXACTLY ONCE

    \item	AT LEAST ONCE (IDEMPOTENT)

    \item	AT MOST ONCE
    \end{nrtc}

\item	IMPLEMENTING THESE SEMANTICS IS POSSIBLE USING THE INVOCATION
	IDENTIFIER
    \begin{nrtc}
    \item	BUT IS THE RESPONSBILITY OF THE USER OF REMOTE OPERATIONS
    \end{nrtc}
\end{nrtc}
\end{bwslide}


\f

\begin{note}\em
note that ``initiator'' here doesn't necessarily mean the entity which
initiated the association

i.e., an entity can start an association, and then it's peer could possibly
initiate all of the operations
\end{note}


\f

\begin{bwslide}
\ctitle	{RELIABILITY CHARACTERISTIC:\\ EXACTLY ONCE}

\begin{nrtc}
\item	RESPONDER
    \begin{nrtc}
    \item	KEEPS TRACK OF THE INVOCATION IDENTIFIERS OF ALL PERFORMED
		OPERATIONS

    \item	WHEN PROCESSING AN INVOCATION, IF AN INVOCATION IDENTIFIER IS
		REPEATED, REJECT THE OPERATION 
    \end{nrtc}

\item	INITIATOR
    \begin{nrtc}
    \item	REPEATEDLY INVOKES THE OPERATION USING THE SAME INVOCATION
		IDENTIFIER UNTIL EITHER

    \item	A CONFIRMATION (RESULT OR ERROR) IS RECEIVED, OR

    \item	A REJECTION (DUPLICATE OPERATION) IS RECEIVED
    \end{nrtc}

\item	A ROS BUG: REJECTION DOES NOT INCLUDE THE VALUE OF THE PREVIOUS RESULT!
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{RELIABILITY CHARACTERISTIC:\\ AT LEAST ONCE}

\begin{nrtc}
\item	RESPONDER
    \begin{nrtc}
    \item	KEEPS NO INFORMATION REGARDING PREVIOUSLY PERFORMED OPERATIONS
    \end{nrtc}

\item	INITIATOR
    \begin{nrtc}
    \item	REPEATEDLY INVOKES THE OPERATION (WITH ANY INVOCATION
		IDENTIFIER) UNTIL

    \item	A CONFIRMATION (RESULT OR ERROR) IS RECEIVED
    \end{nrtc}
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{RELIABILITY CHARACTERISTIC:\\ AT MOST ONCE}

\begin{nrtc}
\item	RESPONDER
    \begin{nrtc}
    \item	KEEPS NO INFORMATION REGARDING PREVIOUSLY PERFORMED OPERATIONS
    \end{nrtc}

\item	INITIATOR
    \begin{nrtc}
    \item	INVOKES THE OPERATION (WITH ANY INVOCATION IDENTIFIER)
		EXACTLY ONCE
    \end{nrtc}
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{KEEPING TOTAL OPERATIONS TOTAL}

\begin{nrtc}
\item	IN THE OSI FRAMEWORK, IT IS POSSIBLE TO DEFINE OPERATIONS WHICH:
    \begin{nrtc}
    \item 	RETURN A RESULT, BUT NO ERRORS

    \item	RETURN ONLY ERRORS
    \end{nrtc}

\item	THIS CAN POTENTIALLY VIOLATE THE TOTALITY PRINCIPLE
    \begin{nrtc}
    \item	(ALL OUTCOMES ARE WELL-DEFINED AND UNAMBIGUOUS)
    \end{nrtc}
    AS AN OPERATION WHICH SUCCEEDS BUT RETURNS NO RESULT WILL RETURN NOTHING!

\item	THIS IN TURN LEADS TO PROBLEMS WHEN THE INITIATOR TRIES TO DETERMINE
	IF THE OPERATION SUCCEEDED OR NOT (HOW LONG TO WAIT FOR AN ERROR?)

\item	SOLUTION: OPERATIONS SHOULD ALWAYS BE ABLE TO RETURN A RESULT,
	EVEN IF THAT RESULT IS \verb"NULL"
\end{nrtc}
\end{bwslide}


\f

\begin{note}\em
note that this totality issue is a philosophical one

some may argue that it is valid only for a class of applications
\end{note}


\f

\begin{bwslide}
\part*	{IN PERSPECTIVE}\bf

\begin{nrtc}
\item	IDEALLY WOULD LIKE TO HIDE ALL (OR MOST) OF THIS FORMALISM FROM
	THE PROGRAMMER

\item	INSTEAD, WE'D LIKE TO PRESENT A SIMPLE PROCEDURE CALL MODEL IN WHICH
	WE DEFINE:
        \begin{nrtc}
	\item	THE INTERFACE TO EACH OPERATION AS A SUBROUTINE CALL

	\item	WITH KNOWN ARGUMENT TYPES
	\end{nrtc}
\end{nrtc}
\end{bwslide}


\begin{bwslide}
\ctitle	{AN EXAMPLE (cont.)}

\vskip.15in
\begin{verbatim}
int     op_CMIP_m__ConfirmedEventReport (sd, in, out, roi)
int     sd;
struct type_CMIP_EventReportArgument *in;
struct type_CMIP_EventReportResult *out;
struct RoSAPindication *roi;
\end{verbatim}
\end{bwslide}


\begin{bwslide}
\ctitle	{AN EXAMPLE (cont.)}

\vskip.15in
\begin{verbatim}
struct type_CMIP_EventReportArgument {
    struct type_CMIP_ObjectClass *managedObjectClass;

    struct type_CMIP_ObjectInstance *managedObjectInstance;

    struct type_CMIP_EventTypeID *eventType;

    struct type_UNIV_GeneralizedTime *eventTime;

    struct type_CMIP_EventInfo *eventInfo;
};
\end{verbatim}
\end{bwslide}
DataMuseum.dk

DKUUG/EUUG Conference tapes

⟦fb08838cb⟧ TextFile

Derivation

TextFile
