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