การวิเคราะห์เชิงลึกเกี่ยวกับการใช้คอมพิวเตอร์แบบกระจาย Java

มันจะง่ายที่สุดถ้าส่วนประกอบทั้งหมดถูกดำเนินการบนพื้นที่ฮีปเดียวกันของเครื่องเสมือน Java เดียวกันบนคอมพิวเตอร์เครื่องเดียวกัน แต่ในทางปฏิบัติเรามักจะไม่ต้องเผชิญกับสถานการณ์เดียวเช่นนี้ หากไคลเอนต์เป็นเพียงอุปกรณ์ที่สามารถรัน Java ได้ ทำ? จะเกิดอะไรขึ้นถ้าด้วยเหตุผลด้านความปลอดภัยเฉพาะโปรแกรมบนเซิร์ฟเวอร์เท่านั้นที่สามารถเข้าถึงฐานข้อมูลได้?

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

โดยปกติแล้วเราจะรับข้อมูลจากคอมพิวเตอร์เครื่องหนึ่งไปยังคอมพิวเตอร์อีกเครื่องหนึ่งผ่านทางอินพุต/เอาท์พุตของซ็อกเก็ต เปิดการเชื่อมต่อซ็อกเก็ตของคอมพิวเตอร์อีกเครื่อง แล้วรับเอาต์พุตสตรีมเพื่อเขียนข้อมูล แต่หากเราต้องการเรียกคอมพิวเตอร์เครื่องอื่นมาที่เครื่องของคุณ คอมพิวเตอร์ อะไรคือวิธีการของวัตถุบนเครื่องเสมือน Java อื่น? แน่นอนว่าเราสามารถกำหนดและออกแบบโปรโตคอลการสื่อสารเองเพื่อเรียก แล้วส่งผลการดำเนินการกลับมาผ่าน Socket ได้ และยังสามารถเป็นเหมือนการเรียกวิธีการบนเครื่องโลคอลได้ กล่าวคือ หากเราต้องการเรียกวัตถุระยะไกล (เช่น เช่นเดียวกับฮีปอื่นๆ) ) แต่ควรเป็นเหมือนการโทรปกติ

นี่คือสิ่งที่ RMI นำมาให้เรา

การออกแบบการเรียกโพรซีเดอร์ระยะไกล

มี 4 สิ่งที่ต้องสร้าง: เซิร์ฟเวอร์ ไคลเอนต์ สิ่งอำนวยความสะดวกเสริมเซิร์ฟเวอร์ และสิ่งอำนวยความสะดวกเสริมไคลเอนต์

1. สร้างแอปพลิเคชันไคลเอ็นต์และเซิร์ฟเวอร์ แอปพลิเคชันเซิร์ฟเวอร์เป็นบริการระยะไกล ซึ่งเป็นออบเจ็กต์ที่มีวิธีการที่ไคลเอ็นต์จะเรียกใช้

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

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

กระบวนการเรียกเมธอด

1. อ็อบเจ็กต์ไคลเอ็นต์เรียก doBigThing() บนอ็อบเจ็กต์สิ่งอำนวยความสะดวกเสริม

2. สิ่งอำนวยความสะดวกเสริมของลูกค้าจะจัดแพคเกจข้อมูลการโทรและส่งไปยังสิ่งอำนวยความสะดวกเสริมของเซิร์ฟเวอร์ผ่านเครือข่าย

3. สิ่งอำนวยความสะดวกเสริมฝั่งเซิร์ฟเวอร์ถอดรหัสข้อมูลจากสิ่งอำนวยความสะดวกเสริมฝั่งไคลเอ็นต์ และใช้เพื่อเรียกใช้บริการจริง

แผนภาพที่อธิบายกระบวนการนี้มีดังนี้:

JavaRMI จัดเตรียมอ็อบเจ็กต์ตัวช่วยฝั่งไคลเอ็นต์และฝั่งเซิร์ฟเวอร์

ใน Java RMI ได้ช่วยเราสร้างสิ่งอำนวยความสะดวกเสริมฝั่งไคลเอ็นต์และฝั่งเซิร์ฟเวอร์ นอกจากนี้ยังรู้วิธีทำให้สิ่งอำนวยความสะดวกเสริมฝั่งไคลเอ็นต์ดูเหมือนบริการจริง กล่าวอีกนัยหนึ่ง RMI รู้วิธีจัดเตรียมวิธีการเดียวกันสำหรับการเรียกไคลเอ็นต์ .

นอกจากนี้ RMI ยังมีโครงสร้างพื้นฐานทั้งหมดที่จำเป็นสำหรับการดำเนินการ รวมถึงการสอบถามบริการและสิ่งอำนวยความสะดวกเสริมที่ช่วยให้ลูกค้าสามารถค้นหาและรับลูกค้า (ตัวแทนบริการจริง)

เมื่อใช้ RMI ไม่จำเป็นต้องเขียนโปรแกรมเครือข่ายหรืออินพุต/เอาท์พุตใดๆ การเรียกไคลเอ็นต์ไปยังเมธอดระยะไกลจะเหมือนกับการเรียกเมธอดบนเครื่องเสมือน Java เดียวกัน

การโทรทั่วไปจะแตกต่างจากการโทร RMI เล็กน้อย แม้ว่าการเรียกเมธอดนี้จะดูเป็นแบบท้องถิ่น แต่ระบบเสริมของไคลเอ็นต์จะทำการโทรผ่านเครือข่ายในที่สุด และเอเจนต์จะแปลงเป็นรีโมต วิธีการส่งข้อมูลระดับกลางจากเครื่องเสมือน Java ไปยังเครื่องเสมือน Java ขึ้นอยู่กับโปรโตคอลที่ใช้โดยอ็อบเจ็กต์สิ่งอำนวยความสะดวกเสริม

เมื่อใช้ RMI คุณต้องตัดสินใจเลือกโปรโตคอล: JRMP หรือ IIOP JRMP เป็นโปรโตคอลดั้งเดิมของ RMI มันถูกออกแบบมาสำหรับการโทรระยะไกลระหว่าง Java สำหรับอ็อบเจ็กต์หรือวิธีการระยะไกลประเภทอื่นๆ CORBA มักจะมีปัญหามากกว่า RMI เพราะหากปลายทั้งสองไม่ใช่ Java การดำเนินการแปลและการสนทนาที่แย่มากจะเกิดขึ้นมากมาย

เราสนใจเฉพาะการดำเนินการระหว่าง Java ถึง Java เท่านั้น ดังนั้นเราจะใช้ RMI ที่ค่อนข้างง่าย

ใน RMI สิ่งอำนวยความสะดวกเสริมฝั่งไคลเอ็นต์เรียกว่า stubs และสิ่งอำนวยความสะดวกเสริมฝั่งเซิร์ฟเวอร์เรียกว่าโครงกระดูก

วิธีสร้างบริการระยะไกล

1.สร้างอินเทอร์เฟซระยะไกล

อินเทอร์เฟซระยะไกลกำหนดวิธีการที่ไคลเอนต์สามารถเรียกจากระยะไกล เป็นคลาส polymorphic เป็นบริการ ทั้ง stub และบริการจะใช้อินเทอร์เฟซนี้

2. ใช้อินเทอร์เฟซระยะไกล

นี่คือคลาสการดำเนินการจริง โดยใช้วิธีการที่กำหนดไว้บนอินเทอร์เฟซ

3. ใช้ rmic เพื่อสร้าง stub และ skeleton

ทั้งไคลเอนต์และเซิร์ฟเวอร์ต่างก็มีตัวช่วย เราไม่จำเป็นต้องสร้างคลาสเหล่านี้หรือสร้างซอร์สโค้ดของคลาสเหล่านี้

4. เริ่มการลงทะเบียน RMI (rmiregistry)

rmiregistry เปรียบเสมือนสมุดโทรศัพท์ ผู้ใช้จะได้รับพรอกซี (วัตถุต้นขั้ว/ตัวช่วยของลูกค้า) จากที่นี่

5. เริ่มบริการระยะไกล

วัตถุบริการจะต้องเริ่มดำเนินการ คลาสที่ใช้บริการจะเริ่มอินสแตนซ์บริการและลงทะเบียนกับ RMIRegistry หลังจากลงทะเบียนแล้วเท่านั้นที่สามารถให้บริการผู้ใช้ได้

รหัสเซิร์ฟเวอร์

กำหนดอินเทอร์เฟซ

เครื่องมือ rmic ที่มาพร้อมกับ JDK จะสร้างสองคลาส ได้แก่ stub และ skeleton โดยขึ้นอยู่กับการใช้งานบริการ โดยจะเพิ่ม _Stub หรือ _Skeleton หลังชื่อการใช้งานระยะไกลตามกฎการตั้งชื่อ rmic มีหลายตัวเลือก รวมถึงการไม่สร้างโครงกระดูก การสังเกตซอร์สโค้ดของคลาสที่สร้างขึ้น หรือใช้ IIOP เป็นโปรโตคอลการสื่อสาร คลาสที่สร้างขึ้นจะถูกวางไว้ในไดเร็กทอรีปัจจุบัน โปรดจำไว้ว่า rmic จะต้องสามารถค้นหาคลาสที่นำไปใช้ได้ ดังนั้น คุณอาจต้องดำเนินการ rmic จากไดเร็กทอรีที่มีการใช้งานอยู่ (ในทางปฏิบัติ คุณอาจต้องพิจารณาโครงสร้างไดเร็กทอรีแพ็กเกจและชื่อเต็ม เพื่อความง่าย จะไม่มีการใช้แพ็กเกจที่นี่)

เรียกบรรทัดคำสั่งเพื่อเริ่ม rmiregistry ตรวจสอบให้แน่ใจว่าคุณเริ่มต้นจากไดเร็กทอรีที่สามารถเข้าถึงคลาสได้ วิธีที่ง่ายที่สุดคือการรันจากไดเร็กทอรีของคลาส

ภาพหน้าจอการทำงานมีดังนี้

สังเกต:

ไคลเอนต์ใช้อินเทอร์เฟซเพื่อเรียกเมธอดบน stub เครื่องเสมือน Java ของไคลเอนต์ต้องมีคลาส stub แต่ไคลเอนต์จะไม่อ้างอิงคลาส stub ในโค้ดโปรแกรมเสมอ

เซิร์ฟเวอร์จะต้องมี stub และโครงกระดูก รวมถึงบริการและอินเทอร์เฟซระยะไกล โดยต้องใช้คลาส stub เนื่องจาก stub จะถูกแทนที่ด้วยบริการจริงที่เชื่อมต่อกับ RMIRegistry