एंटरप्राइज़ एप्लिकेशन अक्सर बड़ी मात्रा में डेटा एकत्र करने, प्रसंस्करण, बदलने और रिपोर्टिंग जैसे कार्यों से निपटते हैं। ये डेटा आम तौर पर किसी विशेष स्थान पर डेटाबेस सर्वर में संग्रहीत किया जाता है और मांग पर पुनर्प्राप्त किया जाता है। एप्लिकेशन डेटाबेस से डेटा को संसाधित करने के लिए जिम्मेदार है और अंत में उन्हें क्लाइंट की खपत के लिए प्रस्तुत करता है। लेकिन, विभिन्न आर्किटेक्चर के बीच डेटा एक्सचेंज को कम करने में शामिल पेचीदगियां वास्तविक चुनौती है जो डेवलपर्स का सामना करती है। समस्या की जड़ एप्लिकेशन को विकसित करने के लिए उपयोग किए गए कोड और डेटा दृढ़ता के लिए उपयोग किए जाने वाले स्टोरेज मॉडल के बीच डेटा आंदोलन के जटिल संबंधों को आसान बनाने में निहित है। संक्षेप में, विचार दो अप्रतिरोध्य मॉडलों के बीच निर्बाध अंतःक्रिया के लिए एक तंत्र बनाना है:जावा भाषा की वस्तु-उन्मुख प्रकृति और संबंधपरक डेटाबेस मॉडल।
डेटाबेस के लिए बुनियादी API
जावा प्लेटफ़ॉर्म में पहले से ही JDBC API के रूप में डेटाबेस सिस्टम के साथ काम करने के लिए मानक API हैं। ये एपीआई डेटाबेस के साथ काम करने में उत्कृष्ट हैं और जावा भाषा से डेटाबेस के साथ आसानी से बातचीत करने के लिए आवश्यक साधन प्रदान करते हैं। लेकिन, समस्या यह है कि जावा एक वस्तु-उन्मुख भाषा है। JDBC डेटाबेस इंटरैक्शन के लिए कोर एपीआई प्रदान करता है और डेटाबेस तालिका की पंक्ति और स्तंभ संरचना को एक इकाई वर्ग में बदलने पर ध्यान केंद्रित नहीं करता है। इसलिए, एपीआई की एक परत की मांग की जाती है जो जेडीबीसी एपीआई के ऊपर काम करती है। दृढ़ता एपीआई, या जेपीए, संचालन की तरलता का लाभ उठाने के लक्ष्य के साथ दो वास्तुशिल्प रूप से भिन्न मॉडलों को कम करता है। एपीआई एक डेटाबेस संबंध तालिका को पीओजेओ के रूप में प्रस्तुत करने में मदद करता है और जावा कोड के माध्यम से एक समान तरीके से व्यवहार किया जा सकता है। कोर JDBC API संचार और डेटाबेस कनेक्शन की पेचीदगियों से निपटने के लिए पृष्ठभूमि में काम करता है जबकि JPA जावा भाषा के ऑब्जेक्ट-ओरिएंटेड कोड के अनुसार व्यवहार करने में सक्षम बनाता है। हालांकि, रिलेशनल डेटाबेस और जावा के बीच डेटा मैपिंग एक आसान काम नहीं है।
जावा पर्सिस्टेंस सपोर्ट
एक विशिष्ट संबंधपरक डेटाबेस में, जानकारी को एक पंक्ति और स्तंभ संरचना में संग्रहीत किया जाता है। एक डेटाबेस सिस्टम और जावा एप्लिकेशन के ऑब्जेक्ट मॉडल के बीच डेटा का आदान-प्रदान मुश्किल है क्योंकि जावा एक एकल इकाई को एक वर्ग के रूप में नामित करता है जो उन पर लागू गुणों और संचालन के एक सेट द्वारा दर्शाया जाता है। इसलिए, दो अलग-अलग आर्किटेक्चर के बीच एक व्यवहारिक बेमेल के अनुरूप होने के लिए, एक जावा प्रोग्रामर को कोड की कई लाइनें लिखनी पड़ती हैं। कोड की ये पंक्तियाँ डेटाबेस तालिका की पंक्ति और स्तंभ डेटा को जावा ऑब्जेक्ट में बदलने में मदद करती हैं। लेकिन, अक्सर कोड की ये पंक्तियाँ बहुत अधिक दोहराव वाली हो जाती हैं, जिसके परिणामस्वरूप स्रोत कोड बॉयलरप्लेट कोड से भर जाता है। यह अवांछनीय है और पुन:प्रयोज्य के मूल वस्तु-उन्मुख सिद्धांत का उल्लंघन करता है। हालांकि चतुर कोड कई प्रतिकूलताओं को कम कर सकते हैं, यह एक आसान समाधान नहीं है। तृतीय-पक्ष समाधानों का उद्भव जावा ऑब्जेक्ट में डेटाबेस डेटा को मैप करने में एक राहत है लेकिन वे मानक नहीं थे। प्रत्येक विक्रेता कार्यान्वयन दूसरे से काफी भिन्न होता है। इसका मतलब यह है कि स्थिति ने जावा प्लेटफॉर्म से ही एक मानक दृढ़ता एपीआई पुस्तकालय की मांग की। इसने जावा पर्सिस्टेंस एपीआई (जेपीए) की शुरुआत की, विशेष रूप से जावा के ऑब्जेक्ट-ओरिएंटेड डोमेन मॉडल और डेटाबेस सिस्टम के बीच की खाई को पाटने के लिए।
स्वामित्व समाधान
समझें कि ऑब्जेक्ट-रिलेशनल सॉल्यूशंस काफी समय से आसपास हैं, जावा भाषा के जन्म से भी पहले से ही डेटिंग कर रहे हैं। उदाहरण के लिए, Oracle का टॉपलिंक उत्पाद वास्तव में स्मॉलटाक के साथ शुरू हुआ, और फिर बाद में जावा में बदल गया। आज, यह OracleAS, WebLogic और OC4J सर्वर का एक हिस्सा है। वास्तव में, दो सबसे लोकप्रिय दृढ़ता एपीआई ओरेकल के टॉपलिंक, वाणिज्यिक डोमेन में एक मालिकाना मानक और ओपन सोर्स कम्युनिटी डोमेन में हाइबरनेट हुआ करते थे। बाद में, हाइबरनेट अधिक लोकप्रिय हो गया और मानक जेपीए पुस्तकालय के निर्माण पर भारी प्रभाव पड़ा।
डेटा मैपर
एक डेटा मैपर मूल रूप से मार्टिन फाउलर द्वारा अपनी पुस्तक एंटरप्राइज़ एप्लिकेशन आर्किटेक्चर के पैटर्न में प्रस्तावित एक वास्तुशिल्प पैटर्न है। , 2003। यह वस्तु-संबंधपरक समस्या को हल करने का एक आंशिक तरीका प्रदान करता है। मैपर एक ऐसी रणनीति बनाने में मदद करता है जो सादे JDBC और एक पूर्ण-कार्यात्मक ऑब्जेक्ट रिलेशनल मैपिंग समाधान के बीच की श्रेणी में आती है। यहां, एप्लिकेशन डेवलपर्स डेटा मैपर विधि का उपयोग करके जावा ऑब्जेक्ट्स में डेटाबेस टेबल को मैप करने के लिए एक कच्ची SQL स्ट्रिंग बनाते हैं। एक लोकप्रिय ढांचा है जो SQL डेटाबेस और जावा ऑब्जेक्ट के बीच मैपिंग की इस तकनीक का उपयोग करता है, जिसे Apache iBatis कहा जाता है। Apache iBatis परियोजना को अब निष्क्रिय घोषित कर दिया गया है। हालांकि, Apache iBatis के मूल निर्माताओं ने इस परियोजना को MyBatis में स्थानांतरित कर दिया है और यह सक्रिय विकास के अधीन है।
MyBatis जैसे डेटा मैपर फ्रेमवर्क का उपयोग करके अन्य ऑब्जेक्ट-रिलेशनल समस्या समाधानों के विपरीत, हम डेटाबेस के साथ SQL लेनदेन पर पूर्ण नियंत्रण रख सकते हैं। यह एक हल्का समाधान है और पूर्ण विकसित ओआरएम ढांचे के ऊपरी हिस्से को वहन नहीं करता है। लेकिन, डेटा मैपर्स के साथ एक समस्या है। ऑब्जेक्ट मॉडल में किए गए किसी भी परिवर्तन का डेटा मॉडल पर प्रभाव पड़ता है। परिणामस्वरूप सीधे SQL कथनों में महत्वपूर्ण परिवर्तन करने पड़ते हैं। ढांचे की न्यूनतम प्रकृति डेवलपर्स को आवश्यकता के अनुसार नए परिवर्तनों और संशोधनों को शामिल करने में मदद करती है। डेटा मैपर विशेष रूप से उस स्थिति में उपयोगी होते हैं जहां हमें न्यूनतम ढांचे, स्पष्ट SQL हैंडलिंग और डेवलपर संशोधन के लिए अधिक नियंत्रण की आवश्यकता होती है।
JDBC
JDBC (जावा डेटाबेस कनेक्टिविटी) Microsoft के ODBC (ऑब्जेक्ट डेटाबेस कनेक्टिविटी) विनिर्देश का जावा-विशिष्ट संस्करण है। ODBC किसी भी भाषा या प्लेटफॉर्म से किसी भी रिलेशनल डेटाबेस को जोड़ने के लिए एक मानक है। JDBC जावा भाषा के संबंध में समान अमूर्तता प्रदान करता है। JDBC डेटाबेस के साथ बातचीत करने के लिए SQL का उपयोग करता है। डेवलपर्स को बैकएंड डेटाबेस के वाक्यात्मक विनिर्देश के अनुसार डीडीएल या डीएमएल प्रश्नों को लिखना चाहिए, लेकिन उन्हें जावा प्रोग्रामिंग मॉडल का उपयोग करके संसाधित करना चाहिए। जावा स्रोत और SQL कथनों के बीच एक तंग युग्मन है। हम कच्चे SQL कथनों का सहारा ले सकते हैं और आवश्यकता के अनुसार उन्हें स्थिर रूप से हेरफेर कर सकते हैं। इसकी स्थिर प्रकृति के कारण, परिवर्तनों को शामिल करना मुश्किल है। इसके अलावा, SQL बोलियाँ एक डेटाबेस विक्रेता से दूसरे में भिन्न होती हैं। JDBC डेटाबेस के लिए हार्डवायर्ड है न कि जावा भाषा के ऑब्जेक्ट मॉडल के लिए। इसलिए, इसके साथ काम करना जल्द ही बोझिल लगता है, खासकर जब जावा स्रोत कोड से डेटाबेस इंटरैक्शन बढ़ता है। हालांकि, जावा में डेटाबेस दृढ़ता के लिए जेडीबीसी प्राथमिक समर्थन है और उच्च स्तरीय ढांचे के लिए आधार बनाता है।
ईजेबी
J2EE के साथ एंटरप्राइज जावा बीन (EJB) ने इकाई बीन के रूप में जावा दृढ़ता के क्षेत्र में कुछ नए बदलाव लाए। यह विचार था कि डेवलपर्स को डेटाबेस दृढ़ता की पेचीदगियों के साथ सीधे हस्तक्षेप करने से अलग किया जाए। इसने एक इंटरफ़ेस-आधारित दृष्टिकोण पेश किया। दृढ़ता, लेनदेन प्रबंधन और व्यावसायिक तर्क प्रतिनिधिमंडल के लिए कार्यान्वयन उत्पन्न करने के लिए एक विशेष बीन कंपाइलर है। इकाई बीन्स को कॉन्फ़िगर करने के लिए विशिष्ट XML परिनियोजन विवरणकों का उपयोग किया गया था। समस्या यह है कि ईजेबी, चीजों को सरल बनाने के बजाय, बहुत अधिक जटिलता को शामिल करता है। परिणामस्वरूप, एंटरप्राइज़ JavaBeans Query Language (EJB QL) की शुरूआत जैसे कई बाद के सुधारों के बावजूद, इसने जल्द ही लोकप्रियता खो दी।
जावा डेटा ऑब्जेक्ट
जेडीओ (जावा डेटा ऑब्जेक्ट) ने ईजेबी दृढ़ता मॉडल के सामने आने वाली समस्या का समाधान करने का प्रयास किया। यह पारदर्शी दृढ़ता के लिए एक एपीआई प्रदान करता है और इसे EJB और J2EE के साथ काम करने के लिए डिज़ाइन किया गया है। JDO ऑब्जेक्ट-ओरिएंटेड डेटाबेस द्वारा अत्यधिक प्रभावित और समर्थित उत्पाद है। पर्सिस्टेंस ऑब्जेक्ट प्लेन जावा ऑब्जेक्ट हैं जिन्हें किसी विशेष वर्ग या इंटरफ़ेस को लागू करने के लिए डेवलपर की आवश्यकता नहीं होती है। ऑब्जेक्ट दृढ़ता विनिर्देशों को आम तौर पर एक्सएमएल मेटाफाइल में परिभाषित किया जाता है। समर्थित क्वेरी भाषाएँ प्रकृति में वस्तु-उन्मुख हैं। कई अच्छी विशेषताओं के बावजूद, JDO विनिर्देश डेवलपर समुदाय के बीच अधिक स्वीकृति प्राप्त नहीं कर सका।
जावा पर्सिस्टेंस एपीआई
वाणिज्यिक डोमेन और ओपन सोर्स डोमेन दोनों में कई स्वामित्व दृढ़ता ढांचे थे। हाइबरनेट और टॉपलिंक जैसे ढांचे आवेदन को काफी अच्छी तरह से पूरा करने लगते थे। नतीजतन, जेपीए नामक एक मानक दृढ़ता मॉडल बनाने के लिए हाइबरनेट को प्राथमिक आधार के रूप में चुना गया था।
जेपीए एक मानक हल्का जावा दृढ़ता ढांचा है जो पीओजेओ का उपयोग करके ऑब्जेक्ट रिलेशनल मैपिंग बनाने में मदद करता है। जेपीए एक स्केलेबल उद्यम अनुप्रयोग में दृढ़ता को एकीकृत करने में भी मदद करता है। इसका उपयोग करना आसान है क्योंकि केवल कुछ ही वर्ग हैं जिन्हें जेपीए दृढ़ता मॉडल का उपयोग करने में रुचि रखने वाले एप्लिकेशन के संपर्क में आने की आवश्यकता है। POJO का उपयोग शायद JPA का सबसे पेचीदा पहलू है। इसका मतलब है कि वस्तु के बारे में कुछ खास नहीं है; जो इसे टिकाऊ बनाता है। ऑब्जेक्ट-रिलेशनल मैपिंग मेटाडेटा संचालित है। यह या तो कोड के भीतर या बाहरी रूप से एनोटेशन का उपयोग करके किया जा सकता है। एक्सएमएल का उपयोग करके।
जेपीए के लगातार एपीआई लगातार वस्तु से एक अलग परत के रूप में मौजूद हैं। व्यावसायिक तर्क आम तौर पर एपीआई को आमंत्रित करता है और उन पर काम करने के लिए लगातार वस्तु को पास करता है। हालांकि एप्लिकेशन को लगातार एपीआई के बारे में पता है, लेकिन लगातार वस्तु, पीओजेओ होने के नाते, इसकी दृढ़ता क्षमता से पूरी तरह अनजान है।
निष्कर्ष
इस लेख ने जेपीए की शुरुआत से पहले उपलब्ध कुछ मालिकाना समाधानों का अवलोकन दिया, जैसे डेटा मैपर, जेडीबीसी, और ईजेबी। विचार यह है कि जेपीए के निर्माण के लिए क्या कारण है, और इसके पूर्ववर्ती की लगातार तकनीक के बारे में थोड़ा सा अंतर्दृष्टि देना है। बने रहें; बाद के लेख जेपीए एपीआई के अधिक विशिष्ट पहलुओं में तल्लीन हैं।
