सामान्य ज्ञान: बाकी और आभासी मशीनें संगत नहीं हैं ।
लंबे समय से विवाद चल रहा है जिसमें मैंने कई बार भाग लिया है, और जो अब तक अनसुलझे हैं। मैं यहां मौजूदा तर्क प्रस्तुत करता हूं, मैं टिप्पणियों और अतिरिक्त तर्कों के लिए दिलचस्पी के साथ सुनूंगा।
इस प्रकार,
थीसिस 1: REST अच्छा है, * -RPC (जैसे XML-RPC, JSON-RPC) खराब है।
थीसिस 2: क्योंकि REST अच्छा है, इसका उपयोग वर्चुअल मशीनों (विशेष रूप से, क्लाउड में) को प्रबंधित करने के लिए किया जाना चाहिए।
पहली नज़र में यह है। उदाहरण के लिए, यदि हम वर्चुअल मशीन के लिए विशेषता (उदाहरण के लिए, "बूट डिस्क" विशेषता) बदलना चाहते हैं, तो हम लिखते हैं:

PUT ... / vm333 / disk1 / bootable
सक्षम = सत्य
PUT ... / vm333 / disk1 / bootable
सक्षम = असत्य
या इस तरह भी:
पोस्ट / वीएम / 333 / डिस्क 1 / बूट करने योग्य
DELETE / vm333 / disk1 / bootable
यदि हम एक डिस्क बनाना चाहते हैं, तो हम कहते हैं POST / vm333 / disk2 और गुण (जैसे आकार या भंडारण) में पास करें।
हालाँकि, यह तब तक ही अच्छा है जब तक हमारा इन्फ्रास्ट्रक्चर डेटाबेस प्रविष्टियों से मिलता-जुलता है।
अब एक सरल प्रश्न: REST में वर्चुअल मशीन की रीबूट कमांड कैसी दिखेगी? आखिरकार, मशीन की स्थिति नहीं बदलती है, क्योंकि यह चल रहा था, यह बनी हुई है। जाहिर है, रिबूट करना एक बेकार कॉल नहीं है, यानी हमें POST कहना चाहिए। लेकिन But POST क्या और कहां? ’। ध्यान दें कि यहां तक कि शटडाउन / शुरू POST बिजली-राज्य में काफी फिट है। लेकिन यहां एक रिबूट है - जो डेटाबेस में किसी वस्तु की स्थिति के "immanence" के तर्क का उल्लंघन करता है और हमें एक क्रूर अनिवार्य दुनिया में ले जाता है - अफसोस, वे फिट नहीं होते हैं। इसी तरह की समस्याएं ऑपरेशन 'इंस्टॉल' (ओएस इंस्टॉलेशन स्टार्ट) के दौरान होंगी।
यहाँ कारण बहुत गहरा है "बस इस पर बहुत अच्छा नहीं है।" शब्द "ontology" के लिए क्षमा करें, लेकिन यह कारण ontological है।
समस्या का सार
क्लाउड में वस्तुएँ (और वास्तव में, सर्वर प्रबंधन फ़ार्म में) डेटाबेस में एक पंक्ति नहीं हैं। वे अपना जीवन जीते हैं, और हमारे डेटाबेस में जो दिखाई देता है (जिससे हम एक REST इंटरफ़ेस संलग्न करने की कोशिश कर रहे हैं) इस जीवन का एक प्रतिबिंब है।
डेटाबेस में कुछ विशेषताएँ आधिकारिक मान हैं। उदाहरण के लिए, अगर हमने कहा कि इस मशीन को 'फोब्बर' कहा जाता है, तो इसे कहा जाता है। और अश्वेतों की राय प्रधान आनंद नहीं देती है। हालांकि, उदाहरण के लिए, 'चल रहे' राज्य पर विचार करें। आखिरकार, यह वर्चुअल मशीन के प्रबंधन के लिए डेटाबेस की "विशेषता" नहीं है। यह _eyo_ है, उसका व्यक्तिगत राज्य है। जैसा वह चाहती है, वैसा ही हो। वह शुरुआत में गिरना चाहता है - और आप इसे चलाने के लिए 'रनिंग' के मूल्य पर पावर-स्टेट विशेषता चलाकर ऐसा नहीं कर सकते। इसी तरह कई अन्य सवालों के साथ: हम कह सकते हैं कि "अपने आप को 32 एमबी मेमोरी बनाएं", लेकिन वर्चुअल मशीन 48 एमबी कोर द्वारा कब्जा की गई मेमोरी को देख सकती है और कह सकती है "धन्यवाद, कोई ज़रूरत नहीं है" - और 64 एमबी पर रोकें। हमने "32 एमबी" विशेषता दर्ज की, और "64 एमबी"। और सबसे बुरी बात यह है कि यह एक "लेन-देन में विफल" स्थिति नहीं थी, एक लेन-देन से इनकार। यह "वह क्या कर सकता है, उसने किया।" यह 128 एमबी था, इसे 32 करने के लिए कहा गया था, यह 64 हो गया। हां, और देरी के साथ - पहले 96 एमबी, फिर 82, और केवल 20 के बाद - 64 मिनट। इसके अलावा, अगर हम वास्तव में तनावग्रस्त हैं और अभी भी कार बनाते हैं (अधिक सटीक रूप से, मशीन सिर के बारे में नहीं सोचेगी " ), तब 32MB के बजाय हम पावर-स्टेट = दुर्घटनाग्रस्त हो जाते हैं। इसके बजाय अपेक्षित 32 एमबी। बकवास। डेटाबेस नहीं, बल्कि किसी तरह का अश्लील साहित्य।
कारण यह है कि हमारा डेटाबेस जिसे हम लिख रहे हैं वह डेटाबेस नहीं है। ये हमारे आधिकारिक अर्थ हैं (जिसके बारे में आभासी मशीन पूरी तरह से जागृत है, जैसे कि इसका नाम और संख्या - और यहां यह थोड़ी सी भी संदेह के बिना एक वास्तविक डीबी है), ये मशीन के लिए हमारी सीमाएं हैं (जो मशीन बाईपास करने की कोशिश कर सकती है, लेकिन यह काम नहीं करेगी, डीबी भी ) और ये हमारी
इच्छाएं हैं जिन्हें मशीन पूरा करने की कोशिश कर सकती है, लेकिन यह
काम नहीं कर सकती
है या यह
अंत तक नहीं हो सकती है।
इस प्रकार, हम एक आज्ञाकारी डेटाबेस और वास्तविक दुनिया के साथ संबंधों की विचारधारा के बीच संबंधों के सार में विरोधाभास देखते हैं।
क्या RPC दुनिया को बचा पाएगी?
इस मामले में, अनिवार्य दृष्टिकोण बहुत अधिक उचित लगता है - किसी भी प्रकार के आरपीसी का उपयोग, जिसमें हम रिमोट (अनिवार्यता) को "कॉल" करते हैं और उनके लिए तर्क देते हैं।
इस मामले में, "वे एक चीज को बदलना शुरू कर देते हैं, यह एक और बदल गया है" अधिक तार्किक लगता है। खासकर अगर vm.set_memory () के बजाय हम vm.send_desired_mem () करेंगे। पहली टीम बकवास कर सकती है, दूसरी - कभी नहीं। उन्होंने कहा कि नंबर पास करो, पास कर दिया। आगे क्या होगा यह वीएम पर निर्भर करेगा। इस मामले में, हम ontological समस्या को हल करते हैं - हम प्रबंधित वस्तुओं की स्वतंत्रता के अधिकार को पहचानते हैं (जहां हम कर सकते हैं - अनुमति / निषेध, जहां हम नहीं कर सकते हैं - हम वास्तविक स्थिति को ठीक करते हैं)।
लेकिन आरपीसी को सही तरीके से डांटा गया है, क्योंकि यह भारी, असुविधाजनक है और आपको डेटाबेस में आरामदायक चिंतन संबंधों के बजाय विषय क्षेत्र के बारे में सोचने देता है।
इस बिंदु पर, एक सुंदर कहानी टूट जाती है और टिप्पणीकारों को यह शब्द दिया जाता है ।