XML / XSLT टेक्नोलॉजीज का भ्रम

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



एक्सएमएल के साथ भी यही हुआ है। XML, सब के बाद, मूल रूप से कुछ भी नया नहीं है। XML, SGML भाषा का एक सरल उपसमूह है जो IBM के 1960 GML की तारीख है। एक्सएमएल, वास्तव में, सूचना विनिमय प्रारूप को मानकीकृत करता है और यह है।



लेकिन एक चमत्कार हुआ, हमें एक्सएमएल मिला और विज्ञापन के लिए एक वस्तु दिखाई दी और निर्माताओं ने हर कोने पर घोषणा करना शुरू कर दिया कि उनके पास पहले से ही एक्सएमएल के साथ डेटाबेस था और सामान्य तौर पर, एक्सएमएल के साथ सब कुछ संतृप्त था।



दूर क्यों देखें, यहाँ यह AJAX है और यहाँ यह विज्ञापन और बिक्री के लिए एक वस्तु है। अब केवल आलसी यह नहीं कहता कि वह AJAX के साथ है।



सामान्य तौर पर, यह है कि दुनिया कैसे काम करती है। सभी नई प्रौद्योगिकियां खराब नहीं हैं और आपको उन्हें शत्रुता के साथ नहीं लेना है। लेकिन हमें कुछ निर्णयों के लिए उपकरणों का चयन करने में सक्षम होना चाहिए और इन निर्णयों को सही ढंग से हमारे व्यवसाय के लिए या हमारी व्यावसायिक समस्याओं को सुलझाने के लिए करना चाहिए।



मेरे लेख में "एक कला के रूप में प्रोग्रामिंग," मैंने तकनीकी फैशन के लिए प्रोग्रामर के उत्साह का उल्लेख किया। और जैसा कि मैंने कहा, मैं खुद एक प्रोग्रामर हूं और मेरे और मेरे सहयोगियों के बीच आम बात थी। और इस लेख में मैं XML / XSLT प्रौद्योगिकियों के उपयोग से संबंधित हमारी गलतियों के बारे में बात करूंगा। शायद यह अनुभव किसी के लिए उपयोगी होगा और उसे इन तकनीकों का उपयोग करने के लिए सही जगह खोजने में मदद मिलेगी। यद्यपि यह दृढ़ता से कहा जा सकता है कि इस लेख से मेरे संबोधन में बहुत आलोचना होगी।



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



ऐसा ही एक उत्पाद है बिट्रिक्स: इन्फो पोर्टल। हमारे द्वारा बनाए गए सबसे परिष्कृत उत्पादों में से एक। MSSQL डेटाबेस के साथ ASP प्रौद्योगिकियों पर आधारित Microsoft प्लेटफ़ॉर्म के लिए डिज़ाइन किया गया था, इसे MS प्लेटफ़ॉर्म पर वेब समाधान बनाने के लिए डिज़ाइन किया गया था।



इस उत्पाद के पहले संस्करण में (1999 या 2000 में, ऐसा लगता है), हमने अपना स्वयं का लिखित टेम्प्लेट इंजन बनाया, जिसमें निर्देश सही टैग में थे और #DATA () # जैसा कुछ दिखाई दिया। इसकी सरल परिस्थितियां और चक्र थे: खैर, जो इस के माध्यम से नहीं गए थे? हां, उन सभी ने जो एक बार सिस्टम बनाया था, जिसे उपयोग और कॉन्फ़िगरेशन के लिए किसी को पारित किया जाना था, ने अपना स्वयं का टेम्पलेट इंजन बनाया।



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



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



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



सभी ने इसे शाब्दिक रूप से लिया और इसी तरह के उत्पाद बनाने शुरू कर दिए। और हां, हमने भी पर्याप्त सुना और माना कि हमारा भविष्य XML / XSLT प्रौद्योगिकियां हैं।



उन्होंने एक उपलब्धि बनाई, जिससे XSLT टेम्प्लेट काफी तेजी से काम करते हैं, प्रौद्योगिकी के विकास में बहुत प्रयास, समय और पैसा लगाया ... सबसे बड़े उत्पाद कैटलॉग में 70 हजार उत्पाद शामिल थे।



लेकिन ग्राहकों ने रूबल में मतदान किया और स्पष्ट किया।



परिणामस्वरूप हमें क्या मिला:



1. XSLT टेम्प्लेट की सादगी का भ्रम।



XML / XSLT का उपयोग करने वाले प्रोजेक्ट ग्राहकों और हमारे सहयोगियों के लिए बहुत मुश्किल साबित हुए। ऐसी परियोजनाओं के स्वामित्व की लागत बहुत अधिक है और जैसे-जैसे परियोजना बढ़ती है, इसमें वृद्धि होती है। बहुत कम XSLT विशेषज्ञ हैं। पर्याप्त उच्च योग्यता वाले विशेषज्ञ द्वारा ही टेक्नोलॉजिकल टेम्प्लेट को ठीक किया जा सकता है। डेटा का चयन करने के लिए XPATH का उपयोग करना भी विशेष रूप से सुविधाजनक नहीं है। इस प्रकार, ग्राहकों के लिए सरलता और परियोजना प्रबंधन में सुविधा के बारे में भ्रम दूर हो गया।



2. नियंत्रणीयता और लचीलेपन का भ्रम।



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



3. प्रदर्शन का भ्रम, कम लागत वाला प्लेसमेंट और मापनीयता।



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



वास्तविक प्रदर्शन समाधान केवल बहु-स्तरीय कैशिंग में दिखाई देता है, जो हमेशा संभव नहीं है, या अवांछनीय, या बस महंगा है, दोनों विकास और उपयोग में है।

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



खैर, और नतीजतन, इस तकनीक पर परियोजनाओं को नियमित होस्टिंग सेवाओं पर रखना बहुत मुश्किल है, लगभग हमेशा ये समर्पित मशीनें हैं। इस तरह की परियोजनाओं को बढ़ाने की आवश्यकता तेज़ी से बढ़ती है और इसके लिए महत्वपूर्ण वित्तीय प्रयासों की आवश्यकता होती है।



4. अमूर्त डेटा और उपस्थिति की सुविधा का भ्रम।



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



5. पुस्तकालयों को बनाने में असमर्थता और काम के परिणामों का पुन: उपयोग



अगले टेम्प्लेट में एक सामान्य ऑपरेशन के साथ काम को आसान बनाने के लिए किसी टेम्प्लेट या XSLT एप्लिकेशन को लाइब्रेरी में नहीं जोड़ा जा सकता है। प्रोग्रामर अपने काम को अपने सहयोगियों को हस्तांतरित करने में बेहद सीमित हैं। पहचानी गई त्रुटियों को कई टेम्प्लेट में ट्रैक किया जाना है।



6. अनुप्रयोग विकास के दौरान विकास जटिलता में गैर-रेखीय वृद्धि



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



और प्रौद्योगिकी में महारत हासिल करने के लिए डेवलपर्स के वीर प्रयासों की क्या बात है?



स्वामित्व और विकास की बड़ी लागत, स्केलिंग की बढ़ती लागत, उत्पादों की कम मांग, महंगी सेवाएं, एक महंगे मूल्य समूह में जाना, आदेशों की संख्या को कम करना, उत्पाद विकास की गति को धीमा करना, काम करने वाले संबद्ध नेटवर्क की कमी ...



क्या इसका मतलब यह है कि हमें XML को पूरी तरह छोड़ देना चाहिए? बिल्कुल नहीं। XML / XSLT एक बहुत ही सुंदर तकनीक है (प्रोग्रामिंग वाक्यांश, सही?) और इसका विकास जारी रहेगा। XML प्रोजेक्ट्स (RSS, Yandex.Market, CommerceML और अन्य) के बीच संचार के लिए बहुत अच्छा काम करता है। छोटे टेम्प्लेट और टुकड़ों के लिए, XML प्रसंस्करण के लिए XSLT का उपयोग आज भी काफी प्रभावी रूप से किया जाता है।



.NET अपने सभी अभिव्यक्तियों में XML का पूर्ण समर्थन करता है। XSLT परिवर्तन भी समर्थित है: यदि आवश्यक हो - उपयोग, आवश्यक नहीं - नहीं। लेकिन कोई भी XML / XSLT का उपयोग करने पर जोर नहीं देता है।



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



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



यह पूरा लेख किस लिए है? अपने उपकरणों को जानबूझकर चुनें, केवल फैशन और प्रौद्योगिकी डेवलपर्स के अपने अविश्वसनीय प्रभावशीलता के बारे में आश्वासन से निर्देशित न करें। यदि आप हमारे जैसा रन उत्पाद बना रहे हैं, तो भागीदारों और ग्राहकों की अर्थव्यवस्थाओं पर विचार करें। यदि उत्पाद का उपयोग करने के लिए डेवलपर को मंच प्रोग्रामिंग भाषा (ASP, JAVA, PHP ...) को जानना होगा और फिर भी डेटा की खोज के लिए टेम्प्लेट और XPATH में XSLT का उपयोग करना होगा, तो यह अकेले उपयोग के लिए परियोजना को लाभहीन बना सकता है, दूसरों की मेजबानी का उल्लेख नहीं करने के लिए। कारणों।



सामान्य तौर पर, किसी ने अपना सिर रद्द नहीं किया।