नमस्कार, हेब्र! हमने हाल ही में जर्मन जावा चैंपियन सेबेस्टियन डैश्नर की किताब "
लर्निंग जावा ईई। मॉडर्न प्रोग्रामिंग फॉर लार्ज एंटरप्राइजेज " प्रकाशित की।
श्री डैशनर सक्रिय रूप से आधुनिक जावा ईई से संबंधित विषयों पर लिखते हैं और बोलते हैं, इसलिए उनके ब्लॉग ने जकार्ता ईई प्लेटफॉर्म के लिए सामान्य डिजाइन सिद्धांतों को अनदेखा नहीं किया, जो अब एक्लिप्स द्वारा विकसित किया गया है। इस विशेष लेख (जून) का अनुवाद आज हम आपके ध्यान में ला रहे हैं।
जकार्ता ईई प्लेटफॉर्म धीरे-धीरे ले रहा है, और इसके साथ उद्यम विकास के लिए नए विनिर्देश उभर रहे हैं। विभिन्न मानकों और तकनीकों पर सहमत होने के लिए जो उभरने वाले हैं, संपूर्ण जावा ईई समुदाय को केवल तभी लाभ होगा जब जकार्ता ईई विनिर्देशों के लिए सामान्य डिजाइन सिद्धांत विकसित किए जाते हैं।
मेरा मानना है कि जावा ईई तकनीक केवल कुछ सिद्धांतों के साथ इतनी सफल रही है। नीचे मैं अपनी बात प्रस्तुत करूंगा कि जावा ईई में विकसित किए गए कौन से डिजाइन सिद्धांत मुझे सबसे महत्वपूर्ण लगते हैं, जो आगे के अध्ययन के योग्य हैं और संभावित रूप से जकार्ता ईई में डिजाइन के लिए सिफारिशों के रूप में काम कर सकते हैं।
मैंने यह लेख लिखने का फैसला किया, जकार्ता ईई के तकनीकी विकास को किस दिशा में जाना है, उस दिशा में दिमित्री कोर्निलोव के प्रस्तावों से प्रेरित होकर।
पहली बात व्यावसायिक तर्क हैजावा ईई में अपनाए गए प्रोग्रामिंग मॉडल डेवलपर को ठीक उसी चीज़ पर ध्यान केंद्रित करने की अनुमति देता है जो आवश्यक है - जो कि व्यावसायिक तर्क पर है। अब आपको API वर्गों को इनहेरिट करने की आवश्यकता नहीं है; डेवलपर सामान्य जावा भाषा में अपने विषय क्षेत्र के तर्क को व्यक्त कर सकता है और मुख्य रूप से घोषित रूप से (एनोटेशन का उपयोग करके) एप्लिकेशन सर्वर के व्यवहार को नियंत्रित करता है। इस प्रकार, रूपरेखा मूल रूप से आपके कोड में एकीकृत होती है और, संक्षेप में, वहाँ से निकालना उतना ही आसान है। डिजाइन करते समय, पुन: उपयोग पर भरोसा न करें, लेकिन आसान हटाने पर।
हालांकि, कार्यान्वयन को अधिकतम रूप से सबसे कठिन काम के डेवलपर को राहत देना चाहिए - यही है, उसे तकनीकी आवश्यकताओं से बचने की अनुमति दें जो व्यावसायिक तर्क से संबंधित नहीं हैं। उदाहरण मल्टीथ्रेडिंग, लेनदेन, नियंत्रण व्युत्क्रम या HTTP अनुरोध प्रसंस्करण हैं। आवेदन पक्ष पर, उबाऊ अच्छा है :)
यह मेरे लिए महत्वपूर्ण लगता है कि रूपरेखा न केवल व्यावसायिक तर्क के कार्यान्वयन में हस्तक्षेप करती है, बल्कि प्रोग्रामर को उत्पादन के लिए विकसित सुविधाओं को जल्दी लाने के लिए प्रोत्साहित करती है। चमकने के लिए रूपरेखा को चमकाने की आवश्यकता नहीं है - आदर्श के लिए व्यापार तर्क के कोड को लाना बेहतर है। J2EE के पुराने जमाने के संस्करणों के साथ आधुनिक जावा ईई या स्प्रिंग की तुलना करें - मुझे लगता है कि आप तुरंत समझ जाएंगे कि मेरा क्या मतलब है।
जकार्ता ईई को एक ही नस में विकसित करना चाहिए और, तदनुसार, उन विनिर्देशों पर ध्यान केंद्रित करना चाहिए जो डेवलपर्स को व्यावसायिक तर्क को जल्दी से लागू करने की अनुमति देगा।
विन्यास सम्मेलनोंजावा ईई एक विशिष्ट उद्यम अनुप्रयोग को परिभाषित करने के लिए आवश्यक कॉन्फ़िगरेशन को कम करता है। अधिकांश व्यावहारिक स्थितियों में, समझौते बॉक्स के ठीक बाहर काम करते हैं, कोई कॉन्फ़िगरेशन की आवश्यकता नहीं है। तो, अब आपको सरल जावा ईई एप्लिकेशन को कॉन्फ़िगर करने के लिए किसी भी XML फ़ाइलों की आवश्यकता नहीं है। एक और उदाहरण है कि JAX-RS डिफ़ॉल्ट HTTP प्रतिक्रिया कोड प्रदान करता है जो JAX-RS विधियों के रिटर्न मानों के अनुरूप है।
जावा ईई में व्यवहार को संशोधित करने और अधिक जटिल लिपियों को लागू करने का लचीलापन है; हालाँकि, इस पर कोई सहमति नहीं है।
जकार्ता ईई को सरल को आसान, और जटिल को संभव में बदलना जारी रखना चाहिए।
अंतर विशिष्टताएँजकार्ता ईई को विनिर्देशों के अंतर को जारी रखना और विस्तार करना चाहिए। जावा ईई मौजूदा विनिर्देशों और उनमें मौजूद कार्यक्षमता का अनुपालन करता है जो पहले ही मानक का हिस्सा बन चुके हैं।
किसी भी कॉन्फ़िगरेशन की आवश्यकता के बिना डेवलपर्स एक दूसरे के साथ अच्छी तरह से बातचीत करने के लिए अलग-अलग विनिर्देशों पर भरोसा कर सकते हैं। मांगे गए मानक: यदि रनटाइम वातावरण विनिर्देश A और विनिर्देश B दोनों का समर्थन करता है, तो A + B को एक दूसरे के साथ बातचीत करनी चाहिए। उदाहरण: घटक सत्यापन, JAXB, या JSON-B का उपयोग JAX-RS संसाधन वर्गों में किया जा सकता है, और इसके आगे किसी विन्यास की आवश्यकता नहीं है।
निर्भरता इंजेक्शन और सीडीआईबेशक, जकार्ता ईई के लिए यह अवांछनीय है कि उन चीजों को फिर से स्थापित किया जाए जो पहले से मौजूद हैं - उदाहरण के लिए, सीडीआई से संबंधित निर्भरता इंजेक्शन। यह वांछनीय है कि विनिर्देशों जेएसआर 330 की ताकत का उपयोग करें और जोर दें या, यदि आवश्यक हो, तो सीडीआई।
एक
UriInfo उदाहरण संसाधन विधियों में JAX-RS से
UriInfo का उपयोग है। एनोटेशन
@Inject इस प्रकार की विधि के कार्यान्वयन का समर्थन नहीं करता है। यह प्रोग्रामर के काम करने के लिए अधिक सुविधाजनक है, जितना अधिक वह सार्वभौमिक तंत्र पर निर्भर करता है।
एक और विशिष्ट उपाय यह है: सीडीआई प्रदाताओं को विनिर्देशों में प्रदान किया जाना चाहिए, और, यदि आवश्यक हो, तो उन प्रकारों के लिए टाइपसेफ़ क्वालिफायर, जिन्हें बनाने की आवश्यकता है। तो, फिलहाल, JAX-RS क्लाइंट उदाहरण केवल
ClientBuilder API के माध्यम से प्रोग्रामेटिक रूप से प्राप्त किया जा सकता है। निर्माता और क्वालिफायर, घोषित परिभाषाएँ प्रदान करके प्रोग्रामर के काम को सरल बनाते हैं।
घोषणात्मक दृष्टिकोणइस सब के लिए, नियंत्रण के उलट का उपयोग करते हुए, जावा ईई एपीआई एक घोषणात्मक दृष्टिकोण पर बहुत अधिक निर्भर करता है। इस प्रकार, डेवलपर्स सीधे कार्यक्षमता को नहीं कहते हैं; कंटेनर कार्यात्मक कॉल करने के लिए जिम्मेदार है, जबकि हम कोड परिभाषाओं पर भरोसा करते हैं। उदाहरण (सबसे मौजूदा विनिर्देशों से) JAX-RS, JSON-B, या CDI हैं।
जकार्ता ईई न केवल अधिक व्यापक सॉफ्टवेयर एपीआई प्रदान करता है, बल्कि आगे की परिभाषात्मक परिभाषाओं और नियंत्रण व्युत्क्रमों के उपयोग को सुविधाजनक बनाना चाहिए।
तैनाती की रणनीतिजावा ईई की एक विशिष्ट विशेषता (और मेरी राय में एक बड़ा फायदा) यह है कि यहां प्रस्तावित मॉडल, जिसमें व्यावसायिक तर्क समस्याएं कार्यान्वयन से अलग हो जाती हैं। डेवलपर विशेष रूप से एपीआई के लिए कार्यक्रम करता है, जो तैनाती विरूपण साक्ष्य का हिस्सा नहीं है और आवेदन कंटेनर द्वारा कार्यान्वित किया जाता है।
ये कॉम्पैक्ट परिनियोजन कलाकृतियाँ प्रोग्राम डिलीवरी को सरल और गति प्रदान करती हैं, जिसमें असेंबली, पब्लिशिंग और तैनाती भी शामिल है। वे कंटेनर फ़ाइल सिस्टम के स्तरों के साथ भी संगत हैं, उदाहरण के लिए, डॉकर में। असेंबली प्रक्रिया के दौरान, आपको केवल परिवर्तित तत्वों को फिर से बनाना या फिर से सबमिट करना होगा।
आदर्श रूप से, परिनियोजन कलाकृतियों में केवल व्यावसायिक तर्क और कुछ नहीं होना चाहिए; रनटाइम कार्यान्वयन और संभावित रूप से जोड़े गए तृतीय-पक्ष लायब्रेरीज़ को निचले स्तर पर वितरित किया जाता है, उदाहरण के लिए, कंटेनर असेंबली के पिछले चरण में जोड़े गए एप्लिकेशन सर्वर पुस्तकालयों में।
जकार्ता ईई में, तैनात कलाकृतियों को भी प्रथम श्रेणी की संस्थाओं के रूप में माना जाना चाहिए। शायद एप्लिकेशन द्वारा आवश्यक विनिर्देश के आधार पर रनटाइम वातावरण को और अधिक कसने का अवसर होगा। हालांकि, जकार्ता ईई डेवलपर के व्यावसायिक तर्क और उत्पादकता पर अधिकतम ध्यान देने की उम्मीद करता है, और निष्पादन समय का शोधन पहले से ही माध्यमिक है।
testabilityउपरोक्त सिद्धांतों को लागू करना, विशेष रूप से घोषणात्मक प्रोग्रामिंग और निर्भरता इंजेक्शन को प्राथमिकता देना, हम व्यापार कोड की परीक्षण क्षमता में सुधार कर रहे हैं। इस प्रकार, डेवलपर्स सीधे परीक्षण स्क्रिप्ट में ऑब्जेक्ट्स को त्वरित कर सकते हैं, क्योंकि अब आपको एपीआई कक्षाएं विरासत में प्राप्त करने या असुविधाजनक कार्यक्षमता को कॉल करने की आवश्यकता नहीं है जो आपको पहले अनुकरण करने की आवश्यकता होगी।
हालांकि, जकार्ता ईई में कोड स्तर पर एकीकरण परीक्षण के मानकीकरण को गंभीरता से परिष्कृत करना आवश्यक है, ताकि यह निर्माता पर निर्भर न हो। इससे पहले, यह वही है जो आपको अर्क्विलियन के साथ काम करते समय व्यवहार करना था। वास्तविक परियोजनाओं में, ऐसा मानक उपयोगी होगा, जो आपको केवल परीक्षण परिनियोजन परिदृश्यों को घोषित करने और एक या अधिक घटकों के लिए कार्यक्षमता को कॉल करने की अनुमति देता है। इससे पहले, मैंने लिखा था कि मैं कोड स्तर पर एकीकरण परीक्षण को अत्यंत महत्वपूर्ण नहीं मानता, उदाहरण के लिए, जब अंतर्निर्मित कंटेनरों में कोई एप्लिकेशन चला रहा हो। हालांकि, यदि आप कोड स्तर पर एकीकरण परीक्षणों का मानकीकरण करते हैं, तो इसका स्पष्ट रूप से सकारात्मक प्रभाव पड़ेगा।
निष्कर्षमुझे लगता है कि यह कोई संयोग नहीं है कि वास्तविक परियोजनाओं में जावा ईई एपीआई का व्यापक रूप से उपयोग किया जाता है: इन एपीआई को अच्छी तरह से समझा जाता है और स्पष्ट सिद्धांतों के अनुसार डिजाइन किया जाता है, जिसके लिए यह संभव है कि न केवल एक विनिर्देशन, बल्कि एक संपूर्ण मंच को एकजुट किया जाए। वे आपको एक ही समय में कई विशिष्टताओं का उपयोग करने की अनुमति देते हैं, उसी भावना में निरंतर। यहां, हम कृत्रिम बाधाओं से छुटकारा पाने में कामयाब रहे जो केवल प्रोग्रामर के काम को जटिल करते हैं - इसलिए, मुझे विश्वास है, सभी उद्यम विकास बहुत अधिक सुखद हो गए हैं।