สถาปัตยกรรมนายหน้าขอวัตถุทั่วไป

จากวิกิพีเดีย สารานุกรมเสรี
ข้ามไปที่การนำทาง ข้ามไปที่การค้นหา

สถาปัตยกรรมนายหน้าขอวัตถุทั่วไป
ตัวย่อคอร์บา
สถานะที่ตีพิมพ์
ปีที่เริ่มต้น1991 ; 31 ปีที่แล้ว ( 1991 )
รุ่นล่าสุด3.4
กุมภาพันธ์ 2564 ; 1 ปีที่แล้ว ( 2021-02 )
องค์กรกลุ่มการจัดการวัตถุ
เว็บไซต์corba .org

สถาปัตยกรรม Common Object Request Broker Architecture ( CORBA ) เป็นมาตรฐานที่กำหนดโดยObject Management Group (OMG) ที่ออกแบบมาเพื่ออำนวยความสะดวกในการสื่อสารของระบบที่ปรับใช้บนแพลตฟอร์มที่หลากหลาย CORBA ช่วยให้เกิดการทำงานร่วมกันระหว่างระบบบนระบบปฏิบัติการภาษาโปรแกรมและฮาร์ดแวร์คอมพิวเตอร์ CORBA ใช้โมเดลเชิงวัตถุ แม้ว่าระบบที่ใช้ CORBA จะไม่จำเป็นต้องเป็นแบบเชิงวัตถุ CORBA เป็นตัวอย่างของกระบวนทัศน์ วัตถุแบบกระจาย

ภาพรวม

CORBA ช่วยให้สามารถสื่อสารระหว่างซอฟต์แวร์ที่เขียนด้วยภาษาต่างๆ และทำงานบนคอมพิวเตอร์หลายเครื่องได้ รายละเอียดการใช้งานจากระบบปฏิบัติการ ภาษาโปรแกรม และแพลตฟอร์มฮาร์ดแวร์ ทั้งหมดจะถูกลบออกจากความรับผิดชอบของนักพัฒนาที่ใช้ CORBA CORBA ทำให้ความหมายของการเรียกเมธอดเป็นมาตรฐานระหว่างออบเจ็กต์ของแอปพลิเคชันที่อยู่ในพื้นที่ที่อยู่เดียวกัน (แอปพลิเคชัน) หรือในช่องว่างที่อยู่ระยะไกล (โฮสต์เดียวกัน หรือโฮสต์ระยะไกลบนเครือข่าย) เวอร์ชัน 1.0 เปิดตัวในเดือนตุลาคม 1991

CORBA ใช้ภาษานิยามอินเทอร์เฟซ (IDL) เพื่อระบุอินเทอร์เฟซที่วัตถุปรากฏต่อโลกภายนอก จากนั้น CORBA จะระบุการแมปจาก IDL กับภาษาการใช้งานเฉพาะ เช่นC ++หรือJava มีการแมปมาตรฐานสำหรับAda , C , C++ , C++11 , COBOL , Java , Lisp , PL/I , Object Pascal , Python , RubyและSmalltalk มีการแมปที่ไม่ได้มาตรฐานสำหรับC# , Erlang ,Perl , TclและVisual Basicใช้งานโดยโบรกเกอร์คำขอวัตถุ (ORB) ที่เขียนขึ้นสำหรับภาษาเหล่านั้น

ข้อกำหนดของ CORBA กำหนดให้ต้องมี ORB ซึ่งแอปพลิเคชันจะโต้ตอบกับวัตถุอื่นๆ นี่คือวิธีการดำเนินการในทางปฏิบัติ:

  1. แอปพลิเคชันเริ่มต้น ORB และเข้าถึงObject Adapter ภายใน ซึ่งดูแลสิ่งต่าง ๆ เช่นการนับการอ้างอิง นโยบายการสร้างอินสแตนซ์ของอ็อบเจ็กต์ (และการอ้างอิง) และนโยบายอายุการใช้งานของอ็อบเจ็กต์
  2. Object Adapter ใช้เพื่อลงทะเบียนอินสแตนซ์ของคลาสโค้ดที่สร้างขึ้น คลาสรหัสที่สร้างเป็นผลจากการรวบรวมรหัส IDL ของผู้ใช้ ซึ่งแปลคำจำกัดความของอินเทอร์เฟซระดับสูงเป็นคลาสพื้นฐานเฉพาะของ OS และภาษาสำหรับใช้งานโดยแอปพลิเคชันผู้ใช้ ขั้นตอนนี้จำเป็นเพื่อบังคับใช้ CORBA semantics และจัดเตรียมกระบวนการผู้ใช้ที่สะอาดสำหรับการเชื่อมต่อกับโครงสร้างพื้นฐาน CORBA

การแมป IDL บางอย่างยากต่อการใช้งานมากกว่าแบบอื่นๆ ตัวอย่างเช่น เนื่องจากธรรมชาติของ Java การแมป IDL-Java ค่อนข้างตรงไปตรงมา และทำให้การใช้งาน CORBA ง่ายมากในแอปพลิเคชัน Java สิ่งนี้เป็นจริงของการจับคู่ IDL กับ Python การแมป C++ ต้องการให้โปรแกรมเมอร์เรียนรู้ประเภทข้อมูลที่มาก่อน C++ Standard Template Library (STL) ในทางตรงกันข้าม การแมป C++11 นั้นใช้งานง่ายกว่า แต่ต้องใช้ STL อย่างหนัก เนื่องจากภาษา C ไม่ใช่เชิงวัตถุ การแมป IDL กับ C จึงต้องการโปรแกรมเมอร์ C เพื่อจำลองคุณลักษณะเชิงวัตถุด้วยตนเอง

ในการสร้างระบบที่ใช้หรือใช้อินเทอร์เฟซวัตถุแบบกระจายตาม CORBA นักพัฒนาต้องขอรับหรือเขียนโค้ด IDL ที่กำหนดอินเทอร์เฟซเชิงวัตถุกับตรรกะที่ระบบจะใช้หรือนำไปใช้ โดยทั่วไป การใช้งาน ORB จะมีเครื่องมือที่เรียกว่าคอมไพเลอร์ IDL ซึ่งแปลอินเทอร์เฟซ IDL เป็นภาษาเป้าหมายเพื่อใช้ในส่วนนั้นของระบบ คอมไพเลอร์แบบเดิมจะคอมไพล์โค้ดที่สร้างขึ้นเพื่อสร้างไฟล์ที่เชื่อมโยงได้สำหรับใช้ในแอปพลิเคชัน ไดอะแกรมนี้แสดงวิธีการใช้โค้ดที่สร้างขึ้นภายในโครงสร้างพื้นฐาน CORBA:

ภาพประกอบของการสร้างรหัสโครงสร้างพื้นฐานอัตโนมัติจากอินเทอร์เฟซที่กำหนดโดยใช้ CORBA IDL

รูปนี้แสดงกระบวนทัศน์ระดับสูงสำหรับการสื่อสารระหว่างกระบวนการระยะไกลโดยใช้ CORBA ข้อมูลจำเพาะของ CORBA ยังระบุถึงการพิมพ์ข้อมูล ข้อยกเว้น โปรโตคอลเครือข่าย การหมดเวลาของการสื่อสาร ฯลฯ ตัวอย่างเช่น: โดยปกติฝั่งเซิร์ฟเวอร์จะมีPortable Object Adapter (POA) ที่เปลี่ยนเส้นทางการเรียกไปยังผู้รับใช้ ในพื้นที่ หรือ (เพื่อปรับสมดุลโหลด) ไปยัง เซิร์ฟเวอร์อื่นๆ ข้อมูลจำเพาะของ CORBA (และด้วยเหตุนี้ตัวเลขนี้) ปล่อยให้แง่มุมต่างๆ ของระบบแบบกระจายไปยังแอปพลิเคชันเพื่อกำหนดรวมถึงอายุการใช้งานของวัตถุ (แม้ว่าความหมายการนับอ้างอิงจะพร้อมใช้งานสำหรับแอปพลิเคชัน) ความซ้ำซ้อน/ความล้มเหลว การจัดการหน่วยความจำ การจัดสรรภาระงานแบบไดนามิก และแอปพลิเคชัน- ตัวแบบเชิงเดี่ยว เช่น การแยกระหว่างการแสดงความหมาย/ข้อมูล/การควบคุม (เช่น seeModel–view–controller ) เป็นต้น

นอกเหนือจากการให้บริการผู้ใช้ด้วยภาษาและ ข้อกำหนด การเรียกโพรซีเดอร์ระยะไกล ที่เป็นกลางบนแพลตฟอร์ม (RPC) แล้ว CORBA ยังกำหนดบริการที่จำเป็นโดยทั่วไป เช่น ธุรกรรมและความปลอดภัย เหตุการณ์ เวลา และโมเดลอินเทอร์เฟซเฉพาะโดเมนอื่นๆ

ประวัติรุ่น

ตารางนี้แสดงประวัติของเวอร์ชันมาตรฐาน CORBA [1] [2]

เวอร์ชั่น วันที่ของเวอร์ชัน ไฮไลท์
1.0 ตุลาคม 1991 รุ่นแรก การทำแผนที่ C
1.1 กุมภาพันธ์ 1992 การทำงานร่วมกัน, การทำแผนที่ C++
1.2 ธันวาคม 2536 -
2.0 สิงหาคม 2539 การปรับปรุงครั้งใหญ่ครั้งแรกของมาตรฐาน เรียกอีกอย่างว่าCORBA 2
2.1 สิงหาคม 1997 -
2.2 กุมภาพันธ์ 1998 การทำแผนที่ Java
2.3 มิถุนายน 2542 -
2.4 สิงหาคม 2000 -
2.5 กันยายน 2544 -
2.6 ธันวาคม 2544 -
3.0 กรกฎาคม 2002 การปรับปรุงหลักครั้งที่สองของมาตรฐาน หรือที่เรียกว่าCORBA 3
CORBA Component Model (CCM)
3.0.1 พฤศจิกายน 2545 -
3.0.2 ธันวาคม 2545 -
3.0.3 มีนาคม 2547 -
3.1 มกราคม 2551 -
3.1.1 สิงหาคม 2011 ได้รับการรับรอง ISO/IEC 19500 . ฉบับปี 2555
3.2 พฤศจิกายน 2011 -
3.3 พฤศจิกายน 2555 การเพิ่ม ZIOP
3.4 กุมภาพันธ์ 2564

ผู้รับใช้

คนใช้คือเป้าหมายการเรียกใช้ที่มีเมธอดสำหรับการจัดการการเรียกใช้เมธอดระยะไกล ในเวอร์ชัน CORBA ที่ใหม่กว่า รีโมตอ็อบเจ็กต์ (บนฝั่งเซิร์ฟเวอร์) จะถูกแบ่งออกเป็นอ็อบเจ็กต์ (ที่เปิดเผยต่อการเรียกใช้ระยะไกล)และคนใช้ (ซึ่งส่วนเดิมส่งต่อการเรียกใช้เมธอด ) อาจเป็นผู้รับใช้หนึ่งคนต่อวัตถุ ระยะไกล หรือคนใช้คนเดียวกันสามารถรองรับวัตถุหลายชิ้น (อาจทั้งหมด) ที่เกี่ยวข้องกับPortable Object Adapter ที่ ให้มา ผู้รับใช้ของแต่ละวัตถุสามารถตั้งค่าหรือพบ "ครั้งเดียวและตลอดไป" (การเปิดใช้งานผู้รับใช้) หรือเลือกแบบไดนามิกทุกครั้งที่มีการเรียกใช้เมธอดบนวัตถุนั้น (ตำแหน่งผู้รับใช้) ทั้งตัวระบุตำแหน่งผู้รับใช้และตัวเปิดใช้งานผู้รับใช้สามารถส่งต่อการเรียกไปยังเซิร์ฟเวอร์อื่นได้ โดยรวมแล้ว ระบบนี้เป็นวิธีที่มีประสิทธิภาพมากในการปรับสมดุลของโหลด โดยกระจายคำขอระหว่างเครื่องหลายเครื่อง ในภาษาเชิงวัตถุ ทั้งวัตถุ ระยะไกล และคนใช้เป็นวัตถุจากมุมมองของการเขียนโปรแกรมเชิงวัตถุ

การกลับ ชาติมาเกิดคือการเชื่อมโยงคนใช้กับวัตถุ CORBA เพื่อให้บริการตามคำขอ การกลับชาติมาเกิดมีรูปแบบผู้รับใช้ที่เป็นรูปธรรมสำหรับวัตถุ CORBA เสมือน การเปิดใช้งานและการปิดใช้งานหมายถึงวัตถุ CORBA เท่านั้น ในขณะที่เงื่อนไขการกลับชาติมาเกิดและการทำให้ไม่มีตัวตนหมายถึงผู้รับใช้ อย่างไรก็ตามอายุการใช้งานของวัตถุและคนใช้นั้นไม่ขึ้นกับ คุณสร้างคนรับใช้ก่อนที่จะเรียก activate_object() เสมอ แต่ในทางกลับกันก็เป็นไปได้ create_reference() จะเปิดใช้งานวัตถุโดยไม่ต้องจุติคนใช้ และการกลับชาติมาเกิดของบ่าวจะทำได้ตามความต้องการด้วย Servant Manager

ดิPortable Object Adapter (POA) เป็นวัตถุ CORBA ที่รับผิดชอบการแยกตัวจัดการการเรียกใช้ระยะไกลฝั่งเซิร์ฟเวอร์ออกเป็นวัตถุและคนใช้ วัตถุถูกเปิดเผยสำหรับการเรียกใช้ระยะไกลในขณะที่คนใช้มีวิธีการที่จัดการคำขอจริง ๆ ผู้รับใช้สำหรับแต่ละอ็อบเจ็กต์สามารถเลือกได้ทั้งแบบสแตติก (ครั้งเดียว) หรือไดนามิก (สำหรับการเรียกใช้ระยะไกลแต่ละครั้ง) ในทั้งสองกรณี อนุญาตให้ส่งต่อการโทรไปยังเซิร์ฟเวอร์อื่น

ทางฝั่งเซิร์ฟเวอร์ POA จะสร้างโครงสร้างเหมือนต้นไม้ โดยที่ POA แต่ละส่วนมีหน้าที่รับผิดชอบสำหรับวัตถุหนึ่งรายการขึ้นไปที่จะถูกเสิร์ฟ กิ่งก้านของทรีนี้สามารถเปิดใช้งาน/ปิดใช้งานได้อย่างอิสระ มีรหัสที่แตกต่างกันสำหรับตำแหน่งผู้รับใช้หรือการเปิดใช้งาน และนโยบายการจัดการคำขอที่แตกต่างกัน

คุณสมบัติ

ต่อไปนี้จะอธิบายวิธีที่สำคัญที่สุดบางประการที่ CORBA สามารถใช้เพื่ออำนวยความสะดวกในการสื่อสารระหว่างอ็อบเจ็กต์แบบกระจาย

วัตถุตามการอ้างอิง

การอ้างอิงนี้ได้มาโดยผ่านUniform Resource Locator (URL), การค้นหา NameService (คล้ายกับDomain Name System (DNS)) หรือส่งผ่านเป็นพารามิเตอร์เมธอดในระหว่างการโทร

การอ้างอิงอ็อบเจ็กต์เป็นอ็อบเจ็กต์น้ำหนักเบาที่ตรงกับอินเทอร์เฟซของอ็อบเจ็กต์จริง (ระยะไกลหรือในเครื่อง) การเรียกเมธอดในการอ้างอิงส่งผลให้เกิดการเรียกต่อมาไปยัง ORB และการบล็อกเธรดขณะรอการตอบกลับ สำเร็จหรือล้มเหลว พารามิเตอร์ ข้อมูลที่ส่งคืน (ถ้ามี) และข้อมูลข้อยกเว้นจะถูกจัดระเบียบภายในโดย ORB ตามภาษาท้องถิ่นและการแมป OS

ข้อมูลตามมูลค่า

CORBA Interface Definition Language ให้คำจำกัดความการสื่อสารระหว่างออบเจ็กต์ภาษาและ OS-neutral วัตถุ CORBA ถูกส่งผ่านโดยการอ้างอิง ในขณะที่ข้อมูล (จำนวนเต็ม คู่ โครงสร้าง enums ฯลฯ) ถูกส่งผ่านด้วยค่า การรวมกันของ Objects-by-reference และ data-by-value ทำให้เกิดวิธีการบังคับใช้การพิมพ์ข้อมูลที่ยอดเยี่ยมในขณะรวบรวมไคลเอ็นต์และเซิร์ฟเวอร์ แต่ยังคงความยืดหยุ่นที่มีอยู่ในพื้นที่ปัญหาของ CORBA

วัตถุตามค่า (OBV)

นอกเหนือจากวัตถุระยะไกล CORBA และRMI-IIOPยังกำหนดแนวคิดของ OBV และประเภทค่า รหัสภายในเมธอดของอ็อบเจกต์ Valuetype จะถูกเรียกใช้งานในเครื่องโดยค่าเริ่มต้น หากได้รับ OBV จากฝั่งระยะไกลแล้ว โค้ดที่จำเป็นจะต้องเป็นระดับความสำคัญที่ทราบทั้งสองด้านหรือดาวน์โหลดแบบไดนามิกจากผู้ส่ง เพื่อให้เป็นไปได้ เร็กคอร์ดที่กำหนด OBV มี Code Base ซึ่งเป็นรายการURL ที่คั่นด้วยช่องว่าง ซึ่งควรดาวน์โหลดโค้ดนี้ OBV สามารถมีวิธีระยะไกลได้เช่นกัน

CORBA Component Model (CCM)

CORBA Component Model (CCM) เป็นส่วนเพิ่มเติมในตระกูลคำจำกัดความของ CORBA [3]นำมาใช้กับ CORBA 3 และอธิบายกรอบงานแอปพลิเคชันมาตรฐานสำหรับส่วนประกอบ CORBA แม้ว่าจะไม่ได้ขึ้นอยู่กับ "ภาษาที่ขึ้นอยู่กับEnterprise Java Beans (EJB)" แต่ก็เป็นรูปแบบทั่วไปของ EJB โดยให้องค์ประกอบสี่ประเภทแทนที่จะเป็นสองประเภทที่ EJB กำหนด นำเสนอสิ่งที่เป็นนามธรรมของเอนทิตีที่สามารถให้บริการและรับบริการผ่านอินเทอร์เฟซที่มีชื่อที่กำหนดไว้อย่างดีซึ่งเรียกว่า พอร์ต

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

เครื่องสกัดกั้นแบบพกพา

เครื่องสกัดกั้นแบบพกพาคือ "ตะขอ" ที่ใช้โดย CORBA และRMI-IIOPเพื่อทำหน้าที่เป็นสื่อกลางในการทำงานที่สำคัญที่สุดของระบบ CORBA มาตรฐาน CORBA กำหนดประเภทของเครื่องสกัดกั้นต่อไปนี้:

  1. ตัวสกัดกั้น IORเป็นสื่อกลางในการสร้างการอ้างอิงใหม่ไปยังวัตถุระยะไกล นำเสนอโดยเซิร์ฟเวอร์ปัจจุบัน
  2. ตัวดักจับไคลเอ็นต์มักจะเป็นสื่อกลางในการเรียกเมธอดระยะไกลที่ฝั่งไคลเอ็นต์ (ผู้โทร) ถ้าวัตถุServantอยู่บนเซิร์ฟเวอร์เดียวกันกับที่มีการเรียกใช้เมธอด พวกเขายังเป็นสื่อกลางในการเรียกภายในเครื่องด้วย
  3. ตัวสกัดกั้นเซิร์ฟเวอร์เป็นสื่อกลางในการจัดการการเรียกใช้เมธอดระยะไกลบนฝั่งเซิร์ฟเวอร์ (ตัวจัดการ)

ผู้สกัดกั้นสามารถแนบข้อมูลเฉพาะกับข้อความที่ส่งและ IOR ที่ถูกสร้างขึ้น ข้อมูลนี้สามารถอ่านได้ในภายหลังโดยเครื่องสกัดกั้นที่เกี่ยวข้องบนฝั่งระยะไกล ผู้สกัดกั้นยังสามารถส่งข้อยกเว้นการส่งต่อ เปลี่ยนเส้นทางคำขอไปยังเป้าหมายอื่น

โปรโตคอล InterORB ทั่วไป (GIOP)

GIOPเป็นโปรโตคอลนามธรรมโดยที่Object Request Brokers (ORB) สื่อสารกัน มาตรฐานที่เกี่ยวข้องกับโปรโตคอลได้รับการดูแลโดยObject Management Group (OMG) สถาปัตยกรรม GIOP มีโปรโตคอลที่เป็นรูปธรรมหลายประการ ได้แก่ :

  1. Internet InterORB Protocol (IIOP) – Internet Inter-Orb Protocol เป็นการนำ GIOP ไปใช้บนอินเทอร์เน็ตและจัดให้มีการแมประหว่างข้อความ GIOP และเลเยอร์TCP/IP
  2. SSL InterORB Protocol (SSLIOP) – SSLIOP คือ IIOP ผ่านSSLให้การเข้ารหัสและรับรองความถูกต้อง
  3. HyperText InterORB Protocol (HTIOP) – HTIOP คือ IIOP ผ่านHTTPซึ่งให้การบายพาสพร็อกซีที่โปร่งใส
  4. Zipped IOP (ZIOP) – GIOP เวอร์ชันซิปที่ลดการใช้แบนด์วิดท์

VMCID (Vendor Minor Codeset ID)

ข้อยกเว้น CORBA มาตรฐานแต่ละรายการมีโค้ดรองเพื่อกำหนดหมวดหมู่ย่อยของข้อยกเว้น รหัสข้อยกเว้นรองเป็นประเภท unsigned long และประกอบด้วย "Vendor Minor Codeset ID" 20 บิต (VMCID) ซึ่งใช้ลำดับสูง 20 บิต และรหัสรองที่เหมาะสมซึ่งมีลำดับต่ำ 12 บิต

รหัสรองสำหรับข้อยกเว้นมาตรฐานนำหน้าโดย VMCID ที่กำหนดให้กับ OMG ซึ่งกำหนดเป็นค่าคงที่แบบยาวที่ไม่ได้ลงนาม CORBA::OMGVMCID ซึ่งมี VMCID ที่จัดสรรให้กับ OMG ที่มีลำดับสูง 20 บิต รหัสข้อยกเว้นเล็กน้อยที่เกี่ยวข้องกับข้อยกเว้นมาตรฐานที่พบในตาราง 3–13 ในหน้า 3-58 นั้นหรือแก้ไขด้วย OMGVMCID เพื่อรับค่ารหัสรองที่ส่งคืนในโครงสร้าง ex_body (ดูหัวข้อ 3.17.1 "มาตรฐาน" คำจำกัดความของข้อยกเว้น" ในหน้า 3-52 และส่วนที่ 3.17.2 "รหัสข้อยกเว้นรองมาตรฐาน" ในหน้า 3-58)

ภายในพื้นที่ที่กำหนดโดยผู้ขาย การกำหนดค่าให้กับรหัสรองจะเหลือให้กับผู้ขาย ผู้จำหน่ายอาจขอจัดสรร VMCID โดยส่งอีเมลไปที่ [email protected] สามารถดูรายการ VMCID ที่ได้รับมอบหมายในปัจจุบันได้จากเว็บไซต์ OMG ที่: http://www.omg.org/cgi-bin/doc?vendor-tags

VMCID 0 และ 0xfffff สงวนไว้สำหรับการใช้งานในการทดลอง VMCID OMGVMCID (ส่วนที่ 3.17.1 "ข้อกำหนดข้อยกเว้นมาตรฐาน" ในหน้า 3-52) และ 1 ถึง 0xf สงวนไว้สำหรับการใช้งาน OMG

นายหน้าขอวัตถุทั่วไป: สถาปัตยกรรมและข้อกำหนด (CORBA 2.3)

ที่ตั้ง Corba (CorbaLoc)

ตำแหน่ง Corba (CorbaLoc) หมายถึงการอ้างอิงวัตถุแบบสตริงสำหรับวัตถุ CORBA ที่มีลักษณะคล้ายกับ URL

ผลิตภัณฑ์ CORBA ทั้งหมดต้องสนับสนุน URL ที่กำหนดโดย OMG สองรายการ: " corbaloc: " และ " corbaname: " จุดประสงค์ของสิ่งเหล่านี้คือเพื่อให้มนุษย์สามารถอ่านและแก้ไขได้ เพื่อระบุตำแหน่งที่สามารถรับ IOR ได้

ตัวอย่างของ corbaloc แสดงด้านล่าง:

corbaloc::160.45.110.41:38693/StandardNS/NameServer-POA/_root

ผลิตภัณฑ์ CORBA อาจสนับสนุนรูปแบบ " http: ", " ftp: " และ " file: " หรือไม่ก็ได้ ความหมายของสิ่งเหล่านี้คือการให้รายละเอียดเกี่ยวกับวิธีการดาวน์โหลด IOR แบบสตริง (หรือเรียกซ้ำดาวน์โหลด URL อื่นที่จะให้ IOR แบบสตริงในท้ายที่สุด) ORB บางตัวมีรูปแบบเพิ่มเติมซึ่งเป็นกรรมสิทธิ์ของ ORB นั้น

ประโยชน์ที่ได้รับ

ประโยชน์ของ CORBA ได้แก่ ความเป็นอิสระของภาษาและ OS, อิสระจากการใช้งานที่เชื่อมโยงกับเทคโนโลยี, การพิมพ์ข้อมูลที่แข็งแกร่ง, ความสามารถในการปรับแต่งในระดับสูง และความเป็นอิสระจากรายละเอียดของการถ่ายโอนข้อมูลแบบกระจาย

ความเป็นอิสระของภาษา
CORBA ได้รับการออกแบบมาเพื่อให้วิศวกรอิสระจากข้อจำกัดของการผสมผสานการออกแบบกับภาษาซอฟต์แวร์เฉพาะ ปัจจุบันมีผู้ให้บริการ CORBA หลายรายรองรับหลายภาษา โดยภาษาที่ได้รับความนิยมมากที่สุดคือ Java และ C++ นอกจากนี้ยังมีการใช้งาน C++11, C-only, Smalltalk, Perl, Ada, Ruby และ Python อีกด้วย
OS-ความเป็นอิสระ
การออกแบบของ CORBA นั้นไม่ขึ้นกับระบบปฏิบัติการ CORBA พร้อมใช้งานใน Java (ไม่ขึ้นกับระบบปฏิบัติการ) เช่นเดียวกับ Linux/Unix, Windows, Solaris, OS X, OpenVMS, HPUX, Android, LynxOS, VxWorks, ThreadX, INTEGRITY และอื่นๆ
อิสระจากเทคโนโลยี
ประโยชน์หลักประการหนึ่งโดยนัยคือ CORBA ให้สนามเด็กเล่นที่เป็นกลางสำหรับวิศวกร เพื่อทำให้อินเทอร์เฟซระหว่างระบบใหม่และระบบเดิมต่างๆ เป็นปกติ เมื่อรวม C, C++, Object Pascal, Java, Fortran, Python และภาษาหรือ OS อื่นๆ เข้าไว้ในโมเดลการออกแบบระบบเดียวที่เชื่อมโยงกัน CORBA มีวิธีในการปรับระดับฟิลด์และอนุญาตให้ทีมที่แตกต่างกันพัฒนาระบบและการทดสอบหน่วยที่สามารถทำได้ในภายหลัง มารวมกันเป็นทั้งระบบ สิ่งนี้ไม่ได้ตัดความจำเป็นในการตัดสินใจด้านวิศวกรรมระบบขั้นพื้นฐาน เช่น การทำเกลียว เวลา อายุการใช้งานของวัตถุ ฯลฯ ปัญหาเหล่านี้เป็นส่วนหนึ่งของระบบโดยไม่คำนึงถึงเทคโนโลยี CORBA อนุญาตให้องค์ประกอบของระบบถูกทำให้เป็นมาตรฐานในแบบจำลองระบบเดียวที่เชื่อมโยงกัน
ตัวอย่างเช่น การออกแบบสถาปัตยกรรม หลายระดับ ทำได้ง่ายโดยใช้Java Servletsในเว็บเซิร์ฟเวอร์และเซิร์ฟเวอร์ CORBA ต่างๆ ที่มีตรรกะทางธุรกิจและการเข้าถึงฐานข้อมูล สิ่งนี้ทำให้การปรับใช้ตรรกะทางธุรกิจสามารถเปลี่ยนแปลงได้ ในขณะที่การเปลี่ยนแปลงอินเทอร์เฟซจะต้องได้รับการจัดการเช่นเดียวกับเทคโนโลยีอื่นๆ ตัวอย่างเช่น ฐานข้อมูลที่ห่อหุ้มโดยเซิร์ฟเวอร์สามารถเปลี่ยนสคีมาฐานข้อมูลเพื่อประโยชน์ในการใช้งานดิสก์ที่ดีขึ้นหรือประสิทธิภาพการทำงาน (หรือแม้แต่การเปลี่ยนแปลงผู้จำหน่ายฐานข้อมูลทั้งสเกล) โดยไม่กระทบต่ออินเทอร์เฟซภายนอก ในเวลาเดียวกัน รหัสดั้งเดิม C++ สามารถพูดคุยกับรหัสดั้งเดิม C/Fortran และรหัสฐานข้อมูล Java และสามารถให้ข้อมูลกับเว็บอินเตอร์เฟส
การพิมพ์ข้อมูล
CORBA ให้การพิมพ์ข้อมูลที่ยืดหยุ่น เช่น ประเภทข้อมูล "ใดๆ" CORBA ยังบังคับใช้การพิมพ์ข้อมูลที่เชื่อมโยงกันอย่างแน่นหนา ช่วยลดข้อผิดพลาดของมนุษย์ ในสถานการณ์ที่คู่ของ Name-Value ถูกส่งผ่านไป เป็นไปได้ว่าเซิร์ฟเวอร์จะจัดเตรียมตัวเลขที่คาดว่าจะมีสตริง CORBA Interface Definition Language จัดเตรียมกลไกเพื่อให้แน่ใจว่ารหัสผู้ใช้สอดคล้องกับชื่อเมธอด การส่งคืน ประเภทพารามิเตอร์ และข้อยกเว้น
ความสามารถในการปรับแต่งสูง
การใช้งานหลายอย่าง (เช่น ORBexpress (การใช้งาน Ada, C++ และ Java) [4]และ OmniORB (การใช้งานโอเพ่นซอร์ส C++ และ Python) [5]มีตัวเลือกสำหรับการปรับแต่งคุณสมบัติการจัดการเธรดและการเชื่อมต่อ การใช้งาน ORB ไม่ได้มีคุณสมบัติเหมือนกันทั้งหมด
อิสระจากรายละเอียดการถ่ายโอนข้อมูล
เมื่อจัดการการเชื่อมต่อและเกลียวในระดับต่ำ CORBA จะให้รายละเอียดในระดับสูงในสภาวะข้อผิดพลาด มีการกำหนดไว้ในชุดข้อยกเว้นมาตรฐานที่กำหนดโดย CORBA และชุดข้อยกเว้นเพิ่มเติมเฉพาะการนำไปใช้งาน ข้อยกเว้น แอปพลิเคชันสามารถระบุได้ว่าการโทรล้มเหลวด้วยเหตุผลเช่น "ปัญหาเล็กน้อย ดังนั้นลองอีกครั้ง", "เซิร์ฟเวอร์ไม่ทำงาน" หรือ "ข้อมูลอ้างอิงไม่สมเหตุสมผล" กฎทั่วไปคือ: ไม่ได้รับการยกเว้นหมายความว่าการเรียกเมธอดเสร็จสมบูรณ์ นี่เป็นคุณสมบัติการออกแบบที่ทรงพลังมาก
การบีบอัด
CORBA จัดการข้อมูลในรูปแบบไบนารีและรองรับการบีบอัด IONA, Remedy IT และTelefónicaได้ทำงานเพื่อขยายมาตรฐาน CORBA ที่ให้การบีบอัด ส่วนขยายนี้เรียกว่า ZIOP และปัจจุบันเป็นมาตรฐาน OMG อย่างเป็นทางการ

ปัญหาและคำวิจารณ์

แม้ว่า CORBA จะนำเสนอวิธีการเขียนโค้ดและสร้างซอฟต์แวร์ได้มาก แต่ก็เป็นเรื่องที่ถูกวิพากษ์วิจารณ์ [6]

การวิพากษ์วิจารณ์ CORBA ส่วนใหญ่เกิดจากการใช้มาตรฐานที่ไม่ดีและไม่ใช่ข้อบกพร่องของมาตรฐาน ความล้มเหลวบางประการของมาตรฐานนั้นเกิดจากกระบวนการที่สร้างข้อกำหนดของ CORBA และการประนีประนอมที่มีอยู่ในการเมืองและธุรกิจของการเขียนมาตรฐานทั่วไปที่มาจากผู้ปฏิบัติที่แข่งขันกันหลายคน

ความไม่ลงรอยกันในการใช้งานเบื้องต้น
ข้อกำหนดเบื้องต้นของ CORBA กำหนดไว้เฉพาะ IDL ไม่ใช่รูปแบบ on-the-wire ซึ่งหมายความว่าความเข้ากันได้ของซอร์สโค้ดเป็นสิ่งที่ดีที่สุดที่มีอยู่เป็นเวลาหลายปี ด้วย CORBA 2 และใหม่กว่า ปัญหานี้ได้รับการแก้ไขแล้ว
ความโปร่งใสของตำแหน่ง
แนวคิดเรื่องความโปร่งใสของตำแหน่ง CORBA ได้รับการวิพากษ์วิจารณ์ กล่าวคือ วัตถุที่อยู่ในพื้นที่ที่อยู่ เดียวกัน และสามารถเข้าถึงได้ด้วยการเรียกใช้ฟังก์ชัน อย่างง่าย จะได้รับการปฏิบัติเหมือนกับวัตถุที่อยู่ในที่อื่น (กระบวนการที่แตกต่างกันในเครื่องเดียวกันหรือเครื่องอื่น) นี่เป็นข้อบกพร่องในการออกแบบพื้นฐาน[7] [ การตรวจสอบล้มเหลว ]เนื่องจากทำให้การเข้าถึงอ็อบเจ็กต์ทั้งหมดซับซ้อนพอๆ กับกรณีที่ซับซ้อนที่สุด (กล่าวคือ การเรียกเครือข่ายระยะไกลที่มีระดับความล้มเหลวกว้างๆ ซึ่งไม่สามารถทำได้ในการโทรในพื้นที่) นอกจากนี้ยังซ่อนความแตกต่างที่หลีกเลี่ยงไม่ได้ระหว่างสองคลาส ทำให้แอปพลิเคชันไม่สามารถเลือกกลยุทธ์การใช้งานที่เหมาะสมได้ (นั่นคือการโทรด้วย 1 µsเวลาแฝงและการรับประกันผลตอบแทนจะถูกนำมาใช้แตกต่างอย่างมากจากการโทรที่มีเวลาในการตอบสนอง 1 วินาทีที่อาจเกิดความล้มเหลวในการขนส่ง ซึ่งสถานะการจัดส่งอาจไม่ทราบและอาจใช้เวลา 30 วินาที)
ข้อบกพร่องในการออกแบบและกระบวนการ
การสร้างมาตรฐาน CORBA มักถูกอ้างถึงในกระบวนการออกแบบโดยคณะกรรมการ ไม่มีกระบวนการอนุญาโตตุลาการระหว่างข้อเสนอที่ขัดแย้งกันหรือตัดสินใจเกี่ยวกับลำดับชั้นของปัญหาที่จะแก้ไข ดังนั้นมาตรฐานจึงถูกสร้างขึ้นโดยการรวมเอาคุณลักษณะต่างๆ ไว้ในข้อเสนอทั้งหมดโดยไม่คำนึงถึงการเชื่อมโยงกัน [8]สิ่งนี้ทำให้ข้อกำหนดซับซ้อน มีราคาแพงในการดำเนินการทั้งหมด และมักจะคลุมเครือ
คณะกรรมการออกแบบที่ประกอบด้วยผู้ขายการติดตั้งใช้งานและลูกค้าร่วมกันสร้างกลุ่มความสนใจที่หลากหลาย ความหลากหลายนี้ทำให้มาตรฐานที่เหนียวแน่นเป็นเรื่องยาก มาตรฐานและความสามารถในการทำงานร่วมกันได้เพิ่มการแข่งขัน และทำให้ลูกค้าเคลื่อนย้ายระหว่างการใช้งานทางเลือกต่างๆ ได้ง่ายขึ้น สิ่งนี้นำไปสู่การต่อสู้ทางการเมืองจำนวนมากภายในคณะกรรมการและการแก้ไขมาตรฐาน CORBA บ่อยครั้งซึ่งผู้ดำเนินการ ORB บางคนรับรองว่ายากต่อการใช้งานหากไม่มีส่วนขยายที่เป็นกรรมสิทธิ์ [6]ผู้ค้า CORBA ที่มีจริยธรรมน้อยกว่าสนับสนุนการล็อคอินของลูกค้าและประสบความสำเร็จในระยะสั้นที่แข็งแกร่ง เมื่อเวลาผ่านไป ผู้ขาย ORB ที่สนับสนุนการพกพาเข้ามามีส่วนครองส่วนแบ่งการตลาด [ ต้องการการอ้างอิง ]
ปัญหาในการใช้งาน
ตลอดประวัติศาสตร์ CORBA ประสบกับข้อบกพร่องในการใช้งาน ORB ที่ไม่ดี น่าเสียดายที่เอกสารหลายฉบับที่วิจารณ์ CORBA ว่าเป็นมาตรฐานเป็นเพียงการวิพากษ์วิจารณ์การใช้งาน CORBA ORB ที่แย่เป็นพิเศษ
CORBA เป็นมาตรฐานที่ครอบคลุมพร้อมคุณสมบัติมากมาย มีการใช้งานเพียงไม่กี่ครั้งในการปรับใช้ข้อกำหนดทั้งหมด[8]และการใช้งานเบื้องต้นไม่สมบูรณ์หรือไม่เพียงพอ เนื่องจากไม่มีข้อกำหนดในการจัดเตรียมข้อมูลอ้างอิง สมาชิกจึงมีอิสระที่จะเสนอคุณลักษณะที่ไม่เคยได้รับการทดสอบว่ามีประโยชน์หรือความสามารถในการนำไปใช้ การดำเนินการถูกขัดขวางเพิ่มเติมโดยแนวโน้มทั่วไปของมาตรฐานที่จะละเอียด และแนวปฏิบัติทั่วไปของการประนีประนอมโดยนำผลรวมของข้อเสนอที่ส่งมาทั้งหมดมาใช้ ซึ่งมักจะสร้าง API ที่ไม่ต่อเนื่องกันและใช้งานยาก แม้ว่าข้อเสนอแต่ละรายการจะสมเหตุสมผลอย่างยิ่ง . [ ต้องการการอ้างอิง ]
ในอดีต การใช้งาน CORBA อย่างมีประสิทธิภาพเป็นเรื่องยากมาก แต่ตอนนี้หาได้ง่ายกว่ามาก SUN Java SDK มาพร้อมกับ CORBA ในตัว พบว่าการใช้งานที่ออกแบบมาไม่ดีบางอย่างซับซ้อน ช้า เข้ากันไม่ได้และไม่สมบูรณ์ เวอร์ชันเชิงพาณิชย์ที่แข็งแกร่งเริ่มปรากฏขึ้น แต่ด้วยราคาที่แพงมาก เนื่องจากมีการใช้งานฟรีที่มีคุณภาพดี การใช้งานเชิงพาณิชย์ที่ไม่ดีจึงตายอย่างรวดเร็ว
ไฟร์วอลล์
CORBA (แม่นยำกว่านั้น คือ GIOP ) ไม่ได้ผูกติดอยู่กับการขนส่งทางการสื่อสารใดๆ ความเชี่ยวชาญพิเศษของ GIOP คือ Internet Inter-ORB Protocol หรือ IIOP IIOP ใช้ การเชื่อมต่อ TCP/IP แบบดิบ เพื่อส่งข้อมูล
หากไคลเอนต์อยู่หลังไฟร์วอลล์ที่เข้มงวดมากหรือ สภาพแวดล้อมของ พร็อกซีเซิร์ฟเวอร์แบบโปร่งใสที่อนุญาต การเชื่อมต่อ HTTPกับภายนอกผ่านพอร์ต 80 เท่านั้น การสื่อสารอาจเป็นไปไม่ได้ เว้นแต่ว่าพร็อกซีเซิร์ฟเวอร์ที่เป็นปัญหาจะอนุญาตให้ใช้ วิธีการเชื่อมต่อ HTTPหรือ การเชื่อมต่อ SOCKSเช่นกัน มีอยู่ครั้งหนึ่ง มันยากแม้แต่จะบังคับให้การใช้งานใช้พอร์ตมาตรฐานเพียงพอร์ตเดียว – พวกเขามักจะเลือกพอร์ตสุ่มหลายพอร์ตแทน ณ วันนี้ ORB ปัจจุบันมีข้อบกพร่องเหล่านี้ เนื่องจากปัญหาดังกล่าว ผู้ใช้บางรายจึงใช้บริการเว็บ เพิ่มขึ้น แทน CORBA สิ่งเหล่านี้สื่อสารโดยใช้XML / SOAPผ่านพอร์ต 80 ซึ่งปกติเปิดทิ้งไว้หรือกรองผ่านพร็อกซี HTTP ภายในองค์กร สำหรับการท่องเว็บผ่าน HTTP อย่างไรก็ตาม การใช้งาน CORBA ล่าสุดนั้นรองรับSSLและสามารถกำหนดค่าให้ทำงานบนพอร์ตเดียวได้อย่างง่ายดาย ORBS บางตัว เช่นTAO , omniORB และJacORBยังสนับสนุน GIOP แบบสองทิศทาง ซึ่งทำให้ CORBA มีข้อได้เปรียบในการใช้การสื่อสารแบบเรียกกลับมากกว่าลักษณะวิธีการสำรวจของการใช้งานเว็บเซอร์วิส นอกจากนี้ ไฟร์วอลล์ที่ทันสมัยส่วนใหญ่รองรับ GIOP & IIOP จึงเป็นไฟร์วอลล์ที่เป็นมิตรกับ CORBA

ดูเพิ่มเติม

วิศวกรรมซอฟต์แวร์

เทคโนโลยีซอฟต์แวร์ที่ใช้ส่วนประกอบ

การผูกภาษา

อ้างอิง

  1. ^ "ประวัติของคอร์บา" . กลุ่ม การจัดการวัตถุ สืบค้นเมื่อ12 มีนาคม 2560 .
  2. ^ "ประวัติของคอร์บา" . กลุ่ม การจัดการวัตถุ สืบค้นเมื่อ4 มิถุนายน 2560 .
  3. ^ "โมเดลส่วนประกอบ CORBA" . บันทึก ของDr. Dobb 1 กันยายน 2547 . สืบค้นเมื่อ13 มีนาคม 2560 .
  4. ^ "ORBexpress : เรียลไทม์ CORBA ORB" .
  5. ^ "omniORB : ฟรี CORBA ORB" . sourceforge.net . สืบค้นเมื่อ9 มกราคม 2557 .
  6. a b Chappel, David (พฤษภาคม 1998). "ปัญหากับคอร์บา" . davidchappel.com เก็บถาวรจากต้นฉบับเมื่อ 3 ธันวาคม 2555 . สืบค้นเมื่อ15 มีนาคม 2010 .
  7. ^ วัลโด จิม; เจฟฟ์ ไวแอนต์; แอน วอลรัธ; แซม เคนดัลล์ (พฤศจิกายน 2537) "หมายเหตุเกี่ยวกับคอมพิวเตอร์แบบกระจาย" (PDF ) ห้อง ปฏิบัติการซันไมโครซิสเต็ม สืบค้นเมื่อ4 พฤศจิกายน 2556 .
  8. a b Henning, Michi (30 มิถุนายน 2549). "การขึ้นและลงของคอร์บา" . คิวACM สมาคมเครื่องจักรคอมพิวเตอร์ . 4 (5): 28–34. ดอย : 10.1145/1142031.1142044 . S2CID 12103742 . สืบค้นเมื่อ15 มีนาคม 2010 . 

อ่านเพิ่มเติม

ลิงค์ภายนอก