कोई सेवा-उन्मुख भाषा क्यों नहीं है?

Question

संपादित करें:

आगे भ्रम से बचने के लिए: मैं वेब सेवाओं और इस तरह की बात नहीं कर रहा हूं । मैं आंतरिक रूप से अनुप्रयोगों को संरचित करने के बारे में बात कर रहा हूं, यह इस बारे में नहीं है कि कंप्यूटर कैसे संवाद करते हैं। यह प्रोग्रामिंग लैंग्वेज, कम्पाइलर और कैसे अनिवार्य प्रोग्रामिंग प्रतिमान के बारे में बताया गया है।

मूल:

अनिवार्य प्रोग्रामिंग क्षेत्र में, हमने पिछले 20 वर्षों (या अधिक) में दो प्रतिमानों को देखा: ऑब्जेक्ट-ओरिएंटेड (OO), और सेवा-उन्मुख (SO) उर्फ। घटक आधारित (सीबी)।

दोनों प्रतिमान अपने स्वयं के मॉड्यूल की धारणा को लागू करके अनिवार्य प्रोग्रामिंग प्रतिमान का विस्तार करते हैं। OO उन्हें ऑब्जेक्ट्स (और क्लासेस) कहता है और उन्हें डेटा (फ़ील्ड्स) और प्रोसेस (मेथड) दोनों को एकसाथ इनकैप्सुलेट करता है। एसओ, इसके विपरीत, कोड (घटकों, सेवाओं) से डेटा (रिकॉर्ड, सेम, ...) को अलग करता है।

हालाँकि, केवल OO के पास प्रोग्रामिंग भाषाएं हैं जो मूल रूप से इसके प्रतिमान का समर्थन करती हैं: स्मॉलटाक, C ++, जावा और अन्य सभी JVM-कंपेटिबल्स, C # और अन्य सभी .NET-कंपेटिबल्स, पायथन आदि।

SO के पास ऐसी कोई मूल भाषा नहीं है। यह केवल प्रक्रियात्मक भाषाओं या OO भाषाओं के शीर्ष पर अस्तित्व में आता है: COM / DCOM (बाइनरी, सी, C ++), CORBA, EJB, स्प्रिंग, गिटार (सभी जावा), ...

ये एसओ फ्रेमवर्क स्पष्ट रूप से उनकी अवधारणाओं के मूल देशी भाषा समर्थन से पीड़ित हैं।

• वे सेवाओं और रिकॉर्ड का प्रतिनिधित्व करने के लिए OO कक्षाओं का उपयोग करना शुरू करते हैं। यह उन डिज़ाइनों की ओर ले जाता है जहाँ वर्गों के बीच एक स्पष्ट अंतर होता है जिसमें केवल विधियाँ (सेवाएँ) होती हैं और जिनके पास केवल फ़ील्ड्स (रिकॉर्ड्स) होते हैं। सेवाओं या रिकॉर्ड के बीच विरासत को तब वर्गों की विरासत द्वारा सिम्युलेटेड किया जाता है। तकनीकी रूप से, इसका कड़ाई से पालन नहीं किया जाता है, लेकिन सामान्य प्रोग्रामर को सलाह दी जाती है कि वे दो में से केवल एक भूमिका निभाने के लिए कक्षाएं बनाएं।
• वे लापता भागों का प्रतिनिधित्व करने के लिए अतिरिक्त, बाहरी भाषाओं का उपयोग करते हैं: आईडीएल के, एक्सएमएल कॉन्फ़िगरेशन, जावा कोड में एनोटेशन, या यहां तक ​​कि एम्बेडेड डीआईओएस जैसे गाइस। यह विशेष रूप से आवश्यक है, लेकिन सीमित नहीं है, क्योंकि सेवाओं की संरचना स्वयं सेवा कोड का हिस्सा नहीं है। OO में, ऑब्जेक्ट अन्य ऑब्जेक्ट बनाते हैं, इसलिए ऐसी सुविधाओं की कोई आवश्यकता नहीं है, लेकिन SO के लिए इसलिए है क्योंकि सेवाएँ अन्य सेवाओं को तुरंत या कॉन्फ़िगर नहीं करती हैं।
• वे OO (प्रारंभिक EJB, CORBA) के शीर्ष पर एक आंतरिक-प्लेटफ़ॉर्म प्रभाव स्थापित करते हैं, जहां प्रोग्रामर को सभी कोड लिखने होते हैं, जिन्हें "ड्राइव" करने के लिए एसओ की आवश्यकता होती है। कक्षाएं एक सेवा की प्रकृति का केवल एक हिस्सा होती हैं और कई वर्गों को एक साथ सेवा बनाने के लिए लिखना पड़ता है। सभी कि बॉयलर प्लेट आवश्यक है क्योंकि कोई एसओ संकलक नहीं है जो इसे प्रोग्रामर के लिए करेगा। यह कुछ वैसा ही है जैसे कुछ लोगों ने O के लिए C में किया था जब C ++ नहीं था। आप केवल उस रिकॉर्ड को पास करते हैं जो ऑब्जेक्ट के डेटा को प्रक्रिया के पहले पैरामीटर के रूप में रखता है जो कि विधि है। OO भाषा में यह पैरामीटर निहित है और संकलक सभी कोड का उत्पादन करता है जो हमें SO के लिए आभासी कार्यों आदि के लिए चाहिए, यह स्पष्ट रूप से गायब है।
• विशेष रूप से नए ढांचे बड़े पैमाने पर ओओ भाषा में लापता भागों को जोड़ने के लिए एओपी या आत्मनिरीक्षण का उपयोग करते हैं। यह आवश्यक भाषा अभिव्यक्ति नहीं लाती है, लेकिन पिछले बिंदु में वर्णित बॉयलर प्लेटफ़ॉर्म कोड से बचा जाता है।
• बॉयलर प्लेट कोड के उत्पादन के लिए कुछ फ्रेमवर्क कोड पीढ़ी का उपयोग करते हैं। XML में कॉन्फ़िगरेशन फ़ाइल या OO कोड में एनोटेशन इसके लिए जानकारी का स्रोत है।

सभी घटनाएं जो मैंने ऊपर बताई हैं, उन्हें एसओ के लिए जिम्मेदार ठहराया जा सकता है, लेकिन मुझे आशा है कि यह स्पष्ट रूप से दिखाता है कि एसओ भाषा की आवश्यकता है। चूंकि यह प्रतिमान इतना लोकप्रिय है: एक क्यों नहीं है? या हो सकता है कि कुछ अकादमिक हों लेकिन कम से कम उद्योग एक का उपयोग नहीं करता है।

Comments

घटक आधारित वास्तुकला SOA के लिए एक आवश्यकता हो सकती है लेकिन घटक आधारित के लिए SOA आवश्यक नहीं है। ओओ सिस्टम जो डेटा संरचनाओं से सेवाओं को अलग नहीं करते हैं वे घटक-आधारित भी हो सकते हैं।

— डैनी व्रॉड

@ डैनी: मैं सीबी और एसओए के बीच अंतर नहीं करता। यदि आप उनमें से प्रत्येक की परिभाषा पढ़ते हैं, तो वे मूल रूप से समान हैं। सीबी 2000 से पहले और एसओए मैं 2000 के बाद की तरह है क्योंकि सीबी को किसी समय "मृत" माना जाता था और कोई भी इस शब्द का उपयोग नहीं करना चाहता था। मैं SOA को वेब सेवाओं या इस तरह सीमित नहीं करता, लेकिन प्रोग्रामिंग प्रतिमान का संदर्भ देता हूं।

— वोल्फगैंग

आप दोनों के बीच टाल नहीं सकते, लेकिन वे अलग हैं। सीबी और इसके उपयोग पर अधिक पढ़ें।

— डैनी व्रॉड

मैंने सीबी और एसओ के बीच अंतर खोजने के लिए लंबे समय से कोशिश की। दोनों में से किसी एक का कोई ऐसा फीचर नहीं मिला जिस पर दूसरे का भी दावा न हो।

— वोल्फगैंग

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

— डैनी व्रॉड

Answer 1

क्योंकि <5% कोड वास्तव में एक सेवा को परिभाषित कर रहा है, और मैं समय की काफी कम राशि का तर्क दूंगा। एक बार इंटरफ़ेस परिभाषित होने के बाद, यह काफी हद तक हो जाता है। बाकी समय OO (या विकल्प) में काम करने में व्यतीत होता है ।

सीधे शब्दों में कहें, यह समस्या के उस छोटे से टुकड़े के लिए एक विशेष भाषा बनाने के लिए एक बड़ी जीत नहीं है। यदि कुछ भी हो, तो दो भाषाओं (सेवा के लिए एक और कार्यान्वयन / उपभोग के लिए) केवल जोड़ा एकीकरण जटिलता के लिए पूछ रहा है।

[ओपी स्पष्टीकरण के लिए संपादित करें कि यह आंतरिक अनुप्रयोग लेआउट है, आवेदन सीमा नहीं]:

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

Comments

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

— वोल्फगैंग

@ मेरे अनुभव में अत्याचारी कोड की मात्रा उतनी महान नहीं है।

— तेलस्टिन

@ वोल्फगैंग अगर ऐसा है, तो आप उचित OOP का उपयोग नहीं कर रहे हैं, एक OO कोटिंग के साथ सिर्फ प्रक्रियात्मक कोड

— TheCatWhisperer

Answer 2

कार्यात्मक भाषाएँ अपने मूल में बहुत सेवा उन्मुख हैं। ऑब्जेक्ट बनाने और उन पर कॉल करने के बजाय, आप फ़ंक्शंस बनाते हैं और उन्हें संदेश भेजते हैं। एरलैंग इस तकनीक का एक प्रमुख उदाहरण है क्योंकि भाषा के कार्यात्मक पहलुओं से परे भी इसमें अंतर-प्रक्रिया है और यहां तक ​​कि इसके मुख्य ढांचे में निर्मित अंतर-मशीन संचार भी आपको दूरस्थ प्रक्रिया में संदेश भेजने की अनुमति देता है जैसे कि यह एक स्थानीय प्रक्रिया थी। ।

अन्य भाषाएं जैसे स्काला, क्लॉजुर और एफ # भी "सेवा-उन्मुख" शब्दार्थ प्रदान करती हैं। समस्या यह नहीं है कि वे मौजूद नहीं हैं, यह है कि सामान्य आबादी उनसे डरती है और इसलिए वे उतने लोकप्रिय नहीं हैं।

Comments

इसके अलावा Erlang में OTP है जो वास्तव में सेवाओं के विचार के आसपास बनाया गया है और उन्हें विश्वसनीय बनाता है। एक सर्वर का निर्माण जो ओटीपी में एक गलती के बाद ठीक हो जाएगा। (यह 10 मिनट के काम की तरह लगता है)

— Zachary K

Answer 3

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

कुछ नई भाषा की आवश्यकता नहीं है, क्योंकि बहुत समस्या पहले से ही कई भाषाओं के होने के बारे में है , जो उच्च अंतर लागत का कारण बनती है।

हालाँकि, एक प्रकार की भाषा थी, वेब सेवा परिभाषा भाषा। WSDL SOA की मेटा भाषा है (और WADL नाम के REST के लिए एक और छोड़ दिया गया है)

Comments

यह ऐसी भाषाएं नहीं हैं जो अंतर-समस्या पैदा करती हैं। यह अनुप्रयोगों की संरचना है। कुछ भाषाएं उन एप्स को बनाने के लिए बेहतर हैं जो इंटरॉपरेट करती हैं, लेकिन इंटरप्रेनरेशन ऐप का एक कार्य है न कि भाषा।

Answer 4

मैं सवाल को घुमा दूंगा और पूछूंगा कि "SO भाषा क्या दिखती है?"

मॉड्यूल के बीच उन अनुबंधों को कैसे लिखा जाएगा?
ऑपरेशन के मौलिक यांत्रिकी को कैसे निष्पादित किया जाएगा?

सेवा उन्मुख अनुप्रयोग की एक संपत्ति है, जरूरी नहीं कि इस्तेमाल की गई भाषा हो। सेवा एक निर्माण है जो एक फ़ंक्शन पर निर्भर करती है। फ़ंक्शन एक निर्माण है जो मशीन के निष्पादन योग्य निर्देशों में ऑपरेशन का अनुवाद करने के लिए एक प्रोग्रामिंग भाषा के यांत्रिकी पर निर्भर करता है।

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

ग्रेट क्यू और मुझे एक अच्छे पल का प्रतिबिंब दिया।

Comments

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

— वोल्फगैंग

Answer 5

मैं अपने स्वयं के प्रश्न का उत्तर देता हूं कि कितने लोग सहमत हैं और असहमत हैं।

कुछ संभावनाएँ:

• एसओ भाषा का निर्माण करना कठिन प्रतीत होता है। ज्यादातर सेवाओं और उनकी संरचना के कार्यान्वयन के अलगाव के कारण। विश्वविद्यालय में मैंने (बिना किसी संदर्भ, खेद) के अकादमिक समाधानों के एक जोड़े को सुना है, लेकिन यह उद्योग में नहीं लगता है। लेकिन मैं इसे एक बहाने के रूप में गिनता हूं, वास्तविक कारण नहीं। OO भाषाओं और कंपाइलरों को लागू करना बहुत मुश्किल है, फिर भी, लंबे समय तक बाजार पर समाधान मौजूद हैं।

• प्रोग्रामर SO के लिए OO भाषाओं का उपयोग करते हैं क्योंकि वे OO को नहीं समझते हैं और इसका गलत तरीके से उपयोग करते हैं। मैं गलत कहता हूं क्योंकि OO में दो मूलभूत अवधारणाएं हैं जो SO के विपरीत हैं:

  1. कार्यक्षमता उस वर्ग में जाती है जहां डेटा स्थित है जो वे काम करते हैं। कोड और डेटा को एक ही मॉड्यूल में एक साथ युग्मित किया जाता है। अन्य वर्गों के डेटा पर काम करने वाली अलग-अलग कक्षाएं होना OO शैली नहीं है। यह Züllighofen के उपकरण और सामग्री दृष्टिकोण (WAM) है जो SO प्रतिमान से मेल खाता है।

  2. ऑब्जेक्ट अन्य ऑब्जेक्ट बनाते हैं और ऑब्जेक्ट का नेटवर्क बनाते हैं। वे पदानुक्रम या जो भी जटिल संबंध बना सकते हैं। सेवाएं हमेशा फ्लैट नेटवर्क बनाती हैं जो बाहर से निर्मित होती हैं। सेवाओं में आमतौर पर केवल एक उदाहरण (सिंगलटन) होता है, जबकि वस्तुओं को जितनी बार वे प्रतिनिधित्व करते हैं उतनी बार त्वरित रूप से मौजूद होते हैं। SO में रिकॉर्ड नेटवर्क में नहीं जुड़े हैं।

• OO की कुछ विशेषताएं SO के समान दिखती हैं, या इसका उपयोग SO की आवश्यकता के लिए किया जा सकता है ताकि OO भाषा का उपयोग करने में आसानी हो।

  1. OO में निर्भरता-व्युत्क्रम सिद्धांत उसी तरह से है जैसे सेवाओं को बाहरी रूप से बनाया जाता है।

  2. सिंगलटन ऑब्जेक्ट्स सेवाओं की तरह हैं, ऑब्जेक्ट फैक्ट्री सर्विस लोकेटर की तरह हैं।

  3. OO में भी इंटरफेस है जो सर्विस इंटरफेस के समान है।

  4. सेवाओं और अभिलेखों की विरासत के रूप में वर्गों का अनुगमन (समान) हो सकता है।

• OO और SO विभिन्न प्रकार की समस्याओं के लिए उपयोगी हैं। इसलिए हर अनुप्रयोग में या तो यहाँ या वहाँ प्रतिमान का उपयोग करना ललचाता है। एक अलग भाषा होने से दोनों के बीच एक ही कार्यक्रम में स्विच करने में बाधा आएगी।

• एसओ न केवल एक प्रोग्रामिंग प्रतिमान है, बल्कि एक प्रोग्राम व्यवहार भी है: वेब सेवाएं, ऑपरेटिंग सिस्टम घटक आदि एसओ हैं, लेकिन एसओ भाषा में लिखे जाने की आवश्यकता नहीं है। इस तरह के "बाइनरी घटक" बहुत स्वाभाविक और सफल हैं। लेकिन यह एक अलग बात है: यह है कि कैसे कार्यक्रम एक-दूसरे के साथ संवाद करते हैं, न कि कैसे कार्यक्रम आंतरिक रूप से संवाद करते हैं। मुझे लगता है कि लोग मिश्रण करते हैं जो अक्सर पर्याप्त होता है।