Analogy By Example
Table 2 illustrates by example correspondence of ASN.1 concepts to similar constructs found in SQL and IDL.
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 |
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 ::= ERRORwhere |
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 The The Note 2. The @ notation (e.g. Note 3. The example specification of ASN.1 data types does not define any formal correspondence between 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 analogy between the mind and a computer fails for many reasons. The brain is constructed by principles that assure diversity and degeneracy. Unlike a computer, it has no replicative memory. It is historical and value driven. It forms categories by internal criteria and by constraints acting at many scales, not by means of a syntactically constructed program. The world with which the brain interacts is not unequivocally made up of classical categories.”
—Gerald M. Edelman (b. 1928)