मोबाइल क्लाइंट सर्वर विकास

मोबाइल क्लाइंट का रिवर्स साइड सर्वर है।

परिचय

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

आवश्यकताओं

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

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

टीम

सिस्टम डेवलपमेंट के लिए प्रोजेक्ट टीम की संरचना आदर्श रूप से निम्नानुसार हो सकती है:
• परियोजना प्रबंधक: प्रबंधन, परियोजना को नियंत्रित करता है, ग्राहक के साथ सीधे संपर्क करता है;
• सर्वर एप्लिकेशन डेवलपर: एक व्यावसायिक तर्क सर्वर, डेटाबेस, नेटवर्क प्रोटोकॉल विकसित करता है;
• एडमिनिस्ट्रेटर एप्लिकेशन डेवलपर: एक वेब एप्लिकेशन, सर्वर एप्लिकेशन को कॉन्फ़िगर और प्रबंधित करने के लिए एक यूजर इंटरफेस विकसित करता है;
• Android के लिए एक ग्राहक आवेदन के डेवलपर;
• iOS के लिए क्लाइंट एप्लिकेशन का डेवलपर;
• ग्राहक एप्लिकेशन डेवलपर ...
• परीक्षक: व्यवस्थापक अनुप्रयोग और ग्राहक अनुप्रयोगों का परीक्षण करता है।

एक चौकस पाठक यह नोटिस करेगा कि यदि आप एक ग्राफिकल इंटरफेस के साथ सर्वर एप्लिकेशन लिखते हैं, उदाहरण के लिए, एचटीएमएल 5 में, तो आप बचा सकते हैं। इस मामले में, क्लाइंट अनुप्रयोगों के विकास की आवश्यकता नहीं है - उपयोगकर्ता इंटरफ़ेस एक ब्राउज़र प्रदान करता है। यह लेख इस तरह के मामले को संबोधित नहीं करता है, यह मोबाइल उपकरणों के लिए "देशी" अनुप्रयोगों को विकसित करने का सवाल है।

मैंने पूरी तरह से पूरक के साथ एक टीम में काम किया है, लेकिन यह यथार्थवादी होगा - हमेशा मानव संसाधन नहीं और बजट मुझे ऐसी टीम को इकट्ठा करने की अनुमति देता है। और कभी-कभी भूमिकाओं को संयुक्त करना पड़ता है: परियोजना प्रबंधक + सर्वर अनुप्रयोग डेवलपर, क्लाइंट अनुप्रयोग डेवलपर + परीक्षक।

प्रौद्योगिकी, उपकरण, पुस्तकालय

मोबाइल क्लाइंट सर्वर विकसित करने के लिए, मैं आमतौर पर "फ्री" तकनीकों के निम्नलिखित स्टैक का उपयोग करता हूं:
• अपाचे टॉम्केट - एक सर्वलेट कंटेनर;
• MySQL - DBMS;
• तोड़फोड़ - संस्करण नियंत्रण प्रणाली;
• मावेन - परियोजनाओं की विधानसभा को स्वचालित करने के लिए एक रूपरेखा;
• JUnit - स्वचालित आवेदन परीक्षण की प्रभावशीलता सुनिश्चित करेगा;
• अपाचे Log4j - लॉगिंग लाइब्रेरी;
• जेनकिंस - निरंतर एकीकरण की एक प्रणाली;
• हाइबरनेट - ओआरएम (सेटिंग्स, गुणों में कॉन्फ़िगरेशन, एक्सएमएल फाइलें और एनोटेशन);
• हाइबरनेट-जेनेरिक-डाओ - Google से डीएओ कार्यान्वयन, डेटाबेस डेटा के साथ काम करने के लिए बुनियादी तरीकों को लागू करता है, तरीकों में फ़िल्टरिंग और सॉर्टिंग के कार्यान्वयन को सरल करता है;
• वसंत - प्रमाणीकरण और प्राधिकरण (सुरक्षा) के कार्यान्वयन, सेवाओं और सेम के एक कंटेनर (xml फ़ाइलों और एनोटेशन में कॉन्फ़िगरेशन), हम परीक्षण बनाते समय भी इसका उपयोग करते हैं।

सिस्टम की बारीकियों और इसके लिए आवश्यकताओं के आधार पर, मैं डेटा विनिमय प्रोटोकॉल को लागू करने के लिए 2 विकल्पों में से एक का उपयोग करता हूं।
जब क्रॉस-प्लेटफॉर्म प्रदर्शन, गति, सादगी, दक्षता, स्केलेबिलिटी, एक खुले एपीआई की आवश्यकता होती है, तो मैं जर्सी - रेस्टफुल वेब सेवाओं का कार्यान्वयन करता हूं। यह लाइब्रेरी आपको JSON या (और) XML प्रारूप में डेटा के क्रमांकन का उपयोग करने की अनुमति देती है। अन्य कॉन्फ़िगरेशन एनोटेशन के माध्यम से किया जाता है। मोबाइल उपकरणों के साथ आदान-प्रदान के लिए, JSON प्रारूप लिया गया था क्योंकि इसका क्लाइंट पक्ष पर सरल कार्यान्वयन है (इस कारण से हम "क्लासिक" वेब सेवाओं का उपयोग नहीं करते हैं), कम ट्रैफ़िक उत्पन्न होता है। जर्सी आपको सबसे उपयुक्त "लुक" JSON में ट्यून करने की अनुमति देता है।
अन्यथा, यदि आपको क्रॉस-प्लेटफॉर्म, उच्च प्रदर्शन, सादगी, दक्षता, अन्तरक्रियाशीलता की आवश्यकता है, तो मैं लेता हूं
• अपाचे MINA - नेटवर्क एप्लिकेशन बनाने के लिए रूपरेखा,
• Google प्रोटोबॉफ़ - संरचित डेटा को एन्कोडिंग और डिकोड करने का एक पुस्तकालय। डेटा संरचना * .pro हैडर फ़ाइलों द्वारा निर्धारित की जाती है, संकलक उनसे जावा कक्षाएं उत्पन्न करता है (अन्य प्रोग्रामिंग भाषाओं के लिए उत्पन्न होने की संभावना भी है: सी ++, ऑब्जेक्टिव-सी, आदि, जो क्रॉस-प्लेटफॉर्म संपत्ति प्रदान करता है);
• java.util.concurrent - मानक पैकेज का उपयोग करें।
इस विकल्प को बढ़ाया जा सकता है, लेकिन इसे व्यवसाय के तर्क को देखते हुए वास्तुकला स्तर पर डिज़ाइन स्तर पर रखा जाना चाहिए।

वास्तविक सास सेवा के लिए प्रौद्योगिकियों को चुनने के उदाहरण से एक काल्पनिक कार्य पर विचार करें - Auknem सेवा नीलामी , जो लोगों को आवश्यक सेवाओं या कार्य करने के लिए एक आदेश देने की अनुमति देती है, और संगठन, बदले में, उनके लिए उनके प्रस्तावों को छोड़ देते हैं। हम सभी मूलभूत आवश्यकताओं को डिफ़ॉल्ट रूप से लेते हैं। इस तथ्य के कारण कि इस प्रणाली में पंजीकरण मुफ्त और मुफ्त है, निश्चित रूप से उनके लिए स्केलेबिलिटी जोड़ना आवश्यक है। और अन्तरक्रियाशीलता के बारे में क्या? नए आदेशों के निर्माण के ठेकेदारों (कलाकारों) को सूचित करना और आवेदन में एक ही समय में प्राप्त प्रस्तावों के ग्राहकों को सूचित करना बहुत अच्छा होगा, न कि केवल ईमेल द्वारा। इसके आधार पर, हम Apache MINA, Google प्रोटोबॉफ़ को लागू करने के लिए लेते हैं। हम निम्नलिखित संपत्ति को देखते हैं - एपीआई खोलें। सेवा सार्वजनिक रूप से उपलब्ध है, इसलिए मान लीजिए कि बाहरी डेवलपर्स को इसके साथ एकीकृत करने में रुचि हो सकती है। एक मिनट रुको! इतना सरल नहीं है। Apache MINA पर आधारित प्रोटोकॉल, बारीकियों को जानने के बिना कार्यान्वयन और एकीकरण पर काफी निर्भर है जो पारदर्शी है। ऐसी स्थिति में, आपको तौलना होगा कि कौन सा कारक अधिक महत्वपूर्ण है और एक विकल्प बनाएं।

निष्कर्ष

मुझे यह जानने में दिलचस्पी होगी कि मोबाइल उपकरणों या समान प्रणालियों के लिए सर्वर विकसित करते समय आपने किन तकनीकों और पुस्तकालयों का उपयोग किया है? सब कुछ बदलता है, कुछ भी हमेशा के लिए नहीं रहता है, प्रत्येक स्तर पर उनके फायदे और नुकसान के साथ विकल्प होते हैं: MySQL - PostgreSQL , तोड़फोड़ - गिट , अपाचे Tomcat - Jetty , Apache MINA - Netty ...