Informationsobjektklass (ASN.1)

ASN.1 Information Object Class är ett begrepp som används ofta i ASN.1-specifikationer för att lösa problem relaterade till protokollspecifikationer som liknar problem som behandlas av CORBA/IDL-specifikationer.

Informationsobjektklasser används till exempel för att specificera ROSE-protokollet (Remote Operations Service Element) i ASN.1.

Förkortningar

Förkortningar som används i den här artikeln:

ASN.1
Abstrakt syntax Notation En
IOC-
informationsobjektklass
IOS
-informationsobjektuppsättning
IO
-informationsobjekt
SQL-
strukturerat frågespråk
PER
packade kodningsregler
BER
grundläggande kodningsregler
IDL-
gränssnittsdefinition Språk
CORBA
Common Object Request Broker Architecture
IIOP
Internet Inter-ORB Protocol

Introduktion

Det enklaste sättet att tänka på ASN.1 Information Object Classes är att betrakta dem som ett sätt att representera IDL-specifikation i ASN.1 med hjälp av begrepp som härrör från relationsdatabaserteorin och SQL-syntax i synnerhet.

Begreppen som används i ASN.1 är mer flexibla än de som används i IDL, eftersom de, för att fortsätta analogin, tillåter att "anpassa grammatiken" för "IDL-specifikationen". ASN.1-kodningsregler används som en överföringssyntax för fjärranrop som liknar CORBA/IIOP.

I ljuset av denna jämförelse kan vi dra en ungefärlig analogi mellan begrepp som används i informationsobjektklasser och SQL- och IDL-koncept som visas i tabell 1.

Tabell 1: Analogi mellan begrepp i ASN.1 Information Object Classes, SQL och IDL
ASN.1 term Analogi i SQL Analogi i IDL

Information Object Class (IOC)

SQL-tabellstrukturbeskrivning (CREATE TABLE-sats)

IDL grammatikspecifikation (BNF-regler)

IOK:s fältdeklaration

SQL-tabellkolumnbeskrivning i CREATE TABLE-satsen (typ av en kolumn)

IDL grammatikproduktion

Informationsobjekt (IO)

SQL-tabellrad (INSERT INTO-sats)

IDL-driftsdeklaration

IO-fältdefinition

Cell i SQL-tabellraden i INSERT INTO-satsen (cellvärde)

Del av IDL-operationsdeklaration, vanligtvis relaterad till deklaration av en operationstypkod, parameterlista, operationsreturvärde eller lista med undantag

Information Object Set (IOS) (samling av informationsobjekt)

Fullständigt definierad SQL-tabell (samling av rader) (se not 1)

IDL-gränssnittsdefinition (insamling av operationer)

ASN.1-datatyp som använder referenser till IOC-fält parametriserade med IOS (vanligtvis en samling semantiskt relaterade typer som anger begäran, svar och undantag, alla parametriserade med samma IOS)

-

Högnivåformat (grammatikspecifikation) för en ram (rangeringsbuffert) som bär CORBA-begäran, svar eller undantag

ASN.1-kodningsregler och överföringssyntaxer (BER, PER)

-

Lågnivåkodning av förfrågningar, svar och undantagsindikatorer lämpliga för fysisk överföring över mediet

Anmärkning 1 . Analogin mellan IOS och en SQL-tabell är inte helt korrekt. SQL tillåter endast en instans av en tabell av given typ (OPERATION i exemplet nedan), medan ASN.1 tillåter flera informationsobjektuppsättningar härledda från samma informationsobjektklass, vad som bör vara mest korrekt relaterat till flera instanser av samma tabell i termer av SQL (OPERATION i exemplet nedan).

Analogi med exempel

Tabell 2 illustrerar genom exempel överensstämmelse mellan ASN.1-koncept och liknande konstruktioner som finns i SQL och IDL.

Tabell 2: Analogi mellan begrepp i ASN.1 Information Object Classes, SQL och IDL, illustrerad med exempel
ASN.1 term ASN.1 exempel Analogi i SQL Analogi i IDL

IOC

 
OPERATION ::= KLASS { &operationCode INTEGER UNIQUE, &InvocationParsType, &ResponseParsAndResultType, &ExceptionList FEL VALFRITT }
 
  

    

   

   

 
 CREATE  TABLE  OPERATION  (  operationCode  heltal  inte  null  unik  ,  InvocationParsType  type_info  inte  null  ,  ResponseParsAndResultType  type_info  inte  null  ,  ExceptionList  ref_to_table  (  ERROR  )  )

(Se not 1 som förklarar typ_info och refer_to_table .)

Detta är ungefär analogt med en del av BNF-beskrivningen av någon pseudo-IDL-syntax av följande form (observera att i efterföljande exempel kommer vi att använda verklig IDL-syntax snarare än den imaginära som definieras av BNF nedan):

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

där Heltalsproduktion löser sig till ett heltalsvärde, Typ löser sig till en typreferens och ExceptionList löser sig till en instans av informationsobjektuppsättning härledd från ERROR Information Object Class (eller lista med undantag i fallet med 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 | fel avdelning } }
 
          INFOGA  I  OPERATIONSVÄRDEN  (  $  get_customers_num_op_type_code  ,  Get_customers_num_req_pars_type  ,  Get_customers_num_ind_pars_type  ,  Get_customers_num_exc_list  )  _

(Tokens som börjar med $ betraktas som en variabel (t.ex. i PHP) och de ska ersättas med ett verkligt variabelvärde.)

 
MyType1 getCustomersNum( i MyType2 par1, inout MyType3 par2, out MyType4 par3) höjer (ExcType1, ExcType2);

IOS

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

SQL-tabell definierad med en sekvens av INSERT-satser.

IDL-gränssnitt (insamling av operationer).

ASN.1 datatyper

 
Begär ::= SEKVENS { invokeId INTEGER, opcode OPERATION. &operationCode ({MyWarehouseOps}), req-pars OPERATION. &InvocationParsType ({MyWarehouseOps} {@opcode}) } Svar ::= SEQUENCE { invokeId INTEGER, opcode OPERATION. &operationCode ({MyWarehouseOps}), rsp-pars OPERATION. &ResponseParsAndResultType ({MyWarehouseOps} {@opcode}) } Undantag ::= SEQUENCE { err-code ERROR. &errorCode ({MyErrorSet}), err-body ERROR. &ErrorBody ({MyErrorSet} {@err-code}) }

(Se not 2, 3.)

-

Högnivåformat för en ram som bär CORBA-förfrågan, svar eller undantag.

BER, PER etc.

0110 0111 0010 110...

-

Lågnivåkodning av förfrågningar, svar och undantagsindikatorer.

Anmärkning 1 . SQL -datatyperna type_info och ref_to_table är imaginära datatyper. De finns inte i SQL och de introducerades på konstgjord väg för att bättre förklara ASN.1-koncept.

Datatypen type_info betyder att dess värde är en referens till en ASN.1-typ.

Datatypen ref_to_table betyder att dess värde är en referens till en annan instans av SQL-tabellen (ERROR-tabell i detta fall). Även om vi vet att vi i verklig SQL inte kan ha flera instanser av samma tabell, låt oss föreställa oss för att vår beskrivning ska vara korrekt, att vi faktiskt kan.

Not 2 . @-notationen (t.ex. @opcode ) definierar överensstämmelse mellan fält baserat på informationsobjektuppsättningen som används för att parametrisera datatypen i fråga. Till exempel @opcode att om opcodefältet innehåller något värde, så ska andra SEQUENCE-fält som är beroende av opcodefältet överensstämma med opcodevärdet . I SQL-termer ska kombinationen av typer och värden som bildar en juridisk instans av den typen tillhöra en enda rad i en tabell.

Anmärkning 3 . Exempelspecifikationen för ASN.1-datatyper definierar inte någon formell överensstämmelse mellan förfrågnings- , svars- och undantagstyper , även om OPERATION Information Object Class som används i alla tre typerna definierar en semantisk nivåkorrelation mellan begäran, svar och eventuellt fel villkor, medan definitionen av IDL-drift gör det formellt.

Därför tillämpar exempelspecifikationen inte formellt några scenarier för meddelandesekvenser. Till skillnad från IDL-operationsdefinitionen är överensstämmelsen mellan ramar icke-bindande och är rent semantisk, även om den kan utnyttjas av ett ASN.1-verktyg på ett verktygsspecifikt sätt.

Parametrisering

Om du noggrant undersöker ASN.1-exemplet som presenteras i Tabell 2 och jämför det med IDL-koncept, kommer du att se en viktig begränsning på ASN.1-sidan.

Våra exempel på ASN.1-datatyper som vi kommit överens om att jämföra med en CORBA/IDL-överföringssyntaxspecifikation på hög nivå är begränsade till definitionen av sådan överföringssyntax endast för en enda instans av vad vi jämförde med ett IDL-gränssnitt (Information Object Set i ASN .1 termer).

Med andra ord är sådan överföringssyntax inte generisk och den är inte återanvändbar.

Med den nuvarande uppsättningen kända verktyg kan du inte definiera en sådan överföringssyntax på ett generiskt sätt i t.ex. ASN.1-specifikation A och sedan återanvända den i ASN.1-specifikationerna B och C som definierar konkreta applikationsspecifika "IDL-gränssnitt " som A inte är beroende av.

Anledningen till den nuvarande begränsningen är att vi för närvarande hårdkodar vår informationsobjektuppsättning ( MyWarehouseOps vid OPERATION , eller MyErrorSet vid ERROR ) i våra ASN.1-datatyper (överföringssyntaxspecifikation på hög nivå).

Nu måste vi ta ett sista steg för att få ett komplett och fullt fungerande system. Vi måste introducera ett koncept för typparameterisering med informationsobjektuppsättning som en typformell parameter.

Här är vår förfrågningstyp omskriven med konceptet parametrisering i åtanke: 

Begär {OPERATION : OpSet} ::= SEQUENCE { invokeId INTEGER, opcode OPERATION.&operationCode ({OpSet}), req-pars OPERATION.&InvocationParsType ({OpSet} {@opcode}) }

Nu kan överföringssyntaxdeskriptorn Request på hög nivå parametreras med vilken godtycklig informationsobjektuppsättning som helst ("IDL-gränssnitt") som överensstämmer med informationsobjektklassspecifikationen ("IDL-grammatik").

Därför kan vi nu instansiera det för vilken informationsobjektuppsättning som helst enligt följande:

Request1 ::= Request{MyWarehouseOps} Request2 ::= Request{MyOtherSetOfOps} -- etc.

WITH SYNTAX-satsen

WITH SYNTAX-satsen är faktiskt ett litet grammatikspråk som används för att uttrycka syntaktiska definitioner av informationsobjekt.

Tänk på följande exempel:

OPERATION ::= KLASS { &opcode INTEGER UNIQUE, &InvocationParsType, &ResponseParsAndResultType, &ExceptionList FEL VALFRITT } MED SYNTAX { OPCODE &opcode BEGÄRAN ARGUMENT &InvocationParsType SVARARGUMENT &ResultatResponser &ResultatResponser &Result

Inneslutning inom hakparenteser ([]) betyder valbarhet av syntaktiska konstruktioner som finns i [].

Tillval kan kapslas.

Tokens i stort betyder nyckelord, tokens som börjar med och betyder produktioner som kräver ersättning av motsvarande enhet i stället för token (ASN.1-värde, typ eller informationsobjektuppsättning, antingen instans eller referens därav), beroende på informationsobjektklassen som detta fält avser.

Vad vi annars skulle ha skrivits som:

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

i närvaro av WITH SYNTAX-satsen kan skrivas om enligt följande:

getCustomersNum OPERATION ::= { OPCODE get-customers-num-op-type-code, REQUEST ARGUMENT Get-customers-num-req-pars-type, SVARARGUMENT Get-customers-num-ind-pars-type, -- enligt till BNF i WITH SYNTAX-satsdelen, kan följande rad utelämnas FEL { wrong-product | fel avdelning } }

För att till fullo förstå grammatikkonceptet bakom WITH SYNTAX-satsen, föreställ dig att vi skrev vår OPERATION Information Object Class-definition enligt följande:

OPERATION ::= KLASS { &opcode INTEGER UNIQUE, &InvocationParsType, &ResponseParsAndResultType, &ExceptionList FEL VALFRITT } MED SYNTAX { &opcode &InvocationParsType &ResponseParsAndResultType [&ExceptionList] }

Då ska en motsvarande informationsobjektsinstans för definitionen ovan definieras enligt följande:

getCustomersNum OPERATION ::= { get-customers-num-op-type-code Get-customers-num-req-pars-type Get-customers-num-ind-pars-type { wrong-product | fel avdelning } }

Se även

externa länkar

Hämtad från " https://en.wikipedia.org/w/index.php?title=Information_Object_Class_(ASN.1)&oldid=1131564935 "