ABBYYOnline - एक वास्तुकार का दृश्य

आज हम पोर्टल http://www.abbyyonline.com के उदाहरण का उपयोग करके वितरित, विषम और कभी-कभी काफी गंभीरता से और इंटरनेट से लोड किए गए इंटरनेट अनुप्रयोगों के बारे में बात करेंगे। मैं एक विशेष प्लेटफॉर्म से संबंधित तकनीकी विवरणों में नहीं जाने की कोशिश करूंगा, और यद्यपि वर्णित एप्लिकेशन का मुख्य भाग ASP.Net MVC पर लागू किया गया है, यह सामग्री वेब विकास से संबंधित हर किसी के लिए रुचि की हो सकती है, भले ही उपयोग किए गए उपकरण की परवाह किए बिना।



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

1. हमारे आसपास की दुनिया के प्रति विश्वास
2. व्यवसाय की आवश्यकताएं

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



व्यवसाय कोई कम क्रूर नहीं है ... विपणन के विचार के अनुसार, एओएल को इंटरनेट पर पूरी कंपनी का चेहरा होना चाहिए, ताकि एबीबीवाई ऑनलाइन प्रदान करने वाली सभी सेवाएं इस पोर्टल पर प्रस्तुत करें।



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



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

सामान्य संरचना

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

एकल साइनऑन और क्रॉस-डोमेन प्रमाणीकरण

पहली समस्या एकल उपयोगकर्ता आधार और एकल साइनऑन प्रमाणीकरण है - यहां कठिनाई क्या है? जैसा कि हम पहले ही पता लगा चुके हैं, वेब एप्लिकेशन की विशेषताओं में से एक राज्य की कमी है। व्यवहार में, इसका मतलब है कि ब्राउज़र से सर्वर के लिए प्रत्येक अनुरोध पिछले एक पर निर्भर नहीं करता है, और हर बार सर्वर को "जो हमारे पास आया था" का अनुमान लगाना चाहिए? परंपरागत रूप से, यह समस्या एक विशेष प्रमाणीकरण कुकी लिखकर हल की जाती है, जिसे ब्राउज़र कुकी के समाप्त होने तक प्रत्येक अनुरोध के साथ सर्वर में वापस भेज देता है। लेकिन तथ्य यह है कि, सुरक्षा कारणों से, साइट का सर्वर हिस्सा केवल उसी दूसरे स्तर के डोमेन पर दर्ज कुकी को पढ़ सकता है, उदाहरण के लिए, http://finereader.abbyyonline.com पर तैनात साइट कुकी को पढ़ सकती है, जो साइट ने लिखी है http://www.abbyyonline.com पर तैनात है, लेकिन साइट http://finereaderonline.com किसी भी परिस्थिति में इस तरह की कुकी नहीं पढ़ेगी। हालांकि, हमारे कार्य की शर्तों के अनुसार, पोर्टल के विभिन्न भाग विभिन्न डोमेन पर स्थित हो सकते हैं, इसलिए हमें किसी प्रकार के क्रॉस-डोमेन प्रमाणीकरण तंत्र की आवश्यकता होती है।



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



किसी भी पोर्टल साइट के किसी भी पेज को एक्सेस करते समय, आपको यह पता लगाना होगा कि यह उपयोगकर्ता का पोर्टल जानता है या नहीं। किसी भी पृष्ठ पर, केवल एक सुरक्षित क्यों नहीं? क्योंकि उपनाम, प्रोफ़ाइल का लिंक और अन्य व्यक्तिगत जानकारी का हिस्सा सभी पृष्ठों पर दिखाया जाना चाहिए ताकि उपयोगकर्ता जानता हो कि हम उसे याद करते हैं और उसे देखकर खुशी महसूस करते हैं :)



इस लक्ष्य को प्राप्त करने के लिए, क्रियाओं का निम्नलिखित क्रम किया जाता है।

1. साइट अपने स्वयं के उत्पादन का एक प्रमाणीकरण कुकी पढ़ने की कोशिश कर रही है। यदि यह सफल होता है, तो प्रमाणीकरण प्रक्रिया यहां समाप्त हो जाती है, क्योंकि अगर कोई ऐसी कुकी है, तो इसका मतलब है कि उपयोगकर्ता पहली बार यहां नहीं है और हमने इस साइट पर उसकी सफलतापूर्वक पहचान की है।
2. साइट एक विशेष कुकी को पढ़ने की कोशिश कर रही है जिसमें कहा गया है कि प्रमाणीकरण प्रक्रिया की गई थी, लेकिन सफल नहीं थी। यदि यह सफल होता है, तो आप यहां समाप्त भी कर सकते हैं - हम जानते हैं कि हम इस उपयोगकर्ता को नहीं जानते हैं।
3. यदि पिछले पैराग्राफ असफल रहे थे, तो ...
   
   
   1. साइट एक विशेष अद्वितीय टोकन बनाती है
   2. डेटाबेस में, नेम प्लेट में, एक प्रविष्टि बनाई जाती है, जो अन्य बातों के अलावा, प्रमाणीकरण का अनुरोध करने वाले पृष्ठ के टोकन और यूआरएल को शामिल करती है।
   3. साइट एक विशेष कुकी लिखती है, जो कहती है कि अभी तक हम इस उपयोगकर्ता को नहीं जानते हैं, लेकिन हमने पहले ही एक प्रमाणीकरण अनुरोध भेजा है। इस कुकी की भूमिका अच्छी तरह से एक नियमित प्रमाणीकरण कुकी द्वारा एक संकेत के साथ निभाई जा सकती है कि उपयोगकर्ता एक अनाम उपयोगकर्ता है - इस मामले में, पैरा नंबर 2 की कोई आवश्यकता नहीं है।
   4. साइट अनुरोध को एक विशेष केंद्रीय सर्वर url में रीडायरेक्ट करती है, अनुरोध पंक्ति में उसी टोकन को पास करती है।
   
   
   
4. ऐसा अनुरोध प्राप्त करने के बाद, केंद्रीय सर्वर ...
   
   
   1. उपयोगकर्ता से इसकी प्रमाणीकरण कुकी पढ़ने की कोशिश करता है।
   2. यह डेटाबेस में पाता है, क्वेरी स्ट्रिंग में स्थानांतरित टोकन पर एक ही असली टैबलेट में, वांछित रिकॉर्ड और वहां पिछले पैराग्राफ से ऑपरेशन के परिणाम लिखते हैं।
   3. केंद्रीय सर्वर उस साइट पर वापस रीडायरेक्ट करता है, जो अनुरोध करने के लिए एक विशेष यूआरएल के लिए अनुरोध पंक्ति में एक ही टोकन के साथ
   
   
   
5. साइट, इस विशेष url के लिए अनुरोध प्राप्त कर रही है, जो प्रत्येक पोर्टल साइट पर होना चाहिए ...
   
   
   1. वह प्रमाणीकरण प्रक्रिया के बारे में कुकी को पढ़ने की कोशिश कर रहा है (हमने इसे खंड 3 सी में लिखा है।) और यदि यह संभव नहीं था, तो ग्राहक कुकी रिकॉर्डिंग का समर्थन नहीं करता है, और हम कुकीज़ के बिना काम नहीं कर सकते हैं, इसलिए आपको उपयोगकर्ता को होम पेज पर भेजने की आवश्यकता है, जो समझदार है उसके मन में इस घृणित तथ्य को लाएगा।
   2. डेटाबेस में चढ़ना, सब कुछ एक ही तालिका में है और टोकन केंद्रीय सर्वर से प्रमाणीकरण परिणाम को पढ़ता है।
   3. यदि केंद्रीय सर्वर द्वारा प्रमाणीकरण सफल रहा, तो वह अपनी प्रमाणीकरण कुकी को लिख देता है ताकि अगली बार उपयोगकर्ता बर्बाद न हो।
   4. प्रमाणीकरण प्रक्रिया शुरू करने वाले पृष्ठ पर वापस भेज देता है।
   
   
   

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

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

एक सामान्य डिजाइन बनाना।

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



मानक ASP.Net नियंत्रण और MVC टेम्पलेट (उर्फ आंशिक दृश्य) इस कार्य में बहुत सफल नहीं हैं, सबसे पहले, वे विभिन्न परियोजनाओं में विभिन्न टीमों के बीच साझा करने के लिए असुविधाजनक हैं, और दूसरी बात, वे FreeBSD पर लोगों के लिए पूरी तरह से बेकार हैं। कुछ विचार के बाद, निम्नलिखित पैटर्न को तैयार किया गया ...



प्रत्येक सामान्य नियंत्रण का मूल xml / xsl बंडल है। इस तरह के नियंत्रण का स्थानीयकृत xml उसी एपीआई के माध्यम से केंद्रीय सर्वर से प्राप्त किया जाता है, जो कुछ मामलों में इस xml को गतिशील रूप से केंद्रीय सर्वर के लिए उपलब्ध डेटा के आधार पर बनाने की अनुमति देता है, उदाहरण के लिए, विभिन्न प्रकार के मेनू प्रदान करने के लिए। अंतिम html प्राप्त करने के लिए Xsl साझा पुस्तकालयों से संबंधित एक विशेष विधानसभा के संसाधनों में स्थित है, और उसी विधानसभा में केंद्रीय सर्वर से xml निकालने के लिए कोड है, इसे xsl के साथ संसाधित करना और परिणाम को सही ढंग से कैशिंग करना है। लगभग हमेशा, एक सहायक साइट पर नियंत्रण का उपयोग करने के लिए, यह उपयुक्त मापदंडों के साथ विधि को कॉल करने के लिए पर्याप्त है और नियंत्रण प्रदान किया जाएगा, दुर्लभ मामलों में यह प्रतिपादन प्रक्रिया में जागने और कुछ विशिष्ट कार्य के लिए इसे थोड़ा सही करने के लिए आवश्यक हो सकता है, जो एक समस्या भी नहीं है।



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

ऑनलाइन स्टोर।

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



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



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

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



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

निष्कर्ष

अंत में, मैं कह सकता हूं कि यहां, सबसे सामान्य शब्दों में, पोर्टल आर्किटेक्चर का केवल एक हिस्सा वर्णित है जो उपयोगकर्ता के लाभ के लिए एक-दूसरे के साथ शांतिपूर्वक सह-अस्तित्व में विभिन्न ऑनलाइन सेवाओं के पूरे पहनावा को मजबूर करने के प्रयास से संबंधित है। :) प्रत्येक व्यक्ति सेवा अपने तरीके से अद्वितीय और दिलचस्प है ... :)



इवान बॉडीगिन

पाठ पहचान उत्पाद विभाग