आरएमआई बनाम वेब सेवाएं। जावा 2 जावा रीमोटिंग के लिए सबसे अच्छा क्या है?

Question

मैं वेब सर्विसेज और आरएमआई दोनों के लिए नया हूं और मुझे आश्चर्य है कि विभिन्न वेब अनुप्रयोगों के बीच रिमोटिंग करने का बेहतर तरीका कौन सा है, जब ये एप्लिकेशन जावा में लिखे गए हैं, तो जब विभिन्न प्रोग्रामिंग भाषाएं कोई फर्क नहीं पड़तीं (जो होगा डब्ल्यूएस का लाभ हो)।

जबकि एक तरफ मुझे लगता है कि वेब सेवाओं का उपयोग करते समय प्रदर्शन प्रदर्शन ओवरहेड है (क्या किसी को यह साबित करने के लिए कुछ संख्याएं हैं?), दूसरी तरफ ऐसा लगता है कि वेब सेवाएं बहुत कम हैं और अधिक सेवा उन्मुख आर्किटेक्चर (एसओए) लागू करने के लिए इस्तेमाल किया जा सकता है (जो आरएमआई के साथ संभव नहीं है, है ना?)।

इस हालांकि काफी एक सामान्य प्रश्न है, आपकी राय क्या है?

धन्यवाद

Answer 1

वेब सेवाओं एक शिथिल युग्मित वास्तुकला आज्ञा नहीं देते। RMI के साथ, आप यह सुनिश्चित करें कि वर्ग परिभाषाएँ, सभी आवेदन मामलों में समन्वयित रहते हैं जिसका मतलब है कि आप हमेशा एक ही समय भले ही उनमें से केवल एक बदल दिया गया है (जरूरी नहीं पर उन सभी को तैनात करने के लिए है कि बनाने के लिए है, लेकिन यह है सीरियल यूयूआईडी और व्हाट्नॉट की वजह से अक्सर आवश्यकता होती है)

यह भी बहुत स्केलेबल नहीं है, यदि आप लोड बैलेंसर्स रखना चाहते हैं तो यह एक मुद्दा हो सकता है।

मेरे दिमाग में आरएमआई छोटे, स्थानीय अनुप्रयोगों के लिए सबसे अच्छा काम करता है, जो इंटरनेट से संबंधित नहीं हैं लेकिन फिर भी उन्हें डीकॉप्लेड करने की आवश्यकता है। मैंने इसका इस्तेमाल जावा एप्लिकेशन करने के लिए किया है जो इलेक्ट्रॉनिक संचार को संभालता है और मैं परिणामों से काफी संतुष्ट था। अन्य अनुप्रयोगों के लिए जिन्हें इंटरनेट पर अधिक जटिल तैनाती और काम की आवश्यकता होती है, मैं वेब सेवाओं का उपयोग करता हूं।

Answer 2

RMI और वेब सेवाओं के ऊपर अपने अनुमान दर्पण के साथ मेरा अनुभव। आम तौर पर, आरएमआई का प्रदर्शन वेब सेवाओं से कहीं अधिक है, लेकिन इंटरफेस विनिर्देश स्पष्ट रूप से वेब सेवाओं के लिए कहा गया है।

ध्यान दें कि इनमें से कोई भी प्रोटोकॉल की आवश्यकता है कि दोनों तरफ के अनुप्रयोग जावा हो। मैं वेब सेवाओं का उपयोग करता हूं जब मेरे पास इंटरफ़ेस को लागू करने वाले एक या अधिक बाहरी भागीदारों थे, लेकिन आरएमआई अगर मैं कनेक्शन के दोनों सिरों के नियंत्रण में था।

Answer 3

चाहे आप वेब सेवा का उपयोग करें या एक ज्यादा "स्थानीय" दृष्टिकोण के रूप में अच्छी तरह से पर्यावरण पर निर्भर करता है। अगर आपको प्रॉक्सी या कुछ कॉरपोरेट फ़ायरवॉल से गुजरना है, तो वेब सर्विसेज काम करने की अधिक संभावना है क्योंकि वे केवल HTTP पर निर्भर हैं। आरएमआई के लिए आपको अपने आवेदन के लिए एक और बंदरगाह खोलने की आवश्यकता है जो कुछ वातावरण में मुश्किल हो सकता है (तकनीकी रूप से नहीं, हालांकि) ...

यदि आप जानते हैं कि यह समस्या कोई समस्या नहीं है, तो आपको आरएमआई का उपयोग करने पर विचार करना चाहिए। एसओए अच्छी सेवा डिजाइन के रूप में प्रौद्योगिकी पर निर्भर नहीं है। यदि आपके पास ईजेबी कंटेनर है, तो आप आरएमआई के माध्यम से सत्र बीन्स को कॉल कर सकते हैं और अतिरिक्त रूप से उन्हें वेब सेवाओं के रूप में बेनकाब कर सकते हैं, अगर आपको वास्तव में, वैसे भी ज़रूरत है।

प्रदर्शन डेटा है कि आप का आदान प्रदान करने की योजना बना रहे पर निर्भर करता है। यदि आप जटिल ऑब्जेक्ट नेट को एक एप्लिकेशन से दूसरे में भेजना चाहते हैं, तो यह शायद आरएमआई के साथ तेज़ है, क्योंकि इसे बाइनरी प्रारूप (आमतौर पर) में स्थानांतरित किया जाता है। आप शाब्दिक/एक्सएमएल सामग्री किसी तरह का वैसे भी है, तो वेब सेवाओं, बराबर या भी तेजी से हो सकता है के बाद से तो आप (संचार के लिए) सब पर कुछ भी बदलने की आवश्यकता नहीं होगी।

HTH,
मार्टिन

Answer 4

यदि आप जटिल स्थिति को बनाए रखने की आवश्यकता है तो आरएमआई बेहतर दिशा हो सकती है।

Answer 5

वसंत रिमोटिंग के बारे में क्या। यह आरएमआई के द्विआधारी प्रारूप के साथ आरईएसटी-जैसे HTTP प्रोटोकॉल को जोड़ती है। मेरे लिए पूरी तरह से काम करता है।

Answer 6

वसंत रिमोटिंग के लिए (मैंने अनुमान लगाया है कि आप HTTP Invoker का मतलब है), दोनों तरफ स्प्रिंग का उपयोग करना चाहिए, अगर ऐसा है तो इस पर चर्चा की जा सकती है।

जावा से जावा एप्लिकेशन के लिए आरएमआई एक अच्छा समाधान है, जावा-टू-जावा संचार के लिए जेएक्स-आरपीसी या जेएक्स-डब्ल्यूएस से बचा जाना चाहिए यदि ग्राहक आपके नियंत्रण में नहीं हैं या किसी अन्य प्लेटफॉर्म पर जा सकते हैं।

Answer 7

एक बात है कि RMI से अधिक WS के पक्ष में है कि WS HTTP पोर्ट 80/443 जो आम तौर पर फायरवॉल पर अवरुद्ध नहीं कर रहे हैं पर काम करता है, नेट आदि के पीछे काम कर सकते हैं है RMI एक बहुत जटिल अंतर्निहित नेटवर्क प्रोटोकॉल है जो आप को खोलने के लिए की आवश्यकता है है आरएमआई बंदरगाह, और यदि ग्राहक नाटकीय है तो भी काम नहीं कर सकता है। दूसरी बार आरएमआई के साथ आप अपनी आस्तीन को जावा-जावा संचार में सीमित कर रहे हैं, जबकि वेबसाइटों के साथ ऐसी कोई सीमा नहीं है। तार पर वेबसाइटों को डीबग करना बहुत आसान है क्योंकि डेटा SOAP/HTTP है, जिसे डिबगिंग के लिए टूल को आसानी से पकड़ा जा सकता है। मैं आरएमआई पर ऐसा करने का एक आसान तरीका नहीं जानता। आरएमआई के अलावा वास्तव में बहुत पुराना है और पिछले कुछ वर्षों से ज्यादा ध्यान नहीं मिला है। यह उन दिनों में बड़ा था जब कॉरबा बड़ा था, और आरएमआई कॉर्बा दोनों वास्तव में पुरातन तकनीकें हैं। सबसे अच्छा विकल्प आरईएसटी स्टाइल वेबसाइट है।

Answer 8

@Martin Klinke

"प्रदर्शन डेटा है कि आप विदेशी मुद्रा की योजना बना रहे पर निर्भर करता है। जब आप एक आवेदन से जटिल वस्तु जाल भेजना चाहते हैं, यह शायद तेजी से RMI के साथ है क्योंकि यह एक में स्थानांतरित कर रहा है बाइनरी प्रारूप (आमतौर पर)। यदि आपके पास किसी प्रकार की पाठ्यचर्या/एक्सएमएल सामग्री है, तो वेब सेवाएं बराबर या तेज हो सकती हैं, तब से आपको कुछ भी (संचार के लिए) कुछ भी बदलने की आवश्यकता नहीं होगी। "

जहां तक ​​मुझे पता है कि प्रदर्शन समस्या सीरियलाइजेशन के दौरान अंतर बनाती है- दूसरे शब्दों में मार्शलिंग-डेमरशलिंग प्रक्रिया में deserialization। मुझे यकीन नहीं है कि ये दोनों शर्तें एक ही बीटीडब्ल्यू वितरित प्रोग्रामिंग में, मैं प्रक्रिया के बारे में बात नहीं कर रहा हूं उसी JVM में, यह डेटा के प्रतिलिपि बनाने के तरीके के बारे में है। यह या तो मूल्य से गुजरता है या संदर्भ द्वारा पास होता है। बाइनरी प्रारूप मूल्य से गुजरता है जिसका अर्थ है किसी ऑब्जेक्ट को बाइनरी में रिमोट सर्वर पर कॉपी करना। अगर आपको अब तक कोई संदेह है तो मैं

मार्शलिंग-डेमरशलिंग या क्रमबद्धता-deserialization के मामले में बाइनरी प्रारूप और पाठ्य/xml सामग्री में भेजने के बीच क्या अंतर है?

मैं सिर्फ guessin.It डेटा आप किस तरह का send.Whatever डेटा टाइप आप भेजने यह मार्शलिंग-demarshalling प्रक्रिया के और अंत में हिस्सा सही बाइनरी में भेजा जाएगा हो जाएगा पर निर्भर नहीं करता हूँ?

चियर्स हक्की

Answer 9

एक स्प्रिंग धर्मांध और कई वर्षों मैं वसंत दूरस्थ सलाह देंगे के लिए SOA के एक प्रतिपादक के रूप में। सेवा निर्यातक का यह स्वाद आरएमआई के लिए चाल करेगा।

org.springframework.remoting.rmi.RmiServiceExporter 

अन्य परिवहन निश्चित रूप से उपलब्ध हैं। यदि आप अपने इंटरफेस (एंड-पॉइंट्स) और डीटीओ को समझदारी से & संस्करण क्रमशः यूआईआईडी का प्रबंधन करते हैं तो क्रमबद्धता चीज काफी प्रबंधनीय है। हम अपने इंटरफेस और ऑब्जेक्ट्स और वृद्धि के लिए 'अल्फा', 'ब्रावो' पोस्टफिक्स करते हैं, & की कमी, जहां और कब आवश्यक हो। हम अपने क्रमिकरण यूयूआईडी को 1 तक भी ठीक करते हैं और सुनिश्चित करते हैं कि परिवर्तन केवल addative हैं, अन्यथा हम कहते हैं, 'ब्रावो' से 'चार्ली'। एंटरप्राइज़ सेटअप में सभी प्रबंधनीय।