IGNOU MCS-051 Solved Question Paper PDF Download

Q1. (a) What is JSP ? How does JSP differ from Servlets ? Explain the life-cycle of servlet with a suitable diagram. (10)

Ans.

जावा सर्वर पेजेज (JSP)

JSP (जावा सर्वर पेजेज) एक सर्वर-साइड प्रोग्रामिंग तकनीक है जो डायनामिक, प्लेटफॉर्म-स्वतंत्र वेब पेज बनाने में मदद करती है। यह डेवलपर्स को HTML या XML कोड के भीतर जावा कोड एम्बेड करने की अनुमति देती है। जब कोई क्लाइंट किसी JSP पेज का अनुरोध करता है, तो वेब सर्वर (जैसे अपाचे टॉमकैट) पहले JSP को एक सर्वलेट में अनुवादित और संकलित करता है, और फिर उस सर्वलेट को निष्पादित करता है। इसका मुख्य उद्देश्य प्रेजेंटेशन लॉजिक (HTML/CSS/JS) को बिजनेस लॉजिक (जावा कोड) से अलग करना है।

JSP और सर्वलेट्स के बीच अंतर

• उद्देश्य और उपयोग: JSP मुख्य रूप से प्रेजेंटेशन लेयर (View) के लिए डिज़ाइन किया गया है, जिससे HTML पेज बनाना आसान हो जाता है। सर्वलेट कंट्रोलर (Controller) के रूप में कार्य करने के लिए अधिक उपयुक्त है, जो अनुरोधों को संसाधित करता है और व्यावसायिक तर्क को निष्पादित करता है।
• कोडिंग में आसानी: वेब डिजाइनरों के लिए JSP लिखना आसान है क्योंकि यह HTML जैसा दिखता है जिसमें जावा कोड के स्निपेट होते हैं। सर्वलेट में, HTML को जावा `out.println()` स्टेटमेंट के भीतर लिखना पड़ता है, जो जटिल और बनाए रखने में कठिन होता है।
• अनुवाद: JSP को पहले उपयोग में सर्वलेट में अनुवादित करने की आवश्यकता होती है, इसलिए पहले अनुरोध में थोड़ी देरी हो सकती है। सर्वलेट पहले से ही संकलित जावा क्लास हैं, इसलिए वे थोड़ा तेज हो सकते हैं।
• रखरखाव: JSP में प्रेजेंटेशन और लॉजिक का पृथक्करण बेहतर रखरखाव की अनुमति देता है। सर्वलेट में HTML और जावा कोड का मिश्रण इसे बनाए रखना कठिन बना सकता है।

सर्वलेट का जीवनचक्र (Life-cycle of Servlet)

एक सर्वलेट का जीवनचक्र सर्वलेट कंटेनर द्वारा प्रबंधित किया जाता है। इसके तीन मुख्य चरण होते हैं: इनिशियलाइज़ेशन, सर्विसिंग और डिस्ट्रक्शन।

1. इनिशियलाइज़ेशन (Initialization): यह तब होता है जब कंटेनर पहली बार सर्वलेट को मेमोरी में लोड करता है।
   • कंटेनर सर्वलेट क्लास को लोड करता है।
   • कंटेनर सर्वलेट का एक इंस्टेंस बनाता है।
   • कंटेनर `init()` मेथड को कॉल करता है। यह मेथड सर्वलेट के पूरे जीवनकाल में केवल एक बार कॉल की जाती है। इसका उपयोग वन-टाइम कॉन्फ़िगरेशन के लिए किया जाता है, जैसे डेटाबेस कनेक्शन स्थापित करना।
2. सर्विसिंग (Servicing): सर्वलेट के इनिशियलाइज़ होने के बाद, यह अनुरोधों को संसाधित करने के लिए तैयार होता है।
   • प्रत्येक क्लाइंट अनुरोध के लिए, कंटेनर `service()` मेथड को कॉल करता है।
   • `service()` मेथड अनुरोध के प्रकार (GET, POST, आदि) की जांच करता है और संबंधित मेथड (`doGet()`, `doPost()`, आदि) को कॉल करता है।
   • यह चरण समवर्ती (concurrent) होता है, जिसका अर्थ है कि एक ही सर्वलेट इंस्टेंस एक साथ कई अनुरोधों को संभाल सकता है, प्रत्येक एक अलग थ्रेड में।
3. डिस्ट्रक्शन (Destruction): यह तब होता है जब कंटेनर सर्वलेट को मेमोरी से हटाता है (उदाहरण के लिए, जब सर्वर बंद हो रहा हो)।
   • कंटेनर `destroy()` मेथड को कॉल करता है। यह मेथड भी सर्वलेट के जीवनकाल में केवल एक बार कॉल की जाती है।
   • इसका उपयोग संसाधनों को मुक्त करने के लिए किया जाता है, जैसे डेटाबेस कनेक्शन बंद करना या फाइलें सहेजना।

सर्वलेट जीवनचक्र का चित्र:

चित्र में, सर्वलेट लोड होता है और `init()` के माध्यम से इनिशियलाइज़ होता है। फिर यह `service()` मेथड के माध्यम से कई क्लाइंट अनुरोधों को संभालता है। अंत में, जब सर्वर बंद होता है, तो `destroy()` मेथड को कॉल किया जाता है और सर्वलेट अनलोड हो जाता है। (b) Describe JDBC. Also discuss its utility. List and explain the types of JDBC drivers. (10)

Ans.

JDBC (जावा डेटाबेस कनेक्टिविटी)

JDBC (Java Database Connectivity) एक जावा एपीआई (एप्लिकेशन प्रोग्रामिंग इंटरफ़ेस) है जो जावा एप्लिकेशन को विभिन्न प्रकार के डेटाबेस के साथ इंटरैक्ट करने के लिए एक मानक तरीका प्रदान करता है। यह डेटाबेस-स्वतंत्र कनेक्टिविटी को सक्षम बनाता है, जिसका अर्थ है कि आप अंतर्निहित डेटाबेस को बदले बिना एक ही एप्लिकेशन कोड का उपयोग कर सकते हैं, जब तक कि उस डेटाबेस के लिए JDBC ड्राइवर उपलब्ध हो।

JDBC की उपयोगिता (Utility of JDBC)

JDBC की उपयोगिता एंटरप्राइज-स्तरीय एप्लिकेशन बनाने में निहित है जिन्हें डेटा संग्रहीत करने, पुनर्प्राप्त करने, अपडेट करने और प्रबंधित करने की आवश्यकता होती है। इसकी मुख्य उपयोगिताएँ हैं:

• डेटाबेस स्वतंत्रता: यह डेवलपर्स को एक मानक एपीआई का उपयोग करके कोड लिखने की अनुमति देता है जो Oracle, MySQL, SQL Server, और PostgreSQL जैसे कई डेटाबेस के साथ काम करता है।
• एंटरप्राइज एप्लिकेशन: यह वेब एप्लिकेशन, डेस्कटॉप एप्लिकेशन और सर्वर-साइड घटकों के लिए आवश्यक है जिन्हें लगातार डेटा बनाए रखने की आवश्यकता होती है।
• सरलीकृत डेटा एक्सेस: यह कनेक्शन स्थापित करने, SQL स्टेटमेंट निष्पादित करने और परिणामों को संसाधित करने के लिए एक सीधा तंत्र प्रदान करता है।
• लेनदेन प्रबंधन: JDBC लेनदेन के प्रबंधन के लिए समर्थन प्रदान करता है, जिससे डेटा की अखंडता सुनिश्चित होती है।

JDBC ड्राइवरों के प्रकार

एक JDBC ड्राइवर एक सॉफ्टवेयर घटक है जो जावा एप्लिकेशन को डेटाबेस के साथ इंटरैक्ट करने में सक्षम बनाता है। चार मुख्य प्रकार के JDBC ड्राइवर हैं:

1. टाइप 1: JDBC-ODBC ब्रिज ड्राइवर
   • यह ड्राइवर JDBC कॉल्स को ODBC (ओपन डेटाबेस कनेक्टिविटी) कॉल्स में अनुवादित करता है।
   • यह क्लाइंट मशीन पर ODBC ड्राइवर को स्थापित करने की आवश्यकता होती है।
   • यह पूरी तरह से जावा में नहीं लिखा गया है और प्लेटफॉर्म पर निर्भर है। प्रदर्शन संबंधी चिंताओं और निर्भरता के कारण अब इसका उपयोग कम ही किया जाता है।
2. टाइप 2: नेटिव-एपीआई ड्राइवर
   • यह ड्राइवर JDBC कॉल्स को डेटाबेस के लिए विशिष्ट नेटिव एपीआई कॉल्स में परिवर्तित करता है।
   • यह टाइप 1 से बेहतर प्रदर्शन प्रदान करता है क्योंकि यह ODBC परत को बायपास करता है।
   • यह आंशिक रूप से जावा में और आंशिक रूप से नेटिव कोड में लिखा गया है, इसलिए यह प्लेटफॉर्म पर निर्भर है और क्लाइंट पर विशिष्ट लाइब्रेरी की आवश्यकता होती है।
3. टाइप 3: नेटवर्क-प्रोटोकॉल ड्राइवर
   • यह एक शुद्ध जावा ड्राइवर है जो एक मिडलवेयर सर्वर के साथ संचार करता है।
   • मिडलवेयर सर्वर फिर JDBC कॉल्स को डेटाबेस-विशिष्ट प्रोटोकॉल में अनुवादित करता है।
   • यह लचीला है क्योंकि क्लाइंट पर किसी भी विक्रेता-विशिष्ट लाइब्रेरी की आवश्यकता नहीं होती है, लेकिन इसके लिए एक अतिरिक्त मिडलवेयर परत की आवश्यकता होती है।
4. टाइप 4: थिन ड्राइवर (नेटिव-प्रोटोकॉल ड्राइवर)
   • यह भी एक शुद्ध जावा ड्राइवर है, लेकिन यह सीधे डेटाबेस के साथ उसके नेटिव प्रोटोकॉल का उपयोग करके संचार करता है।
   • यह सबसे अधिक इस्तेमाल किया जाने वाला ड्राइवर प्रकार है क्योंकि यह प्लेटफॉर्म-स्वतंत्र है, उत्कृष्ट प्रदर्शन प्रदान करता है, और किसी अतिरिक्त मिडलवेयर या क्लाइंट-साइड इंस्टॉलेशन की आवश्यकता नहीं होती है।
   • प्रत्येक डेटाबेस विक्रेता अपना टाइप 4 ड्राइवर प्रदान करता है।

(c) What is EJB ? Describe the goals of EJB. Explain any four services offered by EJB. (10)

Ans.

EJB (एंटरप्राइज जावाबीन्स)

एंटरप्राइज जावाबीन्स (EJB) एक प्रबंधित, सर्वर-साइड कंपोनेंट आर्किटेक्चर है जो बड़े पैमाने पर, वितरित, और लेन-देन योग्य एंटरप्राइज एप्लिकेशन बनाने के लिए उपयोग किया जाता है। EJB कंपोनेंट्स, जिन्हें “बीन्स” कहा जाता है, एक EJB कंटेनर के भीतर चलते हैं, जो एप्लिकेशन सर्वर का हिस्सा होता है। यह कंटेनर बीन्स के लिए जीवनचक्र प्रबंधन, सुरक्षा, लेन-देन और समवर्तीता जैसी निम्न-स्तरीय सेवाएँ प्रदान करता है, जिससे डेवलपर्स व्यावसायिक तर्क पर ध्यान केंद्रित कर सकते हैं।

EJB के लक्ष्य (Goals of EJB)

EJB का प्राथमिक लक्ष्य जटिल एंटरप्राइज एप्लिकेशन के विकास को सरल बनाना है। इसके मुख्य लक्ष्य हैं:

• सरलीकृत विकास: डेवलपर्स को सिस्टम-स्तरीय चिंताओं (जैसे लेन-देन प्रबंधन, सुरक्षा) से मुक्त करके, EJB उन्हें व्यावसायिक समस्याओं को हल करने पर ध्यान केंद्रित करने की अनुमति देता है।
• कंपोनेंट-आधारित विकास: यह पुन: प्रयोज्य और मॉड्यूलर घटकों के निर्माण को प्रोत्साहित करता है।
• पोर्टेबिलिटी: EJB एप्लिकेशन को किसी भी Java EE-संगत एप्लिकेशन सर्वर पर बिना किसी कोड परिवर्तन के तैनात किया जा सकता है।
• स्केलेबिलिटी: EJB कंटेनर स्वचालित रूप से संसाधन प्रबंधन (जैसे इंस्टेंस पूलिंग) और लोड बैलेंसिंग को संभालता है, जिससे एप्लिकेशन बड़ी संख्या में उपयोगकर्ताओं को सेवा प्रदान कर सकता है।

EJB द्वारा प्रदान की जाने वाली चार सेवाएँ

EJB कंटेनर डेवलपर्स के लिए कई महत्वपूर्ण सेवाएँ प्रदान करता है:

1. लेन-देन प्रबंधन (Transaction Management): EJB कंटेनर स्वचालित रूप से लेन-देन की सीमाओं को प्रबंधित कर सकता है।
   • कंटेनर-प्रबंधित लेन-देन (CMT): यह डिफ़ॉल्ट तरीका है, जहाँ कंटेनर स्वचालित रूप से लेन-देन शुरू करता है, प्रतिबद्ध करता है या रोलबैक करता है। डेवलपर केवल एनोटेशन या परिनियोजन डिस्क्रिप्टर का उपयोग करके लेन-देन संबंधी विशेषताओं को निर्दिष्ट करते हैं।
   • बीन-प्रबंधित लेन-देन (BMT): यहाँ, बीन डेवलपर स्पष्ट रूप से अपने कोड में लेन-देन को नियंत्रित करता है, लेकिन यह कम आम है।
2. सुरक्षा (Security): EJB घोषणात्मक और प्रोग्रामेटिक सुरक्षा दोनों प्रदान करता है।
   • घोषणात्मक सुरक्षा: डेवलपर एनोटेशन या परिनियोजन डिस्क्रिप्टर का उपयोग करके यह निर्दिष्ट कर सकते हैं कि कौन सी भूमिकाएँ (जैसे ‘व्यवस्थापक’, ‘उपयोगकर्ता’) किसी बीन या उसके तरीकों तक पहुँच सकती हैं। कंटेनर इस पहुँच को लागू करता है।
   • प्रोग्रामेटिक सुरक्षा: बीन व्यावसायिक तर्क के भीतर उपयोगकर्ता की पहचान और भूमिका की जाँच कर सकता है।
3. समवर्तीता प्रबंधन (Concurrency Management): एंटरप्राइज एप्लिकेशन में, कई क्लाइंट एक ही समय में घटकों तक पहुँच सकते हैं। EJB कंटेनर स्वचालित रूप से समवर्ती पहुँच का प्रबंधन करता है, जिससे डेटा भ्रष्टाचार को रोका जा सकता है। यह इंस्टेंस पूलिंग और सिंक्रोनाइज़ेशन को संभालता है, जिससे डेवलपर्स को जटिल मल्टी-थ्रेडिंग कोड लिखने की आवश्यकता नहीं होती है।
4. जीवनचक्र प्रबंधन (Lifecycle Management): कंटेनर EJB इंस्टेंस बनाने, प्रबंधित करने और नष्ट करने के लिए जिम्मेदार है। उदाहरण के लिए, स्टेटलेस सेशन बीन्स के लिए, कंटेनर प्रदर्शन को अनुकूलित करने के लिए इंस्टेंस का एक पूल बनाए रखता है। यह बीन्स के पैसिवेशन (डिस्क पर सहेजना) और एक्टिवेशन (मेमोरी में वापस लाना) को भी संभाल सकता है।

(d) Explain JNDI authentication, with the help of an example. (10)

Ans.

JNDI प्रमाणीकरण (JNDI Authentication)

JNDI (Java Naming and Directory Interface) एक जावा एपीआई है जो एप्लिकेशन को विभिन्न प्रकार की नेमिंग और डायरेक्टरी सेवाओं (जैसे LDAP, DNS, RMI रजिस्ट्री) से डेटा और ऑब्जेक्ट्स को एक एकीकृत तरीके से खोजने और एक्सेस करने की अनुमति देता है।

JNDI का उपयोग केवल ऑब्जेक्ट्स को खोजने के लिए ही नहीं, बल्कि डायरेक्टरी सेवा के खिलाफ उपयोगकर्ताओं को प्रमाणित करने के लिए भी किया जा सकता है। JNDI प्रमाणीकरण प्रक्रिया में, एक क्लाइंट अपनी क्रेडेंशियल्स (जैसे उपयोगकर्ता नाम और पासवर्ड) डायरेक्टरी सेवा को प्रदान करता है। डायरेक्टरी सेवा इन क्रेडेंशियल्स को मान्य करती है, और यदि वे सही हैं, तो क्लाइंट को डायरेक्टरी तक पहुँच प्रदान की जाती है। यदि क्रेडेंशियल्स अमान्य हैं, तो एक `AuthenticationException` फेंकी जाती है।

यह आमतौर पर LDAP (लाइटवेट डायरेक्टरी एक्सेस प्रोटोकॉल) सर्वर के साथ उपयोग किया जाता है, जहाँ उपयोगकर्ता खाते और समूह संग्रहीत होते हैं। प्रमाणीकरण प्रक्रिया JNDI `InitialDirContext` को कॉन्फ़िगर करते समय होती है।

प्रमाणीकरण प्रक्रिया:

1. एक `Hashtable` या `Properties` ऑब्जेक्ट बनाया जाता है ताकि JNDI संदर्भ के लिए कॉन्फ़िगरेशन सेट किया जा सके।
2. निम्नलिखित महत्वपूर्ण गुण सेट किए जाते हैं:
   • `Context.INITIAL_CONTEXT_FACTORY` : JNDI सेवा प्रदाता के लिए फैक्ट्री क्लास (जैसे, LDAP के लिए `com.sun.jndi.ldap.LdapCtxFactory`)।
   • `Context.PROVIDER_URL` : डायरेक्टरी सर्वर का URL (जैसे, `ldap://localhost:389`)।
   • `Context.SECURITY_AUTHENTICATION` : प्रमाणीकरण का प्रकार, आमतौर पर `”simple”` (उपयोगकर्ता नाम/पासवर्ड के लिए)।
   • `Context.SECURITY_PRINCIPAL` : उपयोगकर्ता का नाम या विशिष्ट नाम (Distinguished Name – DN), जैसे `”cn=admin,dc=example,dc=com”`।
   • `Context.SECURITY_CREDENTIALS` : उपयोगकर्ता का पासवर्ड।
3. इन गुणों का उपयोग करके `InitialDirContext` का एक नया उदाहरण बनाया जाता है।
4. यदि प्रदान की गई क्रेडेंशियल्स सही हैं, तो संदर्भ सफलतापूर्वक बनाया जाता है। यदि वे गलत हैं, तो JNDI प्रदाता एक `AuthenticationException` फेंकता है।

उदाहरण कोड:

यह उदाहरण दिखाता है कि LDAP सर्वर के खिलाफ उपयोगकर्ता को कैसे प्रमाणित किया जाए। “`java import javax.naming.*; import javax.naming.directory.*; import java.util.Hashtable; public class JndiAuthExample { public static void main(String[] args) { // JNDI कॉन्फ़िगरेशन के लिए गुण सेट करें Hashtable env = new Hashtable<>(); env.put(Context.INITIAL_CONTEXT_FACTORY, “com.sun.jndi.ldap.LdapCtxFactory”); env.put(Context.PROVIDER_URL, “ldap://ldap.example.com:389”); // प्रमाणीकरण के लिए गुण env.put(Context.SECURITY_AUTHENTICATION, “simple”); env.put(Context.SECURITY_PRINCIPAL, “uid=testuser,ou=people,dc=example,dc=com”); // उपयोगकर्ता का DN env.put(Context.SECURITY_CREDENTIALS, “userpassword123”); // उपयोगकर्ता का पासवर्ड DirContext ctx = null; try { // प्रमाणीकरण का प्रयास करने के लिए संदर्भ बनाने की कोशिश करें ctx = new InitialDirContext(env); System.out.println(“Authentication successful!”); // यहाँ आप डायरेक्टरी के साथ आगे का काम कर सकते हैं // … } catch (AuthenticationException e) { System.err.println(“Authentication failed: ” + e.getMessage()); } catch (NamingException e) { System.err.println(“An error occurred: ” + e.getMessage()); } finally { if (ctx != null) { try { ctx.close(); } catch (NamingException e) { // क्लोजिंग त्रुटि को अनदेखा करें } } } } } “` इस उदाहरण में, `new InitialDirContext(env)` बनाने का प्रयास ही प्रमाणीकरण का प्रयास है। यदि यह लाइन बिना किसी अपवाद के निष्पादित होती है, तो प्रमाणीकरण सफल होता है। अन्यथा, एक `AuthenticationException` पकड़ी जाती है।

Q2. (a) Differentiate between the following : 5+5 (i) Non-validating parser and Validating parser (ii) Session Bean and Entity Bean

Ans.

(i) नॉन-वैलिडेटिंग पार्सर और वैलिडेटिंग पार्सर (Non-validating parser and Validating parser)

नॉन-वैलिडेटिंग पार्सर:

• कार्य: एक नॉन-वैलिडेटिंग पार्सर केवल यह जांचता है कि XML दस्तावेज़ सुगठित (well-formed) है या नहीं। सुगठित का अर्थ है कि दस्तावेज़ XML के मूल सिंटैक्स नियमों का पालन करता है, जैसे कि सभी टैग ठीक से बंद हैं और नेस्टिंग सही है।
• सत्यापन: यह दस्तावेज़ को DTD (डॉक्यूमेंट टाइप डेफिनिशन) या XML स्कीमा के खिलाफ मान्य नहीं करता है। यह दस्तावेज़ की संरचना या डेटा प्रकारों की शुद्धता की जाँच नहीं करता है।
• प्रदर्शन: चूँकि यह सत्यापन नहीं करता है, यह एक वैलिडेटिंग पार्सर की तुलना में तेज होता है।
• उपयोग: इसका उपयोग तब किया जाता है जब आप आश्वस्त होते हैं कि XML डेटा सही है या जब प्रदर्शन महत्वपूर्ण है और सख्त सत्यापन की आवश्यकता नहीं है।

वैलिडेटिंग पार्सर:

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

(ii) सेशन बीन और एंटिटी बीन (Session Bean and Entity Bean)

सेशन बीन (Session Bean):

• उद्देश्य: यह एक विशिष्ट क्लाइंट के लिए व्यावसायिक तर्क (business logic) या प्रक्रियाओं का प्रतिनिधित्व करता है। यह एक क्रिया या वर्कफ़्लो को एनकैप्सुलेट करता है, जैसे “शॉपिंग कार्ट का प्रबंधन करना” या “ऋण आवेदन संसाधित करना”।
• स्थायित्व (Persistence): सेशन बीन्स स्वाभाविक रूप से स्थायी नहीं होते हैं। वे सीधे डेटाबेस में डेटा का प्रतिनिधित्व नहीं करते हैं। वे डेटा एक्सेस ऑब्जेक्ट्स (DAOs) या एंटिटी बीन्स का उपयोग करके स्थायी डेटा के साथ इंटरैक्ट कर सकते हैं।
• जीवनकाल: इनका जीवनकाल छोटा होता है, जो आमतौर पर एक क्लाइंट सत्र तक ही सीमित होता है।
• प्रकार:
  • स्टेटलेस (Stateless): क्लाइंट के साथ कोई संवादी स्थिति (conversational state) नहीं बनाए रखता है। कोई भी इंस्टेंस किसी भी क्लाइंट को सेवा दे सकता है, जिससे यह स्केलेबल और कुशल हो जाता है।
  • स्टेटफुल (Stateful): एक विशिष्ट क्लाइंट के लिए संवादी स्थिति बनाए रखता है। उदाहरण: एक शॉपिंग कार्ट।

एंटिटी बीन (Entity Bean):

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

नोट: आधुनिक Java EE (अब जकार्ता EE) में, एंटिटी बीन्स को बड़े पैमाने पर JPA (जावा पर्सिस्टेंस एपीआई) एंटिटीज द्वारा प्रतिस्थापित कर दिया गया है, जो अधिक सरल और शक्तिशाली हैं। (b) Describe the use of the following implicit objects of JSP, with the help of an example code : (10) (i) The out object (ii) The pageContext object (iii) The config object (iv) The page object (v) The exception object

Ans. JSP नौ अंतर्निहित (implicit) ऑब्जेक्ट्स प्रदान करता है जिनका उपयोग डेवलपर्स सीधे अपने JSP पेजों में कर सकते हैं बिना उन्हें घोषित किए। ये ऑब्जेक्ट्स सर्वलेट कंटेनर द्वारा प्रदान किए जाते हैं।

(i) The out object

• विवरण: `out` ऑब्जेक्ट `javax.servlet.jsp.JspWriter` क्लास का एक उदाहरण है। इसका उपयोग क्लाइंट के ब्राउज़र पर भेजे जाने वाले रिस्पांस स्ट्रीम में टेक्स्ट या HTML कंटेंट लिखने के लिए किया जाता है।
• उदाहरण: “`jsp <% out.println(“Hello, World!”); out.println(” “); out.println(“Current date is: ” + new java.util.Date()); %> “`

(ii) The pageContext object

• विवरण: `pageContext` ऑब्जेक्ट `javax.servlet.jsp.PageContext` क्लास का एक उदाहरण है। यह एक केंद्रीय बिंदु के रूप में कार्य करता है जहाँ से अन्य सभी अंतर्निहित ऑब्जेक्ट्स तक पहुँचा जा सकता है। यह विभिन्न स्कोप (page, request, session, application) में एट्रिब्यूट्स को प्रबंधित करने के लिए तरीके भी प्रदान करता है।
• उदाहरण: “`jsp <% // सेशन स्कोप में एक एट्रिब्यूट सेट करना pageContext.setAttribute(“username”, “admin”, PageContext.SESSION_SCOPE);

  // रिक्वेस्ट ऑब्जेक्ट तक पहुँचना और प्रिंट करना out.println(“Context Path: ” + pageContext.getRequest().getContextPath()); %> “`

(iii) The config object

• विवरण: `config` ऑब्जेक्ट `javax.servlet.ServletConfig` क्लास का एक उदाहरण है। यह JSP पेज के लिए इनिशियलाइज़ेशन पैरामीटर्स तक पहुँच प्रदान करता है, जो `web.xml` फ़ाइल में परिभाषित होते हैं।
• `web.xml` में उदाहरण कॉन्फ़िगरेशन: “`xml MyJSP /myPage.jsp adminEmailadmin@example.com “`
• JSP में उपयोग का उदाहरण: “`jsp <% String email = config.getInitParameter(“adminEmail”); out.println(“Administrator Email: ” + email); %> “`

(iv) The page object

• विवरण: `page` ऑब्जेक्ट वर्तमान JSP पेज के जेनरेटेड सर्वलेट इंस्टेंस का एक संदर्भ (`this`) है। इसका प्रकार `java.lang.Object` होता है। JSP प्रोग्रामर द्वारा इसका उपयोग सीधे बहुत कम किया जाता है, लेकिन यह उस सर्वलेट को संदर्भित करता है जो वर्तमान पेज को निष्पादित कर रहा है।
• उदाहरण: “`jsp <%– यह जेनरेटेड सर्वलेट क्लास का नाम प्रिंट करेगा –%> The class for this page is: <%= page.getClass().getName() %> “`

(v) The exception object

• विवरण: `exception` ऑब्जेक्ट `java.lang.Throwable` क्लास का एक उदाहरण है। यह ऑब्जेक्ट केवल उन JSP पेजों में उपलब्ध होता है जिन्हें त्रुटि पेज (error page) के रूप में नामित किया गया है। एक पेज को `page` डायरेक्टिव में `isErrorPage=”true”` सेट करके एक त्रुटि पेज बनाया जाता है। यह उस त्रुटि या अपवाद को धारण करता है जो किसी अन्य JSP पेज में हुआ था।
• त्रुटि फेंकने वाला पेज (main.jsp): “`jsp <%@ page errorPage=”error.jsp” %> <% int result = 10 / 0; // यह एक ArithmeticException फेंकेगा %> “`
• त्रुटि पेज (error.jsp): “`jsp <%@ page isErrorPage=”true” %>
  

  An error occurred!

  Error Message: <%= exception.getMessage() %>

  Please contact support.

  “`

Q3. (a) Compare the life-cycle of stateless session bean and stateful session bean, with the help of a block diagram for each. (10)

Ans.

स्टेटलेस और स्टेटफुल सेशन बीन के जीवनचक्र की तुलना

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

स्टेटलेस सेशन बीन (Stateless Session Bean) का जीवनचक्र

स्टेटलेस सेशन बीन्स किसी विशिष्ट क्लाइंट के लिए कोई संवादी स्थिति (conversational state) नहीं रखते हैं। इसका जीवनचक्र बहुत सरल होता है और प्रदर्शन के लिए अनुकूलित होता है।

1. Does Not Exist: प्रारंभ में, बीन इंस्टेंस मौजूद नहीं होता है।
2. Method-Ready Pool: जब क्लाइंट एक मेथड को कॉल करता है, तो कंटेनर पूल से एक उपलब्ध इंस्टेंस लेता है या यदि आवश्यक हो तो एक नया बनाता है (`new` और `PostConstruct` एनोटेशन वाले मेथड को कॉल करके)।
3. Method Execution: बीन पर मेथड निष्पादित होती है। इस समय के दौरान, इंस्टेंस एक क्लाइंट के लिए आरक्षित होता है।
4. Return to Pool: मेथड पूरी होने के बाद, बीन इंस्टेंस तुरंत किसी अन्य क्लाइंट द्वारा उपयोग के लिए पूल में वापस आ जाता है। यह किसी भी क्लाइंट-विशिष्ट डेटा को बनाए नहीं रखता है।

इस मॉडल के कारण, कंटेनर कम संख्या में इंस्टेंस के साथ बड़ी संख्या में क्लाइंट्स की सेवा कर सकता है, जिससे यह अत्यधिक स्केलेबल हो जाता है। ब्लॉक डायग्राम: स्टेटलेस सेशन बीन जीवनचक्र

स्टेटफुल सेशन बीन (Stateful Session Bean) का जीवनचक्र

स्टेटफुल सेशन बीन्स एक विशिष्ट क्लाइंट के लिए संवादी स्थिति बनाए रखते हैं। इसका जीवनचक्र अधिक जटिल होता है क्योंकि यह एक क्लाइंट से बंधा होता है।

1. Does Not Exist: प्रारंभ में, बीन इंस्टेंस मौजूद नहीं होता है।
2. Creation: एक क्लाइंट एक स्टेटफुल बीन का अनुरोध करता है। कंटेनर एक नया इंस्टेंस बनाता है (`new` और `PostConstruct`) और इसे उस विशिष्ट क्लाइंट को समर्पित करता है।
3. Ready State: बीन अब क्लाइंट के साथ अपनी संवादी स्थिति बनाए रखते हुए, मेथड कॉल्स प्राप्त करने के लिए तैयार है। यह एक क्लाइंट के साथ कई इंटरैक्शन के दौरान इस स्थिति में रहता है।
4. Passivation: यदि बीन कुछ समय के लिए निष्क्रिय रहता है और कंटेनर को संसाधनों को बचाने की आवश्यकता होती है, तो वह बीन को “पैसिवेट” कर सकता है। बीन की स्थिति को सेकेंडरी स्टोरेज (जैसे डिस्क) में सीरियलाइज किया जाता है, और इंस्टेंस को मेमोरी से हटा दिया जाता है। `@PrePassivate` एनोटेशन वाला मेथड इस घटना से पहले कॉल किया जाता है।
5. Activation: जब क्लाइंट पैसिवेटेड बीन के साथ फिर से इंटरैक्ट करता है, तो कंटेनर उसकी स्थिति को सेकेंडरी स्टोरेज से पुनर्स्थापित करके बीन को “एक्टिवेट” करता है। `@PostActivate` एनोटेशन वाला मेथड इस घटना के बाद कॉल किया जाता है।
6. Removal: जब क्लाइंट सत्र समाप्त हो जाता है या स्पष्ट रूप से बीन को हटा देता है (`@Remove` एनोटेशन वाले मेथड को कॉल करके), तो `@PreDestroy` मेथड को कॉल किया जाता है और बीन इंस्टेंस को नष्ट कर दिया जाता है।

ब्लॉक डायग्राम: स्टेटफुल सेशन बीन जीवनचक्र

तुलना सारणी

पहलू

स्टेटलेस सेशन बीन

स्टेटफुल सेशन बीन

स्टेट (State)

कोई क्लाइंट-विशिष्ट स्टेट नहीं रखता है।

एकल क्लाइंट के लिए संवादी स्टेट रखता है।

जीवनकाल

एक मेथड कॉल तक सीमित।

एक क्लाइंट सत्र तक सीमित।

पूलिंग

प्रदर्शन के लिए इंस्टेंस का पूल बनाया जाता है।

पूल नहीं किया जा सकता क्योंकि प्रत्येक इंस्टेंस एक क्लाइंट से बंधा होता है।

प्रदर्शन

संसाधन पूलिंग के कारण उच्च प्रदर्शन और स्केलेबिलिटी।

प्रत्येक क्लाइंट के लिए एक इंस्टेंस की आवश्यकता के कारण कम स्केलेबल।

पैसिवेशन

लागू नहीं होता।

संसाधनों को बचाने के लिए निष्क्रिय बीन्स को पैसिवेट किया जा सकता है।

उपयोग का मामला

एकल, परमाणु संचालन जैसे डेटाबेस से डेटा पुनर्प्राप्त करना।

बहु-चरणीय प्रक्रियाएं जैसे ऑनलाइन शॉपिंग कार्ट।

(b) Describe SSL Authentication. Explain the components of SSL client application. (10)

Ans.

SSL प्रमाणीकरण (SSL Authentication)

SSL (सिक्योर सॉकेट्स लेयर), और इसका आधुनिक उत्तराधिकारी TLS (ट्रांसपोर्ट लेयर सिक्योरिटी), एक क्रिप्टोग्राफिक प्रोटोकॉल है जिसे इंटरनेट पर संचार सुरक्षा प्रदान करने के लिए डिज़ाइन किया गया है। इसका मुख्य उद्देश्य क्लाइंट (जैसे एक वेब ब्राउज़र) और सर्वर (जैसे एक वेब सर्वर) के बीच एक सुरक्षित, एन्क्रिप्टेड चैनल स्थापित करना है।

SSL प्रमाणीकरण इस सुरक्षित चैनल को स्थापित करने की प्रक्रिया का एक महत्वपूर्ण हिस्सा है, जिसे SSL हैंडशेक कहा जाता है। यह सुनिश्चित करता है कि क्लाइंट उस सर्वर की पहचान को सत्यापित कर सकता है जिससे वह बात कर रहा है, और इसके विपरीत (पारस्परिक प्रमाणीकरण के मामले में)।

मानक SSL हैंडशेक (सर्वर प्रमाणीकरण) इस प्रकार काम करता है:

1. ClientHello: क्लाइंट सर्वर को एक `ClientHello` संदेश भेजता है, जिसमें SSL/TLS संस्करण, समर्थित सिफर सूट और एक यादृच्छिक बाइट स्ट्रिंग शामिल होती है।
2. ServerHello and Certificate: सर्वर एक `ServerHello` संदेश के साथ प्रतिक्रिया करता है, जिसमें चयनित सिफर सूट और अपनी यादृच्छिक बाइट स्ट्रिंग होती है। इसके बाद, सर्वर अपना SSL प्रमाणपत्र भेजता है। इस प्रमाणपत्र में सर्वर का सार्वजनिक कुंजी, डोमेन नाम और एक विश्वसनीय प्रमाणपत्र प्राधिकरण (Certificate Authority – CA) द्वारा एक डिजिटल हस्ताक्षर होता है।
3. Client Verification: क्लाइंट सर्वर के प्रमाणपत्र को मान्य करता है। यह जाँचता है कि प्रमाणपत्र की समय सीमा समाप्त नहीं हुई है, कि यह उस डोमेन नाम से मेल खाता है जिससे वह कनेक्ट करने का प्रयास कर रहा है, और यह कि उस पर एक विश्वसनीय CA द्वारा हस्ताक्षर किए गए हैं। क्लाइंट के पास पहले से ही विश्वसनीय CAs की एक सूची होती है।
4. Key Exchange: सर्वर की पहचान सत्यापित होने के बाद, क्लाइंट और सर्वर सुरक्षित रूप से एक साझा सेशन कुंजी का आदान-प्रदान करते हैं। यह आमतौर पर सर्वर की सार्वजनिक कुंजी का उपयोग करके क्लाइंट द्वारा उत्पन्न एक गुप्त कुंजी को एन्क्रिप्ट करके और इसे सर्वर को भेजकर किया जाता है। सर्वर इसे अपनी निजी कुंजी से डिक्रिप्ट करता है।
5. Secure Communication: एक बार जब दोनों पक्षों के पास समान सेशन कुंजी होती है, तो हैंडशेक पूरा हो जाता है। इसके बाद के सभी डेटा को इस सममित कुंजी का उपयोग करके एन्क्रिप्ट और डिक्रिप्ट किया जाता है, जिससे एक सुरक्षित संचार चैनल सुनिश्चित होता है।

पारस्परिक प्रमाणीकरण (Mutual Authentication) में, सर्वर क्लाइंट से भी उसका प्रमाणपत्र भेजने का अनुरोध करता है, जिसे सर्वर मान्य करता है।

SSL क्लाइंट एप्लिकेशन के घटक

जावा में एक SSL क्लाइंट एप्लिकेशन बनाने के लिए, JSSE (जावा सिक्योर सॉकेट एक्सटेंशन) एपीआई का उपयोग किया जाता है। मुख्य घटक हैं:

• SSLContext: यह JSSE एपीआई का मुख्य प्रवेश बिंदु है। यह सुरक्षित सॉकेट बनाने के लिए आवश्यक सभी कॉन्फ़िगरेशन और कार्यक्षमता को समाहित करता है। यह `KeyManager`, `TrustManager`, और एक यादृच्छिकता के स्रोत को इनिशियलाइज़ करता है।
• SSLSocketFactory: यह `SSLContext` से प्राप्त एक फैक्ट्री क्लास है। इसका उपयोग `SSLSockets` बनाने के लिए किया जाता है। आप डिफ़ॉल्ट फैक्ट्री प्राप्त कर सकते हैं या कस्टम `KeyManager` और `TrustManager` के साथ एक `SSLContext` से एक बना सकते हैं।
• SSLSocket: यह `java.net.Socket` का एक सबक्लास है और सुरक्षित संचार के लिए वास्तविक कार्य करता है। यह हैंडशेक प्रक्रिया और डेटा के एन्क्रिप्शन/डिक्रिप्शन को स्वचालित रूप से संभालता है।
• TrustManager: यह यह निर्धारित करने के लिए जिम्मेदार है कि रिमोट पार्टी (सर्वर) पर भरोसा किया जाना चाहिए या नहीं। यह सर्वर के प्रमाणपत्र को मान्य करता है। `TrustManager` को आमतौर पर एक ट्रस्टस्टोर (TrustStore) से इनिशियलाइज़ किया जाता है, जो एक फ़ाइल है जिसमें विश्वसनीय CAs के प्रमाणपत्र होते हैं।
• KeyManager: यह क्लाइंट की अपनी निजी कुंजी और प्रमाणपत्रों को प्रबंधित करने के लिए जिम्मेदार है। यह केवल पारस्परिक प्रमाणीकरण के लिए आवश्यक है, जहाँ क्लाइंट को सर्वर के सामने अपनी पहचान साबित करने की आवश्यकता होती है। `KeyManager` को एक कीस्टोर (KeyStore) से इनिशियलाइज़ किया जाता है, जिसमें क्लाइंट की निजी कुंजी और संबंधित प्रमाणपत्र श्रृंखला होती है।

Q4. (a) Explain the various web security objects. Also, describe the web security object dependencies, with the help of a diagram. (10)

Ans. Java EE (अब जकार्ता EE) वेब अनुप्रयोगों में, सुरक्षा को मानक परिनियोजन डिस्क्रिप्टर, `web.xml` में विभिन्न XML तत्वों का उपयोग करके घोषणात्मक रूप से कॉन्फ़िगर किया जाता है। इन तत्वों को वेब सुरक्षा ऑब्जेक्ट्स के रूप में संदर्भित किया जा सकता है।

विभिन्न वेब सुरक्षा ऑब्जेक्ट्स (तत्व)

1. Security Constraint (` `): यह मुख्य तत्व है जो वेब संसाधनों के एक संग्रह के लिए पहुँच नियंत्रण को परिभाषित करता है। यह बताता है कि कौन से URL पैटर्न सुरक्षित हैं और उन तक पहुँचने के लिए क्या आवश्यक है। एक ` ` में एक या अधिक ` ` और एक ` ` होता है।
2. Web Resource Collection (` `): यह तत्व ` ` के भीतर परिभाषित किया गया है। यह उन वेब संसाधनों के समूह को निर्दिष्ट करता है जिन पर सुरक्षा बाधा लागू होती है। इसमें शामिल हैं:
   • ` `: उन URL को परिभाषित करता है जिन्हें सुरक्षित किया जाना है (जैसे, `/admin/*`)।
   • ` `: उन HTTP विधियों को निर्दिष्ट करता है जो सुरक्षित हैं (जैसे, GET, POST)। यदि निर्दिष्ट नहीं है, तो सभी विधियाँ सुरक्षित हैं।

3. Authorization Constraint (` `): यह तत्व यह भी निर्दिष्ट करता है कि ` ` में परिभाषित संसाधनों तक पहुँचने की अनुमति किसे है। इसमें एक या अधिक ` ` तत्व होते हैं, जो उन तार्किक भूमिकाओं को सूचीबद्ध करते हैं जिन्हें पहुँच प्रदान की जाती है।
4. Security Role (` `): यह तत्व एप्लिकेशन द्वारा उपयोग की जाने वाली सभी तार्किक सुरक्षा भूमिकाओं को परिभाषित करता है। ` ` में उपयोग की गई प्रत्येक भूमिका को यहाँ ` ` के रूप में घोषित किया जाना चाहिए। ये तार्किक भूमिकाएँ बाद में एप्लिकेशन सर्वर में वास्तविक उपयोगकर्ताओं या समूहों के लिए मैप की जाती हैं।
5. Login Configuration (` `): यह तत्व परिभाषित करता है कि वेब कंटेनर को उपयोगकर्ताओं को कैसे प्रमाणित करना चाहिए जब वे एक सुरक्षित संसाधन तक पहुँचने का प्रयास करते हैं। इसमें शामिल हैं:
   • ` `: प्रमाणीकरण विधि, जो `BASIC`, `DIGEST`, `FORM`, या `CLIENT-CERT` हो सकती है।
   • ` `: यदि `auth-method` `FORM` है, तो यह तत्व लॉगिन पृष्ठ और त्रुटि पृष्ठ के पथ को निर्दिष्ट करता है।

वेब सुरक्षा ऑब्जेक्ट निर्भरताएँ ये ऑब्जेक्ट्स एक दूसरे पर निर्भर हैं और एक साथ मिलकर एक पूर्ण सुरक्षा कॉन्फ़िगरेशन बनाते हैं।

• एक ` ` में कम से कम एक ` ` होना चाहिए ताकि यह पता चल सके कि किसे सुरक्षित करना है।
• यदि संसाधनों तक पहुँच को प्रतिबंधित करना है, तो ` ` में एक ` ` भी होना चाहिए।
• ` ` में उपयोग किया गया प्रत्येक ` ` `web.xml` में कहीं और एक ` ` तत्व में घोषित किया जाना चाहिए।
• संपूर्ण सुरक्षा तंत्र काम करने के लिए, एक ` ` होना चाहिए ताकि कंटेनर को पता चल सके कि उपयोगकर्ताओं को कैसे प्रमाणित करना है जब वे एक प्रतिबंधित संसाधन तक पहुँचते हैं।

निर्भरता का चित्र: यह चित्र दिखाता है कि ये तत्व `web.xml` में कैसे संरचित और एक दूसरे से संबंधित हैं। इस चित्र में, `security-constraint` मुख्य कंटेनर है। यह `web-resource-collection` (क्या सुरक्षित करना है) और `auth-constraint` (किसे अनुमति है) को समाहित करता है। `auth-constraint` में परिभाषित `role-name` को `security-role` परिभाषा से मेल खाना चाहिए। `login-config` यह परिभाषित करता है कि प्रमाणीकरण कैसे होता है, जो इन बाधाओं को लागू करने के लिए आवश्यक है। (b) Write a JSP program to take date of birth as input and display the age of the person. (5)

Ans. यह JSP प्रोग्राम उपयोगकर्ता से जन्मतिथि इनपुट के रूप में लेता है और फिर व्यक्ति की आयु की गणना करके प्रदर्शित करता है। यह आधुनिक `java.time` API का उपयोग करता है।

“`jsp <%@ page language=”java” contentType=”text/html; charset=UTF-8″ pageEncoding=”UTF-8″%> <%@ page import=”java.time.LocalDate” %> <%@ page import=”java.time.Period” %> <%@ page import=”java.time.format.DateTimeParseException” %>

Age Calculator

Age Calculator

Enter your Date of Birth:

<% // अनुरोध पैरामीटर “dob” प्राप्त करें String dobString = request.getParameter(“dob”); // जाँच करें कि फ़ॉर्म सबमिट किया गया है या नहीं if (dobString != null && !dobString.isEmpty()) { try { // इनपुट स्ट्रिंग से जन्मतिथि को पार्स करें LocalDate birthDate = LocalDate.parse(dobString);

// वर्तमान तिथि प्राप्त करें LocalDate currentDate = LocalDate.now();

// जन्मतिथि और वर्तमान तिथि के बीच की अवधि की गणना करें if (!birthDate.isAfter(currentDate)) { Period age = Period.between(birthDate, currentDate);

// परिणाम प्रदर्शित करें out.println(” “); out.println(“Your age is: ” + age.getYears() + ” years, ” + age.getMonths() + ” months, and ” + age.getDays() + ” days.”); out.println(” “); } else { out.println(” Birth date cannot be in the future. “); } } catch (DateTimeParseException e) { out.println(” Invalid date format. Please use YYYY-MM-DD. “); } } %>

“` प्रोग्राम कैसे काम करता है: 1. HTML Form: एक सरल HTML फ़ॉर्म उपयोगकर्ता को `type=”date”` इनपुट फ़ील्ड का उपयोग करके अपनी जन्मतिथि दर्ज करने की अनुमति देता है। यह एक सुविधाजनक डेट पिकर प्रदान करता है। 2. JSP Scriptlet:

• `request.getParameter(“dob”)` का उपयोग करके सबमिट की गई जन्मतिथि स्ट्रिंग (जैसे, “1995-08-15”) को पुनः प्राप्त किया जाता है।
• यह जाँचता है कि `dobString` null या खाली नहीं है, जिसका अर्थ है कि फ़ॉर्म सबमिट किया गया था।
• `LocalDate.parse(dobString)` स्ट्रिंग को `LocalDate` ऑब्जेक्ट में परिवर्तित करता है।
• `LocalDate.now()` वर्तमान तिथि देता है।
• `Period.between(birthDate, currentDate)` एक `Period` ऑब्जेक्ट लौटाता है जो दो तिथियों के बीच वर्षों, महीनों और दिनों की मात्रा का प्रतिनिधित्व करता है।
• `age.getYears()`, `age.getMonths()`, और `age.getDays()` का उपयोग करके आयु के घटकों को निकाला और प्रदर्शित किया जाता है।
• त्रुटि से निपटने के लिए `try-catch` ब्लॉक का उपयोग किया जाता है, जैसे कि यदि उपयोगकर्ता एक अमान्य तिथि प्रारूप दर्ज करता है। यह भविष्य की तारीखों के लिए भी जाँच करता है।

(c) Describe and compare the Index Property and Bound Property of Java Beans. (5)

Ans. जावा बीन्स में, गुण (properties) एक बीन की विशेषताओं या स्थिति का प्रतिनिधित्व करते हैं, जिन्हें `get` और `set` विधियों के माध्यम से एक्सेस किया जाता है। इंडेक्स्ड और बाउंड गुण मानक गुणों के विशेष प्रकार हैं जो अतिरिक्त कार्यक्षमता प्रदान करते हैं।

इंडेक्स्ड प्रॉपर्टी (Indexed Property)

• विवरण: एक इंडेक्स्ड प्रॉपर्टी एक ऐसी प्रॉपर्टी है जो मानों की एक श्रृंखला (array) या संग्रह (collection) का प्रतिनिधित्व करती है। एक साधारण प्रॉपर्टी के विपरीत, जो एकल मान रखती है, एक इंडेक्स्ड प्रॉपर्टी कई मान रख सकती है।
• एक्सेस विधियाँ: इंडेक्स्ड प्रॉपर्टीज में विशिष्ट सिग्नेचर वाली `get` और `set` विधियाँ होती हैं:
  • एक व्यक्तिगत मान तक पहुँचने के लिए: `public T getPropertyName(int index)` और `public void setPropertyName(int index, T value)`।
  • पूरी श्रृंखला तक पहुँचने के लिए: `public T[] getPropertyName()` और `public void setPropertyName(T[] values)`।
• उदाहरण: एक `Employee` बीन में एक इंडेक्स्ड प्रॉपर्टी `project` हो सकती है जो उन सभी परियोजनाओं की सूची संग्रहीत करती है जिन पर कर्मचारी काम कर रहा है।
• उद्देश्य: इसका मुख्य उद्देश्य एक बीन में बहु-मूल्यवान विशेषताओं को मॉडल करना है।

बाउंड प्रॉपर्टी (Bound Property)

• विवरण: एक बाउंड प्रॉपर्टी एक ऐसी प्रॉपर्टी है जो अन्य घटकों (“श्रोताओं” या “listeners”) को सूचित करती है जब उसका मान बदलता है। यह जावा में ऑब्जर्वर डिज़ाइन पैटर्न का एक कार्यान्वयन है।
• कार्यान्वयन: एक बाउंड प्रॉपर्टी को लागू करने के लिए, बीन को:
  1. श्रोताओं को जोड़ने और हटाने के लिए विधियाँ प्रदान करनी चाहिए: `addPropertyChangeListener(PropertyChangeListener listener)` और `removePropertyChangeListener(PropertyChangeListener listener)`।
  2. `java.beans.PropertyChangeSupport` क्लास का उपयोग करके श्रोताओं की एक सूची बनाए रखनी चाहिए।
  3. जब प्रॉपर्टी का मान बदलता है, तो सेटर विधि को `firePropertyChange()` को कॉल करना चाहिए, जो सभी पंजीकृत श्रोताओं को एक `PropertyChangeEvent` भेजता है।
• उदाहरण: एक GUI घटक में, यदि एक `color` प्रॉपर्टी एक बाउंड प्रॉपर्टी है, तो जब भी रंग बदलता है, तो अन्य घटक (जैसे कि उस रंग का उपयोग करने वाले लेबल) को सूचित किया जा सकता है और वे खुद को फिर से पेंट कर सकते हैं।
• उद्देश्य: इसका मुख्य उद्देश्य विभिन्न घटकों के बीच स्थिति को सिंक्रनाइज़ करना और ईवेंट-संचालित संचार को सक्षम करना है।

तुलना

पहलू

इंडेक्स्ड प्रॉपर्टी

बाउंड प्रॉपर्टी

अवधारणा

मानों की एक श्रृंखला या सूची का प्रतिनिधित्व करती है।

मान बदलने पर श्रोताओं को सूचित करती है।

मुख्य उद्देश्य

बहु-मूल्यवान विशेषताएँ।

परिवर्तन अधिसूचना और ईवेंट हैंडलिंग।

एक्सेस विधियाँ

इंडेक्स-आधारित गेटर्स/सेटर्स (जैसे, `getValue(int index)`).

मानक गेटर्स/सेटर्स, लेकिन सेटर परिवर्तन की सूचना देता है।

सहायक वर्ग

कोई विशिष्ट सहायक वर्ग आवश्यक नहीं है (मानक संग्रह का उपयोग करता है)।

आमतौर पर `PropertyChangeSupport` और `PropertyChangeListener` का उपयोग करता है।

संबंध

एक प्रॉपर्टी एक ही समय में इंडेक्स्ड और बाउंड दोनों हो सकती है। वे परस्पर अनन्य नहीं हैं।

एक प्रॉपर्टी एक ही समय में इंडेक्स्ड और बाउंड दोनों हो सकती है।

Q5. Write short notes on the following : 2×10=20 (a) Relation of applets and servlets with JSP (b) Message-driven bean and its uses (c) Scripting elements in JSP (d) Web security concepts

Ans.

(a) JSP के साथ एप्लेट्स और सर्वलेट्स का संबंध

सर्वलेट्स के साथ संबंध:

JSP और सर्वलेट्स का गहरा संबंध है; वास्तव में, JSP सर्वलेट तकनीक पर बनी एक उच्च-स्तरीय अमूर्तता है।

• अनुवाद: जब एक JSP पेज का पहली बार अनुरोध किया जाता है, तो वेब कंटेनर इसे एक समकक्ष जावा सर्वलेट स्रोत कोड में अनुवादित करता है। फिर यह स्रोत कोड संकलित होता है और परिणामी `.class` फ़ाइल को एक मानक सर्वलेट के रूप में निष्पादित किया जाता है।
• MVC पैटर्न: आधुनिक वेब विकास में, सर्वलेट्स और JSP अक्सर मॉडल-व्यू-कंट्रोलर (MVC) पैटर्न में एक साथ काम करते हैं। सर्वलेट कंट्रोलर के रूप में कार्य करता है, जो आने वाले अनुरोधों को संभालता है, व्यावसायिक तर्क को संसाधित करता है, और डेटा तैयार करता है। JSP व्यू के रूप में कार्य करता है, जो सर्वलेट द्वारा तैयार किए गए डेटा को HTML प्रारूप में प्रस्तुत करने के लिए जिम्मेदार होता है। यह भूमिकाओं का पृथक्करण रखरखाव और विकास को सरल बनाता है।
• उद्देश्य: सर्वलेट्स व्यावसायिक तर्क और अनुरोध प्रसंस्करण के लिए बेहतर हैं, जबकि JSP प्रस्तुति के लिए बेहतर हैं। JSP, HTML के भीतर जावा कोड लिखने की अनुमति देकर वेब डिजाइनरों के लिए गतिशील पेज बनाना आसान बनाता है।

एप्लेट्स के साथ संबंध:

JSP और एप्लेट्स दोनों वेब के लिए जावा प्रौद्योगिकियाँ हैं, लेकिन वे मौलिक रूप से अलग-अलग भूमिकाएँ निभाते हैं।

• क्लाइंट-साइड बनाम सर्वर-साइड: मुख्य अंतर उनके निष्पादन वातावरण में है। JSP एक सर्वर-साइड तकनीक है; यह सर्वर पर चलता है और क्लाइंट को HTML भेजता है। एप्लेट एक क्लाइंट-साइड तकनीक है; यह वेब ब्राउज़र के भीतर जावा वर्चुअल मशीन (JVM) में चलता है।
• संबंध: JSP का उपयोग एप्लेट को वेब पेज पर एम्बेड करने के लिए आवश्यक HTML (` ` या `