Information Object Class (ASN.1) - Analogy By Example

Analogy By Example

Table 2 illustrates by example correspondence of ASN.1 concepts to similar constructs found in SQL and IDL.

Table 2: Analogy between concepts in ASN.1 Information Object Classes, SQL, and IDL, illustrated by example
ASN.1 term ASN.1 example Analogy in SQL Analogy in IDL

IOC

 OPERATION ::= CLASS { &operationCode INTEGER UNIQUE, &InvocationParsType, &ResponseParsAndResultType, &ExceptionList ERROR OPTIONAL } CREATE TABLE OPERATION ( operationCode integer not null unique, InvocationParsType type_info not null, ResponseParsAndResultType type_info not null, ExceptionList ref_to_table(ERROR) )

(See Note 1 explaining type_info and ref_to_table.)

This is approximately analogous to a portion of BNF description of some pseudo-IDL syntax of the following form (note that in subsequent examples we will be using real IDL syntax rather than the imaginary one defined by the BNF below):

OPERATION ::= operationCode InvocationParsType ResponseParsAndResultType ExceptionList operationCode ::= Integer InvocationParsType ::= Type ResponseParsAndResultType ::= Type ExceptionList ::= ERROR

where Integer production resolves to an integer value, Type resolves to a type reference, and ExceptionList resolves to an instance of Information Object Set derived from ERROR Information Object Class (or list of exceptions in case of IDL).

IO

 getCustomersNum OPERATION ::= { &operationCode get-customers-num-op-type-code, &InvocationParsType Get-customers-num-req-pars-type, &ResponseParsAndResultType Get-customers-num-ind-pars-type, &ExceptionList { wrong-product | wrong-department } } INSERT INTO OPERATION VALUES ( $get_customers_num_op_type_code, Get_customers_num_req_pars_type, Get_customers_num_ind_pars_type, Get_customers_num_exc_list )

(Tokens starting with $ are regarded as a variable (e.g. in PHP) and they shall be substituted with a real variable value.)

 MyType1 getCustomersNum( in MyType2 par1, inout MyType3 par2, out MyType4 par3) raises (ExcType1, ExcType2);

IOS

 MyWarehouseOps OPERATION ::= { getCustomersNum | getPiecesNum | appendItem }

SQL table defined using a sequence of INSERT statements.

IDL interface (collection of operations).

ASN.1 data types

 Request ::= SEQUENCE { invokeId INTEGER, opcode OPERATION. &operationCode ({MyWarehouseOps}), req-pars OPERATION. &InvocationParsType ({MyWarehouseOps} {@opcode}) } Response ::= SEQUENCE { invokeId INTEGER, opcode OPERATION. &operationCode ({MyWarehouseOps}), rsp-pars OPERATION. &ResponseParsAndResultType ({MyWarehouseOps} {@opcode}) } Exception ::= SEQUENCE { err-code ERROR. &errorCode ({MyErrorSet}), err-body ERROR. &ErrorBody ({MyErrorSet} {@err-code}) }

(See Notes 2, 3.)

-

High-level format of a frame carrying CORBA request, response, or exception.

BER, PER etc.

0110 0111 0010 110...

-

Low-level encoding of requests, responses and exception indicators.

Note 1. The type_info and ref_to_table SQL data types are imaginary data types. They do not exist in SQL and they were introduced artificially to help better explain ASN.1 concepts.

The type_info data type means that its value is a reference to an ASN.1 type.

The ref_to_table data type means that its value is a reference to another instance of SQL table (ERROR table in this case). While we know that in real SQL we can't have multiple instances of the same table, let's imagine for the purposes of accuracy of our description that we actually can.

Note 2. The @ notation (e.g. @opcode) defines correspondence between fields based on the Information Object Set used to parameterize the data type in question. For example, @opcode says that if the opcode field contains some value, then other SEQUENCE fields dependent on the opcode field shall be consistent with the opcode value. In SQL terms, the combination of types and values forming a legal instance of that type shall belong to a single row of a table.

Note 3. The example specification of ASN.1 data types does not define any formal correspondence between Request, Response, and Exception types, event though the OPERATION Information Object Class used in all three types defines a semantic-level correlation between request, response, and possible error conditions, while IDL operation definition does so formally.

Therefore, the example specification does not formally enforce any message sequence scenarios. Unlike IDL operation definition, the correspondence between frames is non-binding and is purely semantical, although it can be exploited by an ASN.1 tool in a tool-specific fashion.

Read more about this topic:  Information Object Class (ASN.1)

Famous quotes containing the word analogy:

    “The whole of natural theology ... resolves itself into one simple, though somewhat ambiguous proposition, That the cause or causes of order in the universe probably bear some remote analogy to human intelligence.”
    —David Hume (1711–1776)