Clase de objeto de información (ASN.1)

La clase de objeto de información ASN.1 es un concepto ampliamente utilizado en las especificaciones ASN.1 para abordar problemas relacionados con la especificación de protocolos, similares a los problemas abordados por las especificaciones CORBA/IDL.

Las clases de objetos de información se utilizan, por ejemplo, para especificar el protocolo ROSE (Remote Operations Service Element) en ASN.1.

Abreviaturas utilizadas a lo largo de este artículo:

ASN.1

Notación de sintaxis abstracta uno

COI

Clase de objeto de información

iOS

Conjunto de objetos de información

E/S

Objeto de información

SQL

Lenguaje de consulta estructurado

POR

Reglas de codificación empaquetada

BER

Reglas básicas de codificación

IDL

Lenguaje de definición de interfaz

CORBA

Arquitectura de agente de solicitud de objetos comunes

IIOP

Protocolo Inter-ORB de Internet

La forma más sencilla de entender las clases de objetos de información de ASN.1 es considerarlas como una manera de representar la especificación IDL en ASN.1 utilizando conceptos derivados de la teoría de bases de datos relacionales y, en particular, de la sintaxis SQL.

Los conceptos utilizados en ASN.1 son más flexibles que los de IDL, ya que, siguiendo la analogía, permiten "personalizar la gramática" de la "especificación IDL". Las reglas de codificación de ASN.1 se utilizan como sintaxis de transferencia para invocaciones remotas similares a CORBA/IIOP.

A la luz de esta comparación, podemos establecer una analogía aproximada entre los conceptos utilizados en las clases de objetos de información y los conceptos de SQL e IDL, como se muestra en la Tabla 1.

La tabla 2 ilustra, mediante ejemplos, la correspondencia entre los conceptos de ASN.1 y construcciones similares que se encuentran en SQL e IDL.

Si examina detenidamente el ejemplo de ASN.1 presentado en la Tabla 2 y lo compara con los conceptos de IDL, observará una limitación importante en el lado de ASN.1.

Los tipos de datos ASN.1 de ejemplo que acordamos comparar con una especificación de sintaxis de transferencia CORBA/IDL de alto nivel se limitan a la definición de dicha sintaxis de transferencia solo para una única instancia de lo que comparamos con una interfaz IDL (conjunto de objetos de información en términos ASN.1).

En otras palabras, dicha sintaxis de transferencia no es genérica ni reutilizable.

Con el conjunto actual de herramientas conocidas, no se puede definir una sintaxis de transferencia de este tipo de forma genérica en, por ejemplo, la especificación ASN.1 A y luego reutilizarla en las especificaciones ASN.1 B y C que definen "interfaces IDL" concretas específicas de la aplicación de las que A no depende.

La razón de la limitación actual es que actualmente codificamos de forma rígida nuestro conjunto de objetos de información ( MyWarehouseOpsen el caso de OPERATION, o MyErrorSeten el caso de ERROR) en nuestros tipos de datos ASN.1 (especificación de sintaxis de transferencia de alto nivel).

Ahora necesitamos dar un último paso para tener un sistema completo y totalmente funcional. Necesitamos introducir el concepto de parametrización de tipos utilizando el conjunto de objetos de información como parámetro formal de tipo.

Aquí presentamos nuestro Requesttipo reescrito teniendo en cuenta el concepto de parametrización:

Solicitud { OPERACIÓN : OpSet } ::= SECUENCIA { invokeId ENTERO ,opcode OPERATION . &operationCode ({ OpSet }),req-pars OPERACIÓN . &InvocationParsType ({ OpSet } { @ opcode }) }

Ahora, el descriptor de sintaxis de transferencia de alto nivel Requestpuede parametrizarse con cualquier conjunto de objetos de información arbitrario ("interfaz IDL") que cumpla con la especificación de la clase de objeto de información ("gramática IDL").

Por lo tanto, ahora podemos instanciarlo para cualquier conjunto de objetos de información de la siguiente manera:

Solicitud1 ::= Solicitud { MyWarehouseOps } Solicitud2 ::= Solicitud { MyOtherSetOfOps }-- etc.

La cláusula WITH SYNTAX es, en efecto, un pequeño lenguaje gramatical que se utiliza para expresar formas de definir sintácticamente los objetos de información.

Consideremos el siguiente ejemplo:

OPERACIÓN ::= CLASE { &opcode ENTERO ÚNICO , &InvocationParsType , &ResponseParsAndResultType , &ExceptionList ERROR OPCIONAL } CON SINTAXIS { OPCODE &opcode ARGUMENTOS DE SOLICITUD &InvocationParsType ARGUMENTOS DE RESPUESTA &ResponseParsAndResultType [ ERRORES &ExceptionList ] }

El encierro entre corchetes ([]) significa opcionalidad de las construcciones sintácticas contenidas en [].

La opcionalidad puede estar anidada.

Los tokens escritos en mayúsculas significan palabras clave, los tokens que comienzan con & significan producciones que requieren la sustitución de la entidad correspondiente en lugar del token (valor ASN.1, tipo o conjunto de objetos de información, ya sea una instancia o una referencia del mismo), dependiendo de la clase de objeto de información a la que se refiere este campo.

Ahora bien, lo que de otro modo habríamos escrito como:

getCustomersNum OPERACIÓN ::= { &operationCode get-customers-num-op-type-code ,&InvocationParsType Obtener-número-de-clientes-tipo-de-pars-de-solicitud ,&ResponseParsAndResultType Obtener-tipo-pars-ind-número-de-clientes ,&Lista de excepciones { producto incorrecto | departamento incorrecto } }

En presencia de la cláusula WITH SYNTAX, se puede reescribir de la siguiente manera:

getCustomersNum OPERACIÓN ::= { OPCODE get-customers-num-op-type-code ,ARGUMENTOS DE LA SOLICITUD Obtener-número-de-clientes-tipo-de-pars- de- solicitud ,ARGUMENTOS DE RESPUESTA Obtener-número-de-clientes-tipo-pars-ind ,-- según BNF en la cláusula WITH SYNTAX, se puede omitir la siguiente línea ERRORS { wrong-product | wrong-department } }

Para comprender completamente el concepto gramatical detrás de la cláusula WITH SYNTAX, imaginemos que escribimos la definición de nuestra clase de objeto de información OPERATION de la siguiente manera:

OPERACIÓN ::= CLASE { &opcode ENTERO ÚNICO , &InvocationParsType , &ResponseParsAndResultType , &ExceptionList ERROR OPCIONAL } CON SINTAXIS { &opcode &InvocationParsType &ResponseParsAndResultType [ &ExceptionList ] }

A continuación, se debe definir una instancia de objeto de información correspondiente a la definición anterior de la siguiente manera:

getCustomersNum OPERACIÓN ::= { get-customers-num-op-type-codeObtener-número-de-pars-de-solicitud-de-clientesObtener-tipo-de-pars-num-ind-clientes{ producto-incorrecto | departamento-incorrecto } }

• RECOMENDACIÓN X.681 DE LA UIT-T , Notación de Sintaxis Abstracta Uno (ASN.1): Especificación de objetos de información
• ASN.1 simplificado: temas avanzados de OSS Nokalva