फ्लो-बेस्ड प्रोग्रामिंग

कंप्यूटर प्रोग्रामिंग में, फ्लो-बेस्ड प्रोग्रामिंग (FBP) एक प्रोग्रामिंग प्रतिमान है जो अनुप्रयोग प्रक्रिया सामग्री को ब्लैक बॉक्स प्रक्रिया (कंप्यूटर विज्ञान) के नेटवर्क के रूप में परिभाषित करता है, जो संदेश के माध्यम से पूर्वनिर्धारित कनेक्शनों में डेटा का आदान-प्रदान करता है, जहाँ कनेक्शन 'बाहरी' रूप से निर्दिष्ट होते हैं। प्रक्रियाओं के लिए। इन ब्लैक बॉक्स प्रक्रियाओं को आंतरिक रूप से बदले बिना अलग-अलग एप्लिकेशन बनाने के लिए अंतहीन रूप से फिर से जोड़ा जा सकता है। एफबीपी इस प्रकार स्वाभाविक रूप से सॉफ्टवेयर घटक है | घटक-उन्मुख है।

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

परिचय

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

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

क्योंकि FBP प्रक्रियाएं तब तक क्रियान्वित हो सकती हैं जब तक उनके पास काम करने के लिए डेटा होता है और कहीं अपना आउटपुट डालने के लिए, FBP एप्लिकेशन सामान्यतः पारंपरिक कार्यक्रमों की समानता में कम समय में चलते हैं, और किसी विशेष प्रोग्रामिंग की आवश्यकता के बिना मशीन पर सभी प्रोसेसर का इष्टतम उपयोग करते हैं। इसे पाने के लिये।

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

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

एफबीपी डेटा युग्मन प्रदर्शित करता है, जिसे कपलिंग (कंप्यूटर विज्ञान) पर लेख में घटकों के बीच सबसे ढीले प्रकार के युग्मन के रूप में वर्णित किया गया है। लूस कपलिंग की अवधारणा बदले में सेवा-उन्मुख आर्किटेक्चर से संबंधित है, और FBP इस आर्किटेक्चर के अधिकांश उदाहरणों की समानता में अधिक सूक्ष्म स्तर पर होने के अतिरिक्त , इस तरह के आर्किटेक्चर के लिए कई मानदंड फिट बैठता है।

एफबीपी विनिर्देशों की उच्च स्तरीय, कार्यात्मक शैली को बढ़ावा देता है जो प्रणाली व्यवहार के बारे में तर्क को सरल बनाता है। इसका एक उदाहरण वितरित बहुदलीय प्रोटोकॉल के शब्दार्थ को रचनात्मक रूप से निर्दिष्ट और विश्लेषण करने के लिए वितरित डेटा प्रवाह मॉडल है।

इतिहास

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

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

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

80 के दशक की प्रारंभिक से 1993 तक जे. पॉल मॉरिसन और आईबीएम वास्तुकार वेन स्टीवंस (सॉफ्टवेयर इंजीनियर) ने एफबीपी के पीछे की अवधारणाओं को परिष्कृत और प्रचारित किया। स्टीवंस ने FBP अवधारणा का वर्णन और समर्थन करते हुए कई लेख लिखे, और अपनी कई पुस्तकों में इसके बारे में सामग्री सम्मलित की।. 1994 में मॉरिसन ने FBP का वर्णन करने वाली एक पुस्तक प्रकाशित की, और अनुभवजन्य साक्ष्य प्रदान किया कि FBP ने विकास के समय को कम कर दिया।

अवधारणाएं

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

सरल एफबीपी आरेख

A, B और C कोड घटकों को निष्पादित करने वाली प्रक्रियाएं हैं। O1, O2, और दो IN, कनेक्शन M और N को उनकी संबंधित प्रक्रियाओं से जोड़ने वाले पोर्ट हैं। प्रक्रियाओं बी और सी को एक ही कोड निष्पादित करने की अनुमति है, इसलिए प्रत्येक प्रक्रिया के पास काम करने वाले भंडारण, नियंत्रण ब्लॉक इत्यादि का अपना सेट होना चाहिए। वे कोड साझा करते हैं या नहीं, बी और सी एक ही बंदरगाह का उपयोग करने के लिए स्वतंत्र हैं नाम, पोर्ट नामों के रूप में एकमात्र उन्हें संदर्भित करने वाले घटकों के भीतर अर्थ है (और निश्चित रूप से नेटवर्क स्तर पर) है।

M और N वे हैं जिन्हें अधिकांशतः परिपत्र बफ़र्स के रूप में संदर्भित किया जाता है, और आईपी की संख्या के संदर्भ में एक निश्चित क्षमता होती है जिसे वे किसी भी समय पकड़ सकते हैं।

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

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

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

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

एफबीपी के कार्यान्वयन गैर-प्रीमेप्टिव या प्रीमेप्टिव हो सकते हैं - पहले के कार्यान्वयन गैर-प्रीमेप्टिव (मेनफ्रेम और सी भाषा) होते थे, जबकि नवीनतम जावा कार्यान्वयन (नीचे देखें) जावा थ्रेड क्लास का उपयोग करता है और प्रीमेप्टिव है।

उदाहरण

टेलीग्राम समस्या

एफबीपी घटक अधिकांशतः पूरक जोड़े बनाते हैं। यह उदाहरण ऐसे दो जोड़े का उपयोग करता है। वर्णित समस्या शब्दों में वर्णित के रूप में बहुत सरल लगती है, किन्तु वास्तव में पारंपरिक प्रक्रियात्मक तर्क का उपयोग करके इसे पूरा करना आश्चर्यजनक रूप से कठिन है। कार्य, जिसे टेलीग्राम समस्या कहा जाता है, मूल रूप से पीटर नौर के माध्यम से वर्णित है, एक प्रोग्राम लिखना है जो पाठ की पंक्तियों को स्वीकार करता है और अधिक से अधिक शब्दों वाली आउटपुट लाइनें उत्पन्न करता है, जहां प्रत्येक पंक्ति में वर्णों की संख्या एक निश्चित लंबाई से अधिक नहीं होती है। शब्द विभाजित नहीं हो सकते हैं और हम मानते हैं कि कोई भी शब्द आउटपुट लाइनों के आकार से अधिक लंबा नहीं है। यह टेक्स्ट एडिटर्स में वर्ड-रैपिंग समस्या के समान है।

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

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

यहां एफबीपी में सबसे प्राकृतिक समाधान है (एफबीपी में कोई भी सही समाधान नहीं है, किन्तु यह एक प्राकृतिक फिट जैसा लगता है):

पीटर नौर की टेलीग्राम समस्या

जहाँ DC और RC क्रमशः डीकंपोज और रीकॉम्पोज के लिए हैं।

जैसा कि ऊपर उल्लेख किया गया है, आरंभिक सूचना पैकेट (IIP) का उपयोग पैरामीट्रिक जानकारी निर्दिष्ट करने के लिए किया जा सकता है जैसे कि वांछित आउटपुट रिकॉर्ड लंबाई (सबसे दाहिने दो घटकों के माध्यम से आवश्यक), या फ़ाइल नाम। आईआईपी नेटवर्क परिभाषा में एक बंदरगाह से जुड़े डेटा भाग हैं जो संबंधित बंदरगाह के लिए प्राप्त होने पर सामान्य आईपी बन जाते हैं।

बैच अद्यतन

इस प्रकार के कार्यक्रम में एक मास्टर फ़ाइल के विरुद्ध विवरणों की फ़ाइल (परिवर्तन, जोड़ना और हटाना) पास करना और एक अद्यतन मास्टर फ़ाइल और एक या अधिक रिपोर्ट तैयार करना (कम से कम) सम्मलित है। अपडेट प्रोग्राम सामान्यतः सिंक्रोनस, प्रक्रियात्मक कोड का उपयोग करके कोड के लिए काफी कठिन होते हैं, क्योंकि दो (कभी-कभी अधिक) इनपुट स्ट्रीम को सिंक्रोनाइज़ करना पड़ता है, भले ही संबंधित विवरण के बिना मास्टर्स हो सकते हैं, या इसके विपरीत होता है।

विहित बैच अद्यतन संरचना

एफबीपी में, एक कोलेटर के यूनिट रिकॉर्ड उपकरण विचार के आधार पर एक पुन: प्रयोज्य घटक (कोलेट), इस प्रकार के एप्लिकेशन को लिखना बहुत आसान बनाता है क्योंकि कोलेट दो धाराओं को मर्ज करता है और ग्रुपिंग स्तरों को इंगित करने के लिए ब्रैकेट आईपी सम्मिलित करता है, डाउनस्ट्रीम तर्क को काफी सरल करता है। मान लीजिए कि एक धारा (इस मामले में मास्टर्स) में 1, 2 और 3 के प्रमुख मूल्यों के साथ आईपी सम्मलित हैं, और दूसरी धारा के आईपी (विवरण) में 11, 12, 21, 31, 32, 33 और 41 के प्रमुख मूल्य हैं, जहां पहला अंक मास्टर कुंजी मानों से मेल खाता है। ब्रैकेट आईपी का प्रतिनिधित्व करने के लिए ब्रैकेट वर्णों का उपयोग करके, एकत्रित आउटपुट स्ट्रीम निम्नानुसार होगी:

(m1 d11 d12) (m2 d21) (m3 d31 d32 d33) (d41)

चूंकि 4 के मान वाला कोई मास्टर नहीं था, अंतिम समूह में एक ही विवरण (प्लस ब्रैकेट) होता है।

उपरोक्त स्ट्रीम की संरचना को संक्षेप में बैकस-नौर फॉर्म-जैसे नोटेशन का उपयोग करके वर्णित किया जा सकता है जैसे कि

{([एम] डी*)}*

कोलेट एक पुन: प्रयोज्य ब्लैक बॉक्स (सिस्टम) है जिसे एकमात्र यह जानने की आवश्यकता है कि इसके आने वाले IPs में नियंत्रण फ़ील्ड कहाँ हैं (यहां तक ​​​​कि यह कड़ाई से आवश्यक नहीं है क्योंकि नियंत्रण फ़ील्ड को मानक स्थानों में रखने के लिए ट्रांसफ़ॉर्मर प्रक्रियाओं को अपस्ट्रीम में डाला जा सकता है), और कर सकते हैं तथ्य को किसी भी संख्या में इनपुट स्ट्रीम, और ब्रैकेट नेस्टिंग की किसी भी गहराई के लिए सामान्यीकृत किया जा सकता है। कोलेट इनपुट के लिए एक सरणी-प्रकार पोर्ट का उपयोग करता है, जिससे इनपुट स्ट्रीम की एक चर संख्या की अनुमति मिलती है।

बहुसंकेतन प्रक्रियाएं

फ्लो-आधारित प्रोग्रामिंग बहुत ही स्वाभाविक तरीके से प्रोसेस मल्टीप्लेक्सिंग का समर्थन करती है। चूंकि घटक केवल-पढ़ने के लिए हैं, किसी दिए गए घटक (प्रक्रियाओं) के कितने भी उदाहरण एक दूसरे के साथ अतुल्यकालिक रूप से चल सकते हैं।

मल्टीप्लेक्सिंग का उदाहरण

जब कंप्यूटर में सामान्यतः एक ही प्रोसेसर होता था, तो यह तब उपयोगी होता था जब बहुत सारे I/O चल रहे होते थे; अब जबकि मशीनों में सामान्यतः कई प्रोसेसर होते हैं, यह तब उपयोगी होने लगा है जब प्रक्रियाएँ CPU-गहन होती हैं। इस खंड में आरेख एक एकल लोड बैलेंसर प्रक्रिया को क्रमशः S1, S2 और S3 लेबल वाली तीन प्रक्रियाओं के बीच डेटा वितरित करता है, जो एक घटक के उदाहरण हैं, जो पहले आओ, पहले पाओ पर एकल प्रक्रिया में फ़ीड करते हैं। आधार होता है।

सरल इंटरैक्टिव नेटवर्क

सामान्य इंटरैक्टिव अनुप्रयोग की योजनाबद्ध

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

चूंकि अलग-अलग अनुरोध अलग-अलग बैक-एंड का उपयोग कर सकते हैं, और उन्हें संसाधित करने के लिए बैक-एंड (यदि उपयोग किया जाता है) के लिए अलग-अलग समय की आवश्यकता हो सकती है, उचित अनुरोध लेनदेन के लिए लौटाए गए डेटा से संबंधित प्रावधान किया जाना चाहिए, उदा। हैश तालिका या कैश होता है।

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

अन्य प्रतिमानों और पद्धतियों के साथ समानता

जैक्सन स्ट्रक्चर्ड प्रोग्रामिंग (JSP) और जैक्सन प्रणाली डेवलपमेंट (JSD)

Main articles: जैक्सन संरचित प्रोग्रामिंग and जैक्सन प्रणाली विकास

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

एफबीपी और जेएसपी इनपुट स्ट्रीम के पार्सर के रूप में एक प्रोग्राम (या कुछ घटकों) का इलाज करने की अवधारणा साझा करते हैं।

जैक्सन के बाद के कार्य, जैक्सन प्रणाली विकास (JSD) में, विचारों को और विकसित किया गया।

JSD में डिज़ाइन को अंतिम कार्यान्वयन चरण तक नेटवर्क डिज़ाइन के रूप में बनाए रखा जाता है। मॉडल तब उपलब्ध प्रोसेसर की संख्या में अनुक्रमिक प्रक्रियाओं के एक सेट में परिवर्तित हो जाता है। जैक्सन ने अपनी पुस्तक के खंड 1.3 में इस चरण से पहले उपस्थित नेटवर्क मॉडल को सीधे क्रियान्वित करने की संभावना पर चर्चा की (इटैलिक जोड़ा गया)है।

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

एफबीपी को एमए जैक्सन के माध्यम से एक ऐसे दृष्टिकोण के रूप में मान्यता दी गई थी जो एक कोरटाइन-जैसी तंत्र के माध्यम से संचार करने वाली अनुक्रमिक प्रक्रियाओं में कार्यक्रम अपघटन की उनकी पद्धति का अनुसरण करता है।

अनुप्रयोगी प्रोग्रामिंग

Main article: अनुप्रयोगी प्रोग्रामिंग भाषा

पश्चिम बंगाल एकरमैन एक लागू भाषा को परिभाषित करता है, जो मूल्यों पर लागू ऑपरेटरों के माध्यम से अपनी सभी प्रसंस्करण करता है। सबसे पहली ज्ञात अनुप्रयुक्त भाषा LISP थी।

एक एफबीपी घटक को इसके इनपुट स्ट्रीम (एस) को इसके आउटपुट स्ट्रीम (एस) में बदलने वाले फ़ंक्शन के रूप में माना जा सकता है। इन कार्यों को तब अधिक जटिल परिवर्तन करने के लिए जोड़ा जाता है, जैसा कि यहां दिखाया गया है:

एक को खिलाने वाले दो कार्य

यदि हम धाराओं को लेबल करते हैं, जैसा कि दिखाया गया है, छोटे अक्षरों के साथ, तो उपरोक्त आरेख को संक्षेप में निम्नानुसार दर्शाया जा सकता है:

सी = जी (एफ (ए), एफ (बी));

जैसे कार्यात्मक संकेतन में F का दो बार उपयोग किया जा सकता है क्योंकि यह एकमात्र मूल्यों के साथ काम करता है, और इसलिए इसका कोई दुष्प्रभाव नहीं है, FBP में किसी दिए गए घटक के दो उदाहरण एक दूसरे के साथ समवर्ती रूप से चल सकते हैं, और इसलिए FBP घटकों के दुष्प्रभाव नहीं होने चाहिए दोनों में से एक। FBP नेटवर्क के कम से कम एक भाग का प्रतिनिधित्व करने के लिए कार्यात्मक संकेतन का स्पष्ट रूप से उपयोग किया जा सकता है।

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

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

लिंडा

Main article: लिंडा

ऐसा लगता है कि एफबीपी में कई अवधारणाएं वर्षों से अलग-अलग प्रणालियों में स्वतंत्र रूप से खोजी गई हैं। लिंडा, जिसका ज़िक्र ऊपर किया गया है, ऐसी ही एक है। दो तकनीकों के बीच का अंतर लिंडा स्कूल ऑफ पिरान्हास लोड बैलेंसिंग तकनीक के माध्यम से चित्रित किया गया है - एफबीपी में, इसके लिए एक अतिरिक्त लोड बैलेंसर घटक की आवश्यकता होती है, जो उस सूची में घटक के लिए अनुरोध करता है जिसमें आईपी की सबसे छोटी संख्या संसाधित होने की प्रतीक्षा कर रही है। स्पष्ट रूप से एफबीपी और लिंडा निकट से संबंधित हैं, और एक को आसानी से दूसरे का अनुकरण करने के लिए उपयोग किया जा सकता है।

वस्तु-उन्मुख प्रोग्रामिंग

Main article: ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग

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

सी. एलिस और एस. गिब्स का एक पेपर सक्रिय वस्तुओं और निष्क्रिय वस्तुओं के बीच अंतर करता है। जैसा कि ऊपर कहा गया है, निष्क्रिय वस्तुओं में सूचना और व्यवहार सम्मलित हैं, किन्तु वे इस व्यवहार के समय का निर्धारण नहीं कर सकते हैं। दूसरी ओर सक्रिय वस्तुएँ ऐसा कर सकती हैं। एलिस और गिब्स ने अपने लेख में कहा है कि निष्क्रिय वस्तुओं की समानता में सक्रिय वस्तुओं में अनुरक्षण योग्य प्रणालियों के विकास की अधिक संभावना है। एक एफबीपी एप्लिकेशन को इन दो प्रकार की वस्तुओं के संयोजन के रूप में देखा जा सकता है, जहां एफबीपी प्रक्रियाएं सक्रिय वस्तुओं के अनुरूप होंगी, जबकि आईपी निष्क्रिय वस्तुओं के अनुरूप होंगी।

अभिनेता मॉडल

Main article: एक्टर मॉडल

एफबीपी कार्ल हेविट के अभिनेता को 2 बंदरगाहों के साथ एक अतुल्यकालिक प्रक्रिया के रूप में मानता है: एक इनपुट संदेशों के लिए और एक नियंत्रण संकेतों के लिए। निष्पादन के प्रत्येक दौर के बाद अभिनेता के माध्यम से स्वयं एक नियंत्रण संकेत उत्सर्जित किया जाता है। इस संकेत का उद्देश्य अभिनेता के शरीर के समानांतर निष्पादन से बचना है और इसलिए बिना सिंक्रोनाइज़ेशन के अभिनेता वस्तु के क्षेत्रों तक पहुँचने की अनुमति देना है।

यह भी देखें

• सक्रिय वस्तुएं
• अभिनेता मॉडल
• अपाचे NiFi
• बीएमडीएफएम
• अनुक्रमिक प्रक्रियाओं का संचार | अनुक्रमिक प्रक्रियाओं का संचार (सीएसपी)
• समवर्ती कंप्यूटिंग
• डेटा प्रवाह
• डेटा प्रवाह आरेख
• डेटाफ्लो प्रोग्रामिंग
• IEC 61131|FBD - फंक्शन ब्लॉक डायग्राम (IEC 61131 मानक में एक प्रोग्रामिंग भाषा)
• कार्यात्मक प्रतिक्रियाशील प्रोग्रामिंग
• लिंडा (समन्वय भाषा)
• लो-कोड डेवलपमेंट प्लेटफॉर्म
• मानचित्र छोटा करना
• नोड-लाल
• पाइपलाइन प्रोग्रामिंग
• वेन स्टीवंस (सॉफ्टवेयर इंजीनियर)
• एक्सप्रोक
• याहू पाइप्स

बाहरी संबंध

• Razdow, Allen (December 1997). "Building Enterprise Data Refineries". DMReview. Archived from the original on 2005-03-15. Retrieved 2006-07-15.
• Mayer, Anthony; McGough, Stephen; Gulamali, Murtaza; Young, Laurie; Stanton, Jim; Newhouse, Steven; Darlington, John (2002). "Meaning and Behaviour in Grid Oriented Components" (PDF). London e-Science Centre, Imperial College of Science, Technology and Medicine. Archived from the original (PDF) on 2012-02-04.
• Black, Andrew P.; Huang, Jie; Koster, Rainer; Walpole, Jonathan; Pu, Calton (2002). "Infopipes: An abstraction for multimedia streaming" (PDF). Multimedia Systems. Springer-Verlag. 8 (5): 406–419. doi:10.1007/s005300200062. S2CID 5700383. Retrieved 2006-08-10.
• Kra, David (October 2004). "zSeries and iSeries servers in the grid domain". IBM DeveloperWorks. Retrieved 2006-07-13.
• Ludäscher, Bertram; Altintas, Ilkay; Berkley, Chad; et al. (September 2004). "Scientific Workflow Management and the Kepler System" (PDF). San Diego Supercomputer Center. Retrieved 2006-07-14.
• Bickle, Jerry; Richardson, Kevin; Smith, Jeff (2005). "OMG Software Radio Specification Overview for Robotics" (PDF). Object Management Group - Software-Based Communications. Archived from the original (PDF) on 2006-07-14. Retrieved 2006-07-15.
• Blažević, Mario (2006). "Streaming Component Combinators". Proceedings of Extreme Markup Languages. Archived from the original on 2007-09-18. Retrieved 2006-11-09.
• Kauler, Barry (1999). Flow Design for Embedded Systems, 2nd Edition. R&D Books/Miller Freeman. ISBN 978-0-87930-555-0.
• US patent 5204965, Guthery, Scott B.; Barth, Paul S. & Barstow, David R., "Data processing system using stream stores", issued 1993-04-20, assigned to Schlumberger Technology Corporation 
• Morrison, J. Paul (March 2013). "Flow-Based Programming". Application Developers' News (1). Retrieved 2014-05-25.
• Staplin, George Peter (2006). "Tcl Flow-Based Programming - TFP". Retrieved 2010-10-07.
• Johnston, Wesley M.; Hanna, J. R. Paul; Millar, Richard J. (March 2004). "Advances in dataflow programming languages". ACM Computing Surveys. 36 (1): 1–34. doi:10.1145/1013208.1013209. S2CID 5257722.
• Koster, Rainer; Black, Andrew P.; Huang, Jie; Walpole, Jonathan; Pu, Calton (April 2003). "Thread transparency in information flow middleware". Software: Practice and Experience. 33 (4): 321–349. CiteSeerX 10.1.1.15.3933. doi:10.1002/spe.510. S2CID 37356020. Retrieved 2006-12-05.
• Stevenson, Tony (February 1995). "Review of "Flow-Based Programming"". PC Update, the magazine of Melbourne PC User Group, Australia. Archived from the original on 2006-09-25. Retrieved 2006-12-06.
• Lea, Doug (May 2001). "Composing Oneway Messages". Archived from the original on 2006-09-07. Retrieved 2006-12-06.
• Bowers, Shawn; Ludäscher, B.; Ngu, A.H.H.; Critchlow, T. "Enabling Scientific Workflow Reuse through Structured Composition of Dataflow and Control-Flow" (PDF). SciFlow '06. Archived from the original (PDF) on 2007-02-05. Retrieved 2006-12-06.
• Sorber, Jacob; Kostadinov, Alexander; Garber, Matthew; Brennan, Matthew; Corner, Mark D.; Berger, Emery D. (2007). "Eon". Eon: a language and runtime system for perpetual systems. Proceedings of the 5th international conference on Embedded networked sensor systems - Session: Power management. p. 161. doi:10.1145/1322263.1322279. ISBN 9781595937636. S2CID 12851752.
• Fiedler, Lars; Dasey, Timothy (2014). "Systems and Methods for Composable Analytics". National Technical Information Service. Archived from the original on 2014-08-26. Retrieved 2014-04-01.
• Matt, Carkci (2014). Dataflow and Reactive Programming Systems: A Practical Guide. CreateSpace Independent Publishing Platform. ISBN 978-1497422445.
• Lampa, Samuel; Dahlö, Martin; Alvarsson, Jonathan; Spjuth, Ola (2018). "SciPipe - A workflow library for agile development of complex and dynamic bioinformatics pipelines". bioRxiv: 380808. doi:10.1101/380808. Retrieved 2018-08-02.