Information Object Class (ASN.1)

From Wikipedia, the free encyclopedia

ASN.1 Information Object Class is a concept widely used in ASN.1 specifications to address issues related to protocol specification similar to issues addressed by CORBA/IDL specifications.

Information Object Classes are used for example to specify ROSE (Remote Operations Service Element) protocol in ASN.1.

Abbreviations[]

Abbreviations used throughout this article:

ASN.1
Abstract Syntax Notation One
IOC
IOS
IO
SQL
Structured Query Language
PER
Packed Encoding Rules
BER
Basic Encoding Rules
IDL
Interface Definition Language
CORBA
Common Object Request Broker Architecture
IIOP
Internet Inter-ORB Protocol

Introduction[]

The simplest way of thinking of ASN.1 Information Object Classes is to regard them as a way to represent IDL specification in ASN.1 using concepts derived from the relational databases theory and SQL syntax in particular.

The concepts used in ASN.1 are more flexible than the ones used in IDL, because, continuing the analogy, they allow to "customize grammar" of the "IDL specification". ASN.1 encoding rules are used as a transfer syntax for remote invocations that resemble CORBA/IIOP.

In the light of this comparison, we can draw an approximate analogy between concepts used in Information Object Classes and SQL and IDL concepts as shown in Table 1.

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

Information Object Class (IOC)

SQL table structure descriptor (CREATE TABLE statement)

IDL grammar specification (BNF rules)

IOC field declaration

SQL table column descriptor in CREATE TABLE statement (type of a column)

IDL grammar production

Information Object (IO)

SQL table row (INSERT INTO statement)

IDL operation declaration

IO field definition

Cell of SQL table row in INSERT INTO statement (cell value)

Portion of IDL operation declaration, typically related to declaration of an operation type code, parameter list, operation return value, or list of exceptions

Information Object Set (IOS) (collection of Information Objects)

Completely defined SQL table (collection of rows) (see Note 1)

IDL interface definition (collection of operations)

ASN.1 data type using references to IOC fields parameterized with IOS (typically a collection of semantically related types designating request, response, and exception, all parameterized with the same IOS)

-

High-level format (grammar specification) of a frame (marshalling buffer) carrying CORBA request, response, or exception

ASN.1 encoding rules and transfer syntaxes (BER, PER)

-

Low-level encoding of requests, responses and exception indicators suitable for physical transfer over the medium

Note 1. The analogy between IOS and an SQL table is not quite correct. SQL permits only one instance of a table of given type (OPERATION in the example below), while ASN.1 permits multiple Information Object Sets derived from the same Information Object Class, what should be most correctly related to multiple instances of the same table in terms of SQL (OPERATION in the example below).

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.

Parameterization[]

If you carefully examine the ASN.1 example presented in Table 2 and compare it to IDL concepts, you will see one important limitation on the ASN.1 side.

Our example ASN.1 data types which we agreed to compare to a high-level CORBA/IDL transfer syntax specification are limited to definition of such transfer syntax only for a single instance of what we compared to an IDL interface (Information Object Set in ASN.1 terms).

In other words, such transfer syntax is not generic and it is not reusable.

With the current set of known tools you can't define such a transfer syntax in a generic way in, say, ASN.1 specification A and then reuse it in ASN.1 specifications B and C that define concrete application-specific "IDL interfaces" on which A does not depend.

The reason for the current limitation is that we currently hard-code our Information Object Set (MyWarehouseOps in case of OPERATION, or MyErrorSet in case of ERROR) into our ASN.1 data types (high-level transfer syntax specification).

Now we need to make one last step to have a complete and fully functioning system. We need to introduce a concept of type parameterization using Information Object Set as a type formal parameter.

Here is our Request type rewritten with the concept of parameterization in mind: 

Request {OPERATION : OpSet} ::= SEQUENCE
{
    invokeId INTEGER,

    opcode OPERATION.&operationCode ({OpSet}),

    req-pars OPERATION.&InvocationParsType ({OpSet} {@opcode})
}

Now the high-level transfer syntax descriptor Request can be parameterized with any arbitrary Information Object Set ("IDL interface") conforming to the Information Object Class specification ("IDL grammar").

Therefore, we can now instantiate it for any Information Object Set as follows: 

Request1 ::= Request{MyWarehouseOps}
Request2 ::= Request{MyOtherSetOfOps}

-- etc.

The WITH SYNTAX clause[]

The WITH SYNTAX clause is effectively a tiny grammar language used to express ways of syntactic definitions of Information Objects.

Consider the following example: 

OPERATION ::= CLASS
{
    &opcode INTEGER UNIQUE,
    &InvocationParsType,
    &ResponseParsAndResultType,
    &ExceptionList ERROR OPTIONAL
}
WITH SYNTAX
{
    OPCODE &opcode
    REQUEST ARGUMENTS &InvocationParsType
    RESPONSE ARGUMENTS &ResponseParsAndResultType
    [ERRORS &ExceptionList]
}

Enclosure in square brackets ([]) means optionality of syntactic constructs contained in [].

Optionality can be nested.

Tokens all in capital mean keywords, tokens starting with & mean productions requiring substitution of the corresponding entity in place of the token (ASN.1 value, type, or Information Object Set, either instance or reference thereof), depending on the Information Object Class to which this field refers.

Now what we would have otherwise been written as: 

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 }
}

in the presence of the WITH SYNTAX clause can be rewritten as follows: 

getCustomersNum OPERATION ::=
{
    OPCODE get-customers-num-op-type-code,

    REQUEST ARGUMENTS Get-customers-num-req-pars-type,

    RESPONSE ARGUMENTS Get-customers-num-ind-pars-type,

    -- according to BNF in the WITH SYNTAX clause, the following line can be omitted
    ERRORS { wrong-product | wrong-department }
}

To fully understand the grammar concept behind the WITH SYNTAX clause, imagine we wrote our OPERATION Information Object Class definition as follows: 

OPERATION ::= CLASS
{
    &opcode INTEGER UNIQUE,
    &InvocationParsType,
    &ResponseParsAndResultType,
    &ExceptionList ERROR OPTIONAL
}
WITH SYNTAX
{
    &opcode
    &InvocationParsType
    &ResponseParsAndResultType
    [&ExceptionList]
}

Then a corresponding Information Object instance for the definition above is to be defined as follows: 

getCustomersNum OPERATION ::=
{
    get-customers-num-op-type-code

    Get-customers-num-req-pars-type

    Get-customers-num-ind-pars-type

    { wrong-product | wrong-department }
}

See also[]

ASN.1

References[]

External links[]

Retrieved from ""