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

प्लेटफ़ॉर्म का अस्तित्व चार साल से अधिक समय से है, लेकिन अब तक इसका उपयोग हमारी कंपनी के डेवलपर्स और भागीदारों के काफी संकीर्ण दायरे में किया गया है। हम दो प्रतिकृति उत्पादों और उस पर एक दर्जन से अधिक कस्टम प्रोजेक्ट बनाने में कामयाब रहे। और फिर वह क्षण आया जब एक लंबी तैयारी के बाद, हमने इसे सभी के लिए उपलब्ध उत्पाद के रूप में जारी करने का फैसला किया।
आरंभ करने के लिए, मैं मुख्य विशेषताओं की एक छोटी सूची दूंगा। पाठ्यक्रम का विवरण साइट पर पाया जा सकता है।
- Declarative UI निर्माण: XML में स्क्रीन का लेआउट, जावा कक्षाओं में इनिशियलाइज़ेशन और इवेंट हैंडलिंग।
- डेटा-जागरूक दृश्य घटकों का एक पुस्तकालय। सभी मानक, प्लस विशिष्ट हैं, उदाहरण के लिए, एक सार्वभौमिक डेटा फ़िल्टर, विभिन्न क्षमताओं के साथ संबंधित संस्थाओं के लिए चयन फ़ील्ड, समूह के साथ एक तालिका।
- स्क्रीन वेब (AJAX) और डेस्कटॉप (स्विंग) क्लाइंट्स में काम करती हैं। स्रोत आम हैं।
- मेटाडेटा - उन्नत डेटा मॉडल जानकारी। एक डेटा मॉडल "संस्थाओं से टेबल के लिए" डिजाइन करना।
- डेटाबेस में सॉफ्ट डिलीट रिकॉर्ड।
- संस्थाओं, उनकी विशेषताओं और व्यक्तिगत उदाहरणों, स्क्रीन और UI के घटकों के साथ संचालन के स्तर पर एक्सेस अधिकार प्रबंधन।
- यदि आवश्यक हो तो कार्यक्षमता जुड़ा हुआ है: रिपोर्ट जनरेटर, दृश्य संपादक के साथ व्यापार प्रक्रिया मॉड्यूल, पूर्ण-पाठ खोज, क्रेडिट कार्ड के साथ काम करते हैं।
- बॉक्स में से PostgreSQL, MS SQL सर्वर, Oracle, HSQL समर्थित हैं।
- किसी भी वेब कंटेनर पर मानक परिनियोजन।
- सर्वर क्लस्टर पर क्षैतिज स्केलिंग, आप अलग से मध्य परत, अलग से वेब सर्वर कर सकते हैं।
खैर, इसका उपयोग करने के लिए सभी सुविधाजनक बनाने के लिए, हमने एक स्टूडियो बनाया। यह एक अलग एप्लिकेशन है जिसे डेवलपर नियमित जावा आईडीई के समानांतर उपयोग करता है। स्टूडियो प्लेटफ़ॉर्म मैकेनिज्म को एक ग्राफिकल इंटरफ़ेस प्रदान करता है, जिससे आप माउस के साथ डेटा मॉडल पर क्लिक कर सकते हैं, डेटाबेस के लिए DDL स्क्रिप्ट तैयार कर सकते हैं, WYSIWYG संपादक में स्क्रीन बना सकते हैं और मध्य-स्तरीय सेवाएं बना सकते हैं। स्टूडियो का उपयोग करना आवश्यक नहीं है, लेकिन बहुत सी चीजों की सुविधा देता है, खासकर परियोजना के प्रारंभिक चरण में।
इसका उपयोग कौन कर सकता है?
हम मुख्य रूप से उद्यमों की आंतरिक व्यापार प्रक्रियाओं के स्वचालन में शामिल डेवलपर्स के लिए एक उपकरण के रूप में सीयूबीए की स्थिति रखते हैं। यह उत्पादन प्रक्रिया, खरीद और बिक्री, दस्तावेज़ प्रबंधन, कार्मिक प्रबंधन, निगरानी उपकरण और इतने पर हो सकता है। CUBA किसी भी लेखांकन या प्रबंधन प्रणाली के लिए आधार के रूप में कार्य कर सकता है।
इसके अलावा, एक सिद्ध विकल्प बैकएंड वितरित प्रणाली के रूप में मंच का उपयोग करना है। इस मामले में, मध्य परत को मुख्य व्यावसायिक तर्क और कर्मचारियों के लिए यूआई के साथ मंच पर बनाया जाता है, और बाहरी उपयोगकर्ताओं के लिए साइट और मोबाइल एप्लिकेशन मध्यम परत के ग्राहकों के रूप में कार्य करते हैं।

प्लेटफ़ॉर्म का उपयोग करके, आप मुख्य रूप से व्यावसायिक तर्क पर ध्यान केंद्रित कर सकते हैं, क्योंकि अधिकांश बुनियादी ढांचे की समस्याएं पहले से ही हल हो गई हैं। तदनुसार, परियोजना को तेज और कम प्रयास करने के लिए।
हमारी
वेबसाइट पर CUBA के उपयोग की शर्तें वर्णित हैं। एक मुफ्त विकल्प है।
प्रलेखन है।
कहानी
अब मैं मंच की उत्पत्ति और विकास के बारे में बात करना चाहता हूं। दरअसल, हम मुख्य रूप से प्रौद्योगिकियों पर ध्यान केंद्रित करेंगे, इसलिए यह लगभग स्पष्ट हो जाएगा कि CUBA की व्यवस्था कैसे की जाती है।
यह सब कैसे शुरू हुआ। हमारी कंपनी उद्यमों के लिए सूचना प्रणाली बनाने के लिए बनाई गई थी। अलग-अलग उद्यमों के लिए अलग-अलग सिस्टम, और उतना ही बेहतर। हम जावा में जो लिखेंगे, वह पिछले सकारात्मक अनुभव, ओएस से स्वतंत्रता, एक उत्कृष्ट आईडीई की उपस्थिति, सभी स्तरों पर चौखटे की एक विस्तृत चयन और इस तरह की वजह से संदेह नहीं उठाता था। उसी समय, हम समझ गए कि स्क्रैच से हर प्रोजेक्ट बनाना, केवल जावा और उपलब्ध फ्रेमवर्क जो प्रदान करता है, का उपयोग करना मुश्किल और अक्षम है। कॉर्पोरेट सिस्टम की कार्यक्षमता का एक महत्वपूर्ण हिस्सा अंतर है, चाहे व्यवसाय की विशेषताओं की परवाह किए बिना। और जो हिस्सा प्रत्येक एप्लिकेशन में अद्वितीय है, हम आसान और तेज करना चाहते थे। दुर्भाग्य से (या सौभाग्य से), हमें जावा दुनिया में ऐसा कुछ भी तैयार नहीं मिला जो हमारी आवश्यकताओं को पूरा करता हो, "व्यावसायिक अनुप्रयोग बनाने के लिए कोई उपयुक्त मंच", और हमेशा की तरह, हमने अपना लिखने का फैसला किया।
हमने मध्य परत से शुरू किया - उन्होंने EJB3 के साथ JBoss लिया, उन्होंने ORJ के रूप में OpenJPA को खराब कर दिया। क्यों नहीं हाइबरनेट एक अलग लेख के लिए एक विषय है, हम इसे समय के साथ लिखने की कोशिश करेंगे। उन्होंने डेवलपर के लिए पारदर्शी रूप से नरम विलोपन के साथ काम करने के लिए OpenJPA सिखाया ताकि अनुरोधों को जोड़ने और परिणामों को नियंत्रित करने की कोई आवश्यकता न हो।
हमने अपनी मेटाडेटा रूपरेखा लिखी है, जो हमारे लिए सार्वभौमिक तंत्रों को लागू करने के लिए आवश्यक है, जैसे कि दृश्य घटक जो कि इकाई गुण के प्रकार के आधार पर उनके गुणों को कॉन्फ़िगर करते हैं जो वे प्रदर्शित करते हैं। मेटाडेटा के आधार पर, हमने इकाई रेखांकन की घोषणा की घोषणा के लिए एक तंत्र बनाया (हम उन्हें "विचार" कहते हैं)। इस तरह के तंत्र की आवश्यकता है ताकि आवेदन के किसी भी स्तर से डेटा का अनुरोध करना संभव हो और यह इंगित किया जा सके कि अब किस वस्तु का ग्राफ आवश्यक है, अर्थात इस समय हम किन विशेषताओं और संबंधित संस्थाओं के साथ काम करना चाहते हैं।
हमने सुरक्षा पर काम करना शुरू किया: उपयोगकर्ता सत्र, उपयोगकर्ता स्वयं, भूमिकाएं और अभिगम अधिकार। वे पंक्ति-स्तरीय सुरक्षा को लागू करने के तरीके पर अपना दिमाग लगाते हैं। हम इस तथ्य पर ध्यान केंद्रित करते हैं कि बाधाओं से अलग एक पदानुक्रमित संरचना में समूहबद्ध किया जाना चाहिए। बेशक, सभी सुरक्षा प्रबंधन को रनटाइम में कॉन्फ़िगर करने में सक्षम होने के अर्थ में तुरंत गतिशील बना दिया गया था।
वेब यूआई के लिए प्रौद्योगिकी का विकल्प मुश्किल था। हमें स्क्रीन के लेआउट और कोड को अलग करने के लिए कुछ ढांचे के ऊपर अपनी खुद की अमूर्त परत बनाने की जरूरत है, साथ ही दृश्य घटकों के एक सेट को लागू करने के लिए जो हमारे मेटाडेटा का उपयोग करके संस्थाओं के साथ काम करते हैं। इसके अलावा, हमने भविष्य में डेस्कटॉप स्विंगिंग के आधार पर एक ही परत के कार्यान्वयन को बनाने की योजना बनाई है। सामान्य तौर पर, मैं चाहता था कि एप्लिकेशन कोड जावा और हमारे अलावा किसी भी तकनीक पर निर्भर न हो। नतीजतन, वाडिन को वेब क्लाइंट के लिए चुना गया (तब इसे ITMill कहा जाता था)। कुछ विकल्प थे, अच्छी तरह से, और किसी भी मामले में, अब हमें पसंद पर पछतावा नहीं है, क्योंकि ढांचा शक्तिशाली है और सक्रिय रूप से विकसित हो रहा है। यद्यपि हमें बहुत सारे शंकु मिले, हम उनके बारे में एक अलग लेख में बात करने की कोशिश करेंगे।
इस प्रकार, हमें जेनेरिकयूआई मिला - एक्सएमएल और जावा में स्क्रीन बनाने के लिए एक मंच मॉड्यूल। इसमें स्क्रीन लोडर, दृश्य घटकों और डेटा स्रोतों का एक पुस्तकालय होता है जो घटकों को डेटा मॉडल से जोड़ता है। GenericUI पर हमने जो पहली चीज लिखी थी, वह मंच की सुरक्षा प्रबंधन स्क्रीन ही थी। खैर, फिर उन्होंने पहला आवेदन करना शुरू किया - यह एक कस्टम वर्कफ़्लो सिस्टम था। मुझे कहना होगा कि जेनेरिकयूआई आपको सीधे यूआई फ्रेमवर्क के घटकों के साथ अपने आसपास काम करने की अनुमति देता है। सबसे पहले, हमने सक्रिय रूप से इसका इस्तेमाल किया, क्योंकि जेनरिकयूआई की क्षमताएं अक्सर पर्याप्त नहीं थीं। समय के साथ, मंच के विकास के परिणामस्वरूप, इस तरह के "निम्न-स्तर" की कोडिंग की आवश्यकता लगभग गायब हो गई, 99% अनुप्रयोग कोड केवल सामान्यीकृत इंटरफेस के साथ काम करता है।
कुछ समय बाद, JBoss को छोड़ने और स्प्रिंग पर संपूर्ण बुनियादी ढांचे को लागू करने के लिए विचार आया। वसंत की उल्लेखनीय कार्यक्षमता और व्यापकता ने हमें आवश्यक तंत्र को अधिक सरल और विश्वसनीय तरीके से लागू करने में सक्षम किया है। इसके अलावा, हमने सर्वर से स्वतंत्रता प्राप्त की, साथ ही 5 से 15 सेकंड से टॉमकैट पर आवेदन का लॉन्च समय, जो कि JBoss की तुलना में कई गुना तेज है।
एप्लिकेशन को पुनरारंभ करने के स्वीकार्य समय के बावजूद, कभी-कभी सर्वर को बंद किए बिना, मक्खी पर एप्लिकेशन के कुछ हिस्सों को तैनात करना आवश्यक है। इसलिए, हमने विशेष निर्देशिका से गतिशील रूप से संकलन और लोड करने की क्षमता को लागू किया। इसके अलावा, अब स्टूडियो लगातार परियोजना में बदलावों की निगरानी करता है और इस निर्देशिका में UI स्रोतों को फेंकता है, जो स्क्रीन विकसित करते समय बहुत मदद करता है - आप फिर से शुरू किए बिना परिवर्तनों के परिणाम देख सकते हैं, लॉगिन कर सकते हैं, मेनू में स्क्रीन की खोज कर सकते हैं, आदि।
कार्यक्षमता का निर्माण करने का समय आ गया है - अनुप्रयोगों को व्यावसायिक प्रक्रिया प्रबंधन और पूर्ण-पाठ खोज की आवश्यकता है। हमने प्लेटफ़ॉर्म के मुख्य भाग को नहीं उकसाया, लेकिन कई परियोजनाओं में इसे तोड़ दिया जो कि यदि आवश्यक हो तो अनुप्रयोगों द्वारा उपयोग किया जाता है।
वर्कफ़्लो और पूर्ण पाठ खोज के बाद अपना स्वयं का रिपोर्ट जनरेटर विकसित करना शुरू किया। इससे पहले, वे जैस्पररीपोर्ट्स का उपयोग करते थे, लेकिन यह हमारे अनुरूप नहीं था, पहला तो टेम्पलेट्स बनाने की बहुत श्रमसाध्य प्रक्रिया के कारण, और दूसरा यह कि एक्सेल में परिणामों के आउटपुट के साथ कठिनाइयों के कारण। उन्होंने एक सरल विचार लागू किया: अलग से डेटा निष्कर्षण के तर्क का वर्णन करें, अलग से एक्सेल, वर्ड या एचटीएमएल में एक टेम्पलेट बनाएं। इस दृष्टिकोण ने भुगतान किया, और हाल ही में हमने जनरेटर कोर को प्लेटफॉर्म के बाहर उपयोग के लिए
YARG नामक एक अलग ओपन-सोर्स प्रोजेक्ट में अलग कर दिया। हैबे पर उनके बारे में एक लेख होगा।
बिल्ड सिस्टम काफी समय से एंट-स्क्रिप्ट पर आधारित है। इसके अलावा, यदि तीसरे पक्ष के पुस्तकालयों को द्विआधारी रूप में भंडार से डाउनलोड किया गया था, तो मंच केवल एसवीएन से सीधे स्रोतों के रूप में आवेदन परियोजना से जुड़ा था। मंच के गठन के चरण में इस दृष्टिकोण के फायदे थे - कोई भी प्रोग्रामर, जब अपनी परियोजना पर काम कर रहा होता है, तो आसानी से मंच में कुछ ठीक कर सकता है और बस कुछ बदलाव कर सकता है। कुछ बिंदु पर, हमने मानक संस्करण पर स्विच किया, जब बाइनरी कलाकृतियों और प्लेटफ़ॉर्म स्रोतों को बाकी निर्भरताओं के समान परियोजना में लोड किया गया - मावेन भंडार से। उसी समय, हमने चींटी को ग्रैडल से बदल दिया, जिसने हमें प्लगइन में मुख्य असेंबली कोड को संलग्न करने और प्रोजेक्ट स्क्रिप्ट को यथासंभव संक्षिप्त बनाने की अनुमति दी, लेकिन एक ही समय में मनमाने ढंग से एक्स्टेंसिबल।
जब हमने शरलॉक, एक टैक्सी उत्पाद बनाना शुरू किया, तो हमें एक डेस्कटॉप क्लाइंट की आवश्यकता थी। फिर स्विंग पर जेनिसीयूआई घटकों का दूसरा कार्यान्वयन दिखाई दिया। नतीजतन, उत्पाद का पूरा यूआई (300 से अधिक स्क्रीन) दोनों वेब और डेस्कटॉप संस्करणों में एक ही कार्यक्षमता के साथ उपलब्ध है, एकमात्र अंतर इंटरफ़ेस की जवाबदेही और कीबोर्ड के साथ काम करने की बारीकियों में है।
इसके अलावा दोहराया उत्पादों के लिए, हम एक विस्तार तंत्र के साथ आए जो हमें ग्राहकों की आवश्यकताओं के अनुकूल बनाने की अनुमति देता है। एक विस्तार वास्तव में, एक नए अनुप्रयोग की एक परियोजना है जिसमें उत्पाद को एक मंच के रूप में उपयोग किया जाता है। इस प्रकार, हम मुख्य उत्पाद के कोड को बदले बिना ग्राहक के लिए अधिकतम अनुकूलन प्राप्त करने का प्रबंधन करते हैं। उत्पाद संस्करणों को अपडेट करने की क्षमता अभी भी संरक्षित है - इसके लिए यह विस्तार को नए संस्करण के अनुरूप लाने और इसके पुनर्निर्माण के लिए पर्याप्त है।
एक निश्चित समय में, हमारी कंपनी के बाहर डेवलपर्स के लिए मंच को सुलभ बनाने के लिए विचार आया। दो साल पहले, सीयूबीए को दो और आईटी कंपनियों द्वारा अपनाया गया था, जिन्होंने इसके आधार पर बड़ी परियोजनाएं बनाईं: मास्को सरकार के नागरिकों के लिए एक इलेक्ट्रॉनिक संदेश प्रसंस्करण प्रणाली और कजाकिस्तान गणराज्य के कैंसर मरीजों के संघीय इलेक्ट्रॉनिक रजिस्टर। इसने अंततः हमें आश्वस्त किया कि सीयूबीए हमारे लिए न केवल उपयोगी हो सकता है, और हमने एक सार्वजनिक रिलीज की तैयारी शुरू कर दी है।
उस क्षण से, स्टूडियो पर काम शुरू हुआ, जो आपको प्लेटफ़ॉर्म पर विकास शुरू करने के लिए प्रवेश सीमा को कम करने की अनुमति देता है और नियमित कार्यों को और अधिक आसानी से हल करना संभव बनाता है। हमने स्टूडियो को एक वेब एप्लिकेशन बनाया है, जो दिलचस्प एप्लिकेशन प्रदान करता है - क्लाउड में काम करने की सैद्धांतिक क्षमता से लेकर किसी सहयोगी के प्रोजेक्ट से जल्दी जुड़ने की व्यावहारिक संभावना और, उदाहरण के लिए, उसे समस्या को समझने में मदद करता है। स्टूडियो के अतिरिक्त, एक IntelliJ IDEA प्लगइन डेवलपर को CUBA- विशिष्ट परियोजना तत्वों को नेविगेट करने में मदद करने के लिए लिखा गया था।
भविष्य की योजना
फिलहाल, CUBA गहन विकास और निरंतर परिवर्तन के एक चरण से विकास के एक शांत चरण में चला गया है। स्वाभाविक रूप से, सबसे पहले यह विभिन्न स्थानीय सुधारों और दोषों के उन्मूलन की एक सतत प्रक्रिया है। इसके अलावा, हम चार्ट डिस्प्ले मॉड्यूल के पूरा होने से निपटने के लिए निकट भविष्य में योजना बनाते हैं - जावास्क्रिप्ट में नक्शे और इंटरैक्टिव आरेख प्रदर्शित करने के लिए घटक दिखाई देंगे, जिन्हें सर्वर-साइड जावा कोड से अन्य सभी जेनेरिकयूआई घटकों की तरह नियंत्रित किया जाएगा। उसके बाद, सबसे अधिक संभावना है, हम Paa प्रदाताओं के साथ क्लाउड में CUBA अनुप्रयोगों की तैनाती से निपटेंगे।
बेशक, हम बातचीत के लिए खुले हैं, और मंच में सुधार के लिए दिशा-निर्देश मोटे तौर पर डेवलपर्स द्वारा उपयोग किए जाने की इच्छा से निर्धारित किए जाएंगे।
मंच के विपरीत, स्टूडियो एक बहुत ही युवा उत्पाद है। सबसे पहले, हम स्टूडियो की उपयोगिता को बेहतर बनाने के लिए काम कर रहे हैं और इसे और अधिक बुद्धिमान और मैत्रीपूर्ण बनाने की कोशिश कर रहे हैं।
इसके अलावा, हाल ही में प्रलेखन में सुधार के लिए बहुत प्रयास किए गए। जब तक इसमें अंतराल हैं, विशिष्ट समस्याओं को हल करने के लिए स्पष्ट रूप से पर्याप्त उदाहरण और व्यंजनों नहीं हैं। हम इन कमियों को दूर करेंगे, और अगले साल हम अंग्रेजी में सभी दस्तावेज जारी करने जा रहे हैं।
Habré पर हम मंच डिवाइस के विभिन्न पहलुओं और उन समस्याओं के बारे में लेख प्रकाशित करने की योजना बना रहे हैं जिन्हें हमें हल करना था। उम्मीद है कि यह दिलचस्प होगा।