วิกิพีเดียภาษาไทย
กลับไปหน้าบทความ

อ่าน 3 นาที

คลาสวัตถุข้อมูล (ASN.1)

ASN.1 Information Object Classเป็นแนวคิดที่ใช้กันอย่างแพร่หลายใน ข้อกำหนด ASN.1เพื่อแก้ไขปัญหาที่เกี่ยวข้องกับข้อกำหนดโปรโตคอล ซึ่งคล้ายกับปัญหาที่กล่าวถึงในข้อกำหนด CORBA/IDL

คลาสวัตถุข้อมูล (ASN.1)

( เรียนรู้วิธีและเวลาในการลบข้อความนี้ )

ASN.1 Information Object Classเป็นแนวคิดที่ใช้กันอย่างแพร่หลายใน ข้อกำหนด ASN.1เพื่อแก้ไขปัญหาที่เกี่ยวข้องกับข้อกำหนดโปรโตคอล ซึ่งคล้ายกับปัญหาที่กล่าวถึงในข้อกำหนด CORBA/IDL

ตัวอย่างเช่น คลาสของวัตถุข้อมูล (Information Object Classes) ใช้เพื่อระบุโปรโตคอล ROSE (Remote Operations Service Element) ใน ASN.1

คำย่อ

คำย่อที่ใช้ในบทความนี้:

ASN.1
สัญกรณ์ไวยากรณ์นามธรรมหนึ่ง
ไอโอซี
คลาสวัตถุข้อมูล
ระบบปฏิบัติการ iOS
ชุดวัตถุข้อมูล
ไอโอ
วัตถุข้อมูล
คำสั่ง SQL
ภาษาการสอบถามเชิงโครงสร้าง
ต่อ
กฎการเข้ารหัสแบบแพ็ค
เบอร์
กฎการเข้ารหัสพื้นฐาน
ไอดีแอล
ภาษานิยามอินเทอร์เฟซ
คอร์บา
สถาปัตยกรรมตัวกลางการร้องขอวัตถุทั่วไป
IIOP
โปรโตคอลอินเทอร์เน็ตอินเตอร์-ORB

การแนะนำ

วิธีคิดที่ง่ายที่สุดเกี่ยวกับคลาสวัตถุข้อมูล ASN.1 คือการมองว่าคลาสเหล่านั้นเป็นวิธีการแสดงข้อกำหนด IDL ใน ASN.1 โดยใช้แนวคิดที่ได้มาจากทฤษฎีฐานข้อมูลเชิงสัมพันธ์และไวยากรณ์ SQL โดยเฉพาะ

แนวคิดที่ใช้ใน ASN.1 มีความยืดหยุ่นมากกว่าแนวคิดที่ใช้ใน IDL เพราะหากเปรียบเทียบให้เหมือนกัน แนวคิดเหล่านี้อนุญาตให้ "ปรับแต่งไวยากรณ์" ของ "ข้อกำหนด IDL" ได้ กฎการเข้ารหัสของ ASN.1 ถูกใช้เป็นไวยากรณ์การถ่ายโอนสำหรับการเรียกใช้ระยะไกลที่คล้ายกับ CORBA/IIOP

จากข้อเปรียบเทียบนี้ เราสามารถสรุปความคล้ายคลึงกันโดยประมาณระหว่างแนวคิดที่ใช้ในคลาสของวัตถุสารสนเทศกับแนวคิดของ SQL และ IDL ดังแสดงในตารางที่ 1

ตารางที่ 1: ความคล้ายคลึงกันระหว่างแนวคิดในคลาสของวัตถุข้อมูล ASN.1, SQL และ IDL
เทอม ASN.1การเปรียบเทียบใน SQLการเปรียบเทียบใน IDL

คลาสวัตถุข้อมูล (IOC)

ตัวอธิบายโครงสร้างตาราง SQL ( คำสั่งCREATE TABLE )

ข้อกำหนดไวยากรณ์ IDL (กฎ BNF)

การประกาศภาคสนามของ IOC

ตัวระบุคอลัมน์ของตาราง SQL ใน คำสั่ง CREATE TABLE (ประเภทของคอลัมน์)

การผลิตไวยากรณ์ IDL

วัตถุข้อมูล (IO)

แถวในตาราง SQL ( คำสั่งINSERT INTO )

การประกาศการดำเนินการ IDL

คำจำกัดความฟิลด์ IO

ค่าในเซลล์ของแถวในตาราง SQL ใน คำสั่ง INSERT INTO (ค่าในเซลล์)

ส่วนหนึ่งของคำประกาศการทำงานของ IDL ซึ่งโดยทั่วไปเกี่ยวข้องกับการประกาศรหัสประเภทการทำงาน รายการพารามิเตอร์ ค่าส่งคืนของการทำงาน หรือรายการข้อยกเว้น

ชุดวัตถุข้อมูล (Information Object Set หรือ IOS) (ชุดของวัตถุข้อมูล)

ตาราง SQL ที่กำหนดไว้อย่างสมบูรณ์ (ชุดของแถว) (ดูหมายเหตุ 1)

คำจำกัดความอินเทอร์เฟซ IDL (ชุดของการดำเนินการ)

ประเภทข้อมูล ASN.1 ใช้การอ้างอิงถึงฟิลด์ IOC ที่กำหนดพารามิเตอร์ด้วย IOS (โดยทั่วไปคือชุดของประเภทที่เกี่ยวข้องกันทางความหมาย ซึ่งระบุคำขอ การตอบสนอง และข้อยกเว้น โดยทั้งหมดกำหนดพารามิเตอร์ด้วย IOS เดียวกัน)

ไม่มีข้อมูล

รูปแบบระดับสูง (ข้อกำหนดทางไวยากรณ์) ของเฟรม (บัฟเฟอร์การจัดเรียงข้อมูล) ที่บรรจุคำขอ การตอบสนอง หรือข้อยกเว้นของ CORBA

กฎการเข้ารหัส ASN.1 และไวยากรณ์การถ่ายโอน (BER, PER)

ไม่มีข้อมูล

การเข้ารหัสระดับต่ำของคำขอ การตอบสนอง และตัวบ่งชี้ข้อผิดพลาดที่เหมาะสมสำหรับการถ่ายโอนทางกายภาพผ่านสื่อกลาง

หมายเหตุ:การเปรียบเทียบระหว่าง IOS กับตาราง SQL นั้นไม่ถูกต้องนัก SQL อนุญาตให้มีตารางประเภทเดียวกันได้เพียงหนึ่งอินสแตนซ์เท่านั้น (OPERATION ในตัวอย่างด้านล่าง) ในขณะที่ ASN.1 อนุญาตให้มีชุดข้อมูลวัตถุหลายชุดที่ได้มาจากคลาสข้อมูลวัตถุเดียวกัน ซึ่งควรจะเปรียบเทียบกับอินสแตนซ์หลายรายการของตารางเดียวกันในแง่ของ SQL (OPERATION ในตัวอย่างด้านล่าง) มากกว่า

การเปรียบเทียบโดยใช้ตัวอย่าง

ตารางที่ 2 แสดงตัวอย่างความสอดคล้องกันของแนวคิด ASN.1 กับโครงสร้างที่คล้ายคลึงกันที่พบใน SQL และ IDL

ตารางที่ 2: ความคล้ายคลึงกันระหว่างแนวคิดใน ASN.1 คลาสของวัตถุข้อมูล SQL และ IDL พร้อมตัวอย่างประกอบ
เทอม ASN.1ตัวอย่าง ASN.1การเปรียบเทียบใน SQLการเปรียบเทียบใน IDL

ไอโอซี 

การดำเนินการ::= คลาส{ &operationCode จำนวนเต็มที่ไม่ซ้ำกัน,&InvocationParsType ,&ResponseParsAndResultType ,&ExceptionList ข้อผิดพลาด ( ไม่บังคับ) }
สร้างตารางOPERATION ( operationCode จำนวนเต็มไม่เป็นค่าว่าง ไม่ซ้ำ กัน,InvocationParsType type_info ไม่เป็นค่าว่างResponseParsAndResultType type_info ไม่เป็นค่าว่างExceptionList ref_to_table ( ERROR ) )

(ดูหมายเหตุ 1 ที่อธิบายtype_infoเพิ่มเติมref_to_table)

สิ่งนี้มีความคล้ายคลึงโดยประมาณกับส่วนหนึ่งของคำอธิบาย BNF เกี่ยวกับไวยากรณ์ pseudo-IDL ในรูปแบบต่อไปนี้ (โปรดทราบว่าในตัวอย่างต่อๆ ไป เราจะใช้ไวยากรณ์ IDL จริง แทนที่จะใช้ไวยากรณ์สมมติที่กำหนดโดย BNF ด้านล่าง): 

การดำเนินการ::= รหัสการดำเนินการประเภทการเรียกใช้ประเภทการตอบสนองและผลลัพธ์รายการข้อยกเว้นรหัสการทำงาน::= จำนวนเต็มInvocationParsType ::= TypeResponseParsAndResultType ::= ประเภทExceptionList ::= ข้อผิดพลาด

โดยที่Integerผลลัพธ์ของการผลิตจะแปลงเป็นค่าจำนวนเต็มTypeแปลงเป็นค่าอ้างอิงประเภท และExceptionListแปลงเป็นอินสแตนซ์ของชุดวัตถุสารสนเทศที่ได้มาจากERRORคลาสวัตถุสารสนเทศ (หรือรายการข้อยกเว้นในกรณีของ IDL)

ไอโอ 

getCustomersNum OPERATION ::= { &operationCode get-customers-num-op-type-code ,&InvocationParsType Get-customers-num-req-pars-type ,&ResponseParsAndResultType Get-customers-num-ind-pars-type ,&ExceptionList { สินค้าผิด| แผนกผิด} }
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 )

(โทเค็นที่ขึ้นต้นด้วย $ ถือเป็นตัวแปร (เช่น ใน PHP) และจะถูกแทนที่ด้วยค่าตัวแปรจริง) 

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

ระบบปฏิบัติการ iOS 

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

ตาราง SQL ถูกสร้างขึ้นโดยใช้ลำดับของคำสั่ง INSERT

อินเทอร์เฟซ IDL (ชุดของการดำเนินการ)

ประเภทข้อมูล ASN.1 

คำขอ::= ลำดับ{ invokeId INTEGER ,opcode OPERATION . &operationCode ({ MyWarehouseOps }),req-pars OPERATION . &InvocationParsType ({ MyWarehouseOps } { @ opcode }) }การตอบสนอง::= ลำดับ{ invokeId INTEGER ,opcode OPERATION . &operationCode ({ MyWarehouseOps }),rsp-pars OPERATION . &ResponseParsAndResultType ({ MyWarehouseOps } { @ opcode }) }ข้อยกเว้น::= ลำดับ{ รหัสข้อผิดพลาดERROR . &errorCode ({ MyErrorSet }),err-body ERROR . &ErrorBody ({ MyErrorSet } { @ err-code }) }

(ดูหมายเหตุ 2, 3)

ไม่มีข้อมูล

รูปแบบระดับสูงของเฟรมที่บรรจุคำขอ การตอบสนอง หรือข้อยกเว้นของ CORBA

BER, PER เป็นต้น

0110 0111 0010 110...

ไม่มีข้อมูล

การเข้ารหัสระดับต่ำของคำขอ การตอบสนอง และตัวบ่งชี้ข้อผิดพลาด

หมายเหตุ 1. ชนิดข้อมูล `and` type_infoและref_to_table`SQL` เป็นชนิดข้อมูลสมมุติ ไม่มีอยู่จริงใน SQL และถูกสร้างขึ้นมาเพื่อช่วยอธิบายแนวคิด ASN.1 ให้ดียิ่งขึ้น

ชนิดข้อมูล นี้type_infoหมายความว่าค่าของมันเป็นการอ้างอิงถึงชนิดข้อมูล ASN.1

ชนิดข้อมูล นี้ref_to_tableหมายความว่าค่าของมันเป็นการอ้างอิงถึงอินสแตนซ์อื่นของตาราง SQL (ในกรณีนี้คือตาราง ERROR) แม้ว่าเราจะรู้ว่าใน SQL จริงๆ แล้วเราไม่สามารถมีอินสแตนซ์ของตารางเดียวกันได้หลายตาราง แต่เพื่อความถูกต้องในการอธิบาย เราจะสมมติว่าเราสามารถทำได้

หมายเหตุ 2สัญลักษณ์ @ (เช่น@opcode) กำหนดความสัมพันธ์ระหว่างฟิลด์โดยอิงจากชุดออบเจ็กต์ข้อมูลที่ใช้ในการกำหนดพารามิเตอร์ของชนิดข้อมูลนั้นๆ ตัวอย่างเช่น@opcodeหมายความว่า ถ้าopcodeฟิลด์นั้นมีค่าบางอย่าง ฟิลด์ SEQUENCE อื่นๆ ที่ขึ้นอยู่กับฟิลด์นั้นจะต้องสอดคล้องกับค่าดังกล่าว ในแง่ของ SQL การรวมกันของชนิดและค่าที่ประกอบกันเป็นอินสแตนซ์ที่ถูกต้องของชนิดนั้น จะต้องอยู่ในแถวเดียวกันของตาราง opcodeopcode

หมายเหตุ 3.ข้อกำหนดตัวอย่างของประเภทข้อมูล ASN.1 ไม่ได้กำหนดความสัมพันธ์อย่างเป็นทางการระหว่างประเภทRequest, Response, และ แม้ว่าคลาสออบเจ็กต์ข้อมูล การดำเนินการที่ใช้ในทั้งสามประเภทจะกำหนดความสัมพันธ์ในระดับความหมายระหว่างคำขอ การตอบสนอง และเงื่อนไขข้อผิดพลาดที่เป็นไปได้ ในขณะที่คำจำกัดความการดำเนินการ IDL ทำเช่นนั้นอย่างเป็นทางการ Exception

ดังนั้น ข้อกำหนดตัวอย่างจึงไม่ได้บังคับใช้สถานการณ์ลำดับข้อความใดๆ อย่างเป็นทางการ แตกต่างจากคำจำกัดความการทำงานของ IDL ความสัมพันธ์ระหว่างเฟรมนั้นไม่ผูกมัดและเป็นเพียงความหมายเท่านั้น แม้ว่าเครื่องมือ ASN.1 จะสามารถใช้ประโยชน์จากความสัมพันธ์นี้ได้ในลักษณะเฉพาะของเครื่องมือนั้นๆ ก็ตาม

การกำหนดพารามิเตอร์

หากคุณพิจารณาตัวอย่าง ASN.1 ที่แสดงในตารางที่ 2 อย่างละเอียด และเปรียบเทียบกับแนวคิด IDL คุณจะเห็นข้อจำกัดที่สำคัญประการหนึ่งของ ASN.1

ตัวอย่างประเภทข้อมูล ASN.1 ของเรา ซึ่งเราตกลงที่จะนำมาเปรียบเทียบกับข้อกำหนดไวยากรณ์การถ่ายโอนระดับสูงของ CORBA/IDL นั้น ถูกจำกัดไว้เฉพาะการกำหนดไวยากรณ์การถ่ายโอนดังกล่าวสำหรับอินสแตนซ์เดียวของสิ่งที่เรานำมาเปรียบเทียบกับอินเทอร์เฟซ IDL (ชุดวัตถุข้อมูลในแง่ของ ASN.1) เท่านั้น

กล่าวอีกนัยหนึ่ง ไวยากรณ์การถ่ายโอนดังกล่าวไม่ใช่แบบทั่วไปและไม่สามารถนำกลับมาใช้ซ้ำได้

ด้วยชุดเครื่องมือที่มีอยู่ในปัจจุบัน คุณไม่สามารถกำหนดไวยากรณ์การถ่ายโอนดังกล่าวในลักษณะทั่วไปได้ในข้อกำหนด ASN.1 ข้อ A แล้วนำไปใช้ซ้ำในข้อกำหนด ASN.1 ข้อ B และข้อ C ซึ่งกำหนด "อินเทอร์เฟซ IDL" เฉพาะแอปพลิเคชันที่ A ไม่ได้ขึ้นอยู่ด้วย

สาเหตุของข้อจำกัดในปัจจุบันคือ เราได้กำหนดชุดวัตถุข้อมูล ( MyWarehouseOpsในกรณีของOPERATIONหรือMyErrorSetในกรณีของERROR) ลงในประเภทข้อมูล ASN.1 (ข้อกำหนดไวยากรณ์การถ่ายโอนระดับสูง) แบบ ตายตัวไว้แล้ว

ตอนนี้เราต้องทำขั้นตอนสุดท้ายเพื่อให้ระบบสมบูรณ์และใช้งานได้อย่างเต็มที่ เราต้องนำแนวคิดเรื่องการกำหนดพารามิเตอร์ประเภทมาใช้ โดยใช้ชุดวัตถุข้อมูล (Information Object Set) เป็นพารามิเตอร์รูปแบบประเภท

นี่คือRequestรูปแบบที่เราเขียนใหม่โดยคำนึงถึงแนวคิดเรื่องการกำหนดพารามิเตอร์: 

คำขอ{ การดำเนินการ: OpSet } ::= ลำดับ{ invokeId INTEGER ,opcode OPERATION . &operationCode ({ OpSet }),req-pars OPERATION . &InvocationParsType ({ OpSet } { @ opcode }) }

ขณะนี้ ตัวอธิบายไวยากรณ์การถ่ายโอนระดับสูงRequestสามารถกำหนดพารามิเตอร์ได้ด้วยชุดวัตถุข้อมูลใดๆ ("อินเทอร์เฟซ IDL") ที่สอดคล้องกับข้อกำหนดคลาสวัตถุข้อมูล ("ไวยากรณ์ IDL")

ดังนั้น เราจึงสามารถสร้างอินสแตนซ์สำหรับชุดวัตถุข้อมูลใดๆ ได้ดังต่อไปนี้: 

คำขอ 1 ::= คำขอ{ MyWarehouseOps } คำขอ 2 ::= คำขอ{ MyOtherSetOfOps }-- เป็นต้น

เงื่อนไข WITH SYNTAX

คำสั่ง WITH SYNTAX นั้นเปรียบเสมือนภาษาไวยากรณ์ขนาดเล็กที่ใช้ในการแสดงวิธีการกำหนดความหมายเชิงไวยากรณ์ของวัตถุข้อมูล

พิจารณาตัวอย่างต่อไปนี้: 

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

วงเล็บเหลี่ยม ([]) แสดงถึงความเป็นไปได้ในการใช้โครงสร้างทางไวยากรณ์ที่อยู่ใน []

ตัวเลือกเสริมสามารถซ้อนกันได้

โทเค็นที่เขียนด้วยตัวพิมพ์ใหญ่ทั้งหมดหมายถึงคำหลัก โทเค็นที่ขึ้นต้นด้วย & หมายถึงการสร้างที่ต้องแทนที่ด้วยเอนทิตีที่เกี่ยวข้องในตำแหน่งของโทเค็น (ค่า ASN.1 ประเภท หรือชุดวัตถุข้อมูล ไม่ว่าจะเป็นอินสแตนซ์หรือการอ้างอิง) ขึ้นอยู่กับคลาสวัตถุข้อมูลที่ฟิลด์นี้อ้างถึง

แล้วถ้าไม่เป็นเช่นนั้น เราคงเขียนไว้แบบนี้: 

getCustomersNum OPERATION ::= { &operationCode get-customers-num-op-type-code ,&InvocationParsType Get-customers-num-req-pars-type ,&ResponseParsAndResultType Get-customers-num-ind-pars-type ,&ExceptionList { สินค้าผิด| แผนกผิด} }

ในกรณีที่มีคำสั่ง WITH SYNTAX สามารถเขียนใหม่ได้ดังนี้: 

การดำเนินการgetCustomersNum ::= { OPCODE get-customers-num-op-type-code ,อาร์กิวเมนต์คำขอGet-customers-num-req-pars-type ,อาร์กิวเมนต์การตอบกลับGet-customers-num-ind-pars-type ,-- ตามหลักการของ BNF ในส่วน WITH SYNTAX บรรทัดต่อไปนี้สามารถละเว้นได้ERRORS { wrong-product | wrong-department } }

เพื่อให้เข้าใจแนวคิดทางไวยากรณ์เบื้องหลังคำสั่ง WITH SYNTAX อย่างถ่องแท้ ลองนึกภาพว่าเราเขียนคำจำกัดความของคลาส OPERATION Information Object ดังนี้: 

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

จากนั้น จะต้องกำหนดอินสแตนซ์ของ Information Object ที่สอดคล้องกับคำจำกัดความข้างต้น ดังนี้: 

getCustomersNum OPERATION ::= { get-customers-num-op-type-codeรับจำนวนลูกค้า-ประเภทคำขอ-พาร์สรับหมายเลขลูกค้า-ประเภทข้อมูลย่อย{ สินค้าผิด| แผนกผิด} }
  • ข้อแนะนำ ITU-T X.681สัญกรณ์ไวยากรณ์นามธรรมแบบที่หนึ่ง (ASN.1): ข้อกำหนดของวัตถุข้อมูล
  • ASN.1 ฉบับเข้าใจง่าย — หัวข้อขั้นสูงจาก OSS Nokalva
ดึงข้อมูลมาจาก " https://en.wikipedia.org/w/index.php?title=Information_Object_Class_(ASN.1)&oldid=1309160016 "

สรุปเนื้อหา

ข้อมูลสำคัญจากบทความ

ข้อมูลสำคัญเกี่ยวกับ คลาสวัตถุข้อมูล (ASN.1)

ASN.1 Information Object Classเป็นแนวคิดที่ใช้กันอย่างแพร่หลายใน ข้อกำหนด ASN.1เพื่อแก้ไขปัญหาที่เกี่ยวข้องกับข้อกำหนดโปรโตคอล ซึ่งคล้ายกับปัญหาที่กล่าวถึงในข้อกำหนด CORBA/IDL

การแนะนำ

วิธีคิดที่ง่ายที่สุดเกี่ยวกับคลาสวัตถุข้อมูล ASN.1 คือการมองว่าคลาสเหล่านั้นเป็นวิธีการแสดงข้อกำหนด IDL ใน ASN.1 โดยใช้แนวคิดที่ได้มาจากทฤษฎีฐานข้อมูลเชิงสัมพันธ์และไวยากรณ์ SQL โดยเฉพาะ

การเปรียบเทียบโดยใช้ตัวอย่าง

ตารางที่ 2 แสดงตัวอย่างความสอดคล้องกันของแนวคิด ASN.1 กับโครงสร้างที่คล้ายคลึงกันที่พบใน SQL และ IDL

การกำหนดพารามิเตอร์

หากคุณพิจารณาตัวอย่าง ASN.1 ที่แสดงในตารางที่ 2 อย่างละเอียด และเปรียบเทียบกับแนวคิด IDL คุณจะเห็นข้อจำกัดที่สำคัญประการหนึ่งของ ASN.1