IIS + .NET + Json। अपने अनुप्रयोग सर्वर लेखन

इस लेख में, मैंने अपने विज़न के बारे में बात करने की कोशिश की कि एक एप्लिकेशन सर्वर विभिन्न क्लाइंट्स के साथ क्या बातचीत करता है, और इसे .NET पर कैसे लाया जाए। लेख को ओवरलोड करने से बचने के लिए, मैंने कार्यान्वयन विवरणों में नहीं जाने की कोशिश की, लेकिन, मुझे लगता है, मुख्य विचार आपके लिए रुचि के होंगे।

तो क्या वास्तव में एक अनुप्रयोग सर्वर है?

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

इस परियोजना की पृष्ठभूमि यह थी।
किसी भी तरह से अगले अनुप्रयोग को विकसित करना जैसे कि Microsoft विंडोज कम्युनिकेशन फ़ंडेशन तकनीक पर आधारित है (विंडोज के बाद बस WCF के रूप में संदर्भित), विंडोज के लिए मोटी .NET क्लाइंट के अलावा, इस सेवा के लिए एक वेब इंटरफ़ेस बनाने की इच्छा थी। ExtJs को मास्टरिंग के लिए चुना गया था। "कैसे अजाक्स क्लाइंट को WCF सेवा से कनेक्ट करें" विषय पर एक छोटी सी सामग्री को देखते हुए, पहले ड्राफ्ट बनाए गए थे। लेआउट ने काम किया, लेकिन फिर भी कुछ असंतोष प्रतीत होता है कि प्रारंभिक चीजें प्राप्त करने के तरीकों में पैदा हुईं। पहली नज़र में बहुत सी "अनावश्यक बातें" इसके लिए की जानी थीं, जो व्यवहार में आवश्यक थीं।

थोड़ा और इतिहास।
WCF में कार्य अनुभव और कई सफलतापूर्वक कार्यान्वित परियोजनाएं थीं। ओ'रेली की एक स्मार्ट पुस्तक में, सेवा इंटरफ़ेस में कई तरीके नहीं बनाने की सिफारिश की गई थी (एक दर्जन से अधिक नहीं +)। इस से आगे बढ़ने और वास्तविक ज़रूरतों के लिए सेवा के लिए कई अलग-अलग तरीके हैं, एक मुख्य निष्पादन योग्य विधि और कुछ अतिरिक्त लोगों को आवश्यकतानुसार बनाने का निर्णय विकसित हो रहा था। क्योंकि उस समय यह केवल सेवा के .NET क्लाइंट्स के बारे में था, तब इस मुख्य विधि ने तथाकथित विधि के नाम को स्वीकार कर लिया और पैरामीटरों को बाइनरीफॉर्माटर द्वारा जोड़ दिया गया, साथ ही असेंबली में बाह्य असेंबलियों के मामले में असेम्बली क्विकलाइज्ड नाम दिया।
लेकिन ऐसा समाधान वेब ग्राहकों के साथ पूरी तरह से असंगत था और सेवा इंटरफ़ेस में लागू किए गए "फ्लैट" तरीकों पर वापस जाना था।
एमटीओएम के समर्थन के बावजूद, धाराओं के साथ काम करते समय समस्याएं थीं। मैं अभी भी सामान्य रूप से प्रॉक्सी सर्वर के माध्यम से स्ट्रीम पारित करने के लिए WCF नहीं प्राप्त कर सका।
WCF + अजाक्स बंडल में एक और उपद्रव Json क्रमांकन है। खैर, यह बहुत आसान लग रहा था, नहीं, और यहाँ इसकी बहुत सारी बारीकियों का गठन किया गया था।
इसके अलावा, अभ्यास ने हमेशा दिखाया है कि जिन ग्राहकों ने डब्ल्यूसीएफ-आधारित समाधानों को लागू किया है, उनके सर्वर पर .NET 3.5 SP1 को स्थापित करने में अक्सर समस्याएं होती हैं। या तो फ्रेमवर्क स्वयं स्थापित नहीं है, फिर .svc पंजीकृत नहीं है, जो सबसे अधिक बार है, फिर कुछ और।
थोड़ा-थोड़ा करके, चुपचाप, WCF पसंद करना बंद कर दिया।

और इस बीच, यह विचार अभी भी सता रहा था कि प्रसिद्ध सामाजिक नेटवर्क, वेब प्रोजेक्ट, विभिन्न ऐप स्टोर की सेवाएं इंटरनेट पर कैसे काम करती हैं। आखिरकार, एक भी php नहीं। यह स्पष्ट है कि यह विंडोज नहीं है, लेकिन यह बात नहीं है। लब्बोलुआब यह है कि ये सेवाएं विभिन्न प्रकार के ग्राहकों को डेटा प्रदान करती हैं। एक सेवा - कई अलग-अलग ग्राहक, यह हमारे समय में "शांत" और "कट्टर-महत्वपूर्ण" है, लेकिन .NET पर यह कैसे करना है?

.NET 2.0 से .asmx WebService का उपयोग करने का प्रयास करने का निर्णय लिया गया। इसके अलावा, .NET 3.5 ने एक्सटेंशन पेश किए जो उन्हें अजाक्स दुनिया के साथ बातचीत करने की अनुमति देते हैं। मैं तुरंत ही कहूंगा कि कुछ हुआ, कुछ नहीं हुआ, लेकिन फिर भी एक भावना थी कि XML वेब सेवाओं के लिए ये सभी एक्सटेंशन-जोड़ "दूर की कौड़ी" थे और उनके मूल निवासी नहीं थे।

मैं यह नहीं कहना चाहता कि WCF और WebService प्रौद्योगिकियाँ वेब 2.0 के कार्यान्वयन के लिए बिल्कुल उपयुक्त नहीं हैं, लेकिन मैं दोहराता हूं - जो प्रतीत होता है कि सहज रूप से कभी-कभी ऐसा "गलतफहमी" का कारण बनता है जिसे मैं छोड़ना चाहता था। सरल चीजों का कार्यान्वयन किसी भी तरह से जटिल लगता था, और कुछ चीजें पूरी तरह से असंभव थीं।
यहां एक ऐसे अप्रिय क्षणों की सूची दी जा सकती है जो विकास की प्रक्रिया के दौरान उत्पन्न हुए, लेकिन ईमानदार होने के लिए - अब मैं सब कुछ सुरुचिपूर्ण और सरल होने के बाद भी याद नहीं रखना चाहता।

तो क्या आपके लक्ष्यों को प्राप्त करने के लिए .NET में कुछ ऐसा होना चाहिए? हमारा उद्धार System.Net और System.Web है।
और इसलिए, IHttpHandler चुनें।

HttpRequest और HttpResponse के साथ HttpContext पर एक नज़र डालें। वे लगभग पूरी तरह से Webengine से Http प्रोटोकॉल के निम्न-स्तरीय विवरणों को लागू करते हैं और इसे चांदी की थाल पर रख देते हैं। हम केवल "नीली सीमा" खींच सकते हैं।

/// <summary> /// Enables processing of HTTP Web requests by a custom HttpHandler. /// </summary> /// <param name="httpContext"> Http .</param> void IHttpHandler.ProcessRequest(HttpContext httpContext) 

हमें कुछ क्लाइंट से रिक्वेस्ट मिली।
और फिर हम इसके साथ क्या करेंगे? जवाब सब कुछ है आपके दिल की इच्छाएं। हाँ, हाँ, बिल्कुल।
केवल एक बार फिर से हम क्या चाहते हैं:
1. एक अनुप्रयोग सर्वर - कई प्रकार के ग्राहक (.NET, Java, Web + Ajax, Silverlight, iPhone, Android, आदि);
2. किसी भी क्लाइंट से एप्लिकेशन सर्वर के आवश्यक एप्लिकेशन विधि को कॉल करना;
3. "GET" और "POST" अनुरोधों का समर्थन, अर्थात उरल या अनुरोध निकाय के माध्यम से गुजरने वाले पैरामीटर;
4. ग्राहकों को वापस भेजे जाने वाले तरीकों के मापदंडों और परिणामों को संपीड़ित करने के लिए समर्थन;
5. बिना किसी प्रयास के दोनों दिशाओं में प्रवाह के साथ काम करें;
6. समाधान की गति, सहजता, अतुल्यकालिकता, पारदर्शिता और स्पष्टता।

पहले पैराग्राफ को लागू करते समय, मैं इस निष्कर्ष पर पहुंचा था कि लगभग सभी भाषाओं और प्लेटफार्मों में मौजूद डेटा प्रकार हैं, जो एक-दूसरे के साथ संगत हैं और उन्हें पर्यावरण की सीमा के पार स्थानांतरित करने के लिए उपयुक्त है (मुझे भी बुलाया - अमेरिका की खोज की)। मैं "संगत" शब्द पर जोर देता हूं क्योंकि यह एक मूलभूत बिंदु है:
वर्ण, स्ट्रिंग्स (एन्कोडिंग को ध्यान में रखते हुए), सरल डेटा प्रकार (संख्या के विभिन्न प्रकार, बूलियन मान), बाइट सरणियाँ और धाराएँ। एक तारीख में आमतौर पर एक विशिष्ट स्ट्रिंग प्रतिनिधित्व होता है। इसमें उपरोक्त डेटा प्रकारों के कंटेनर के रूप में सरणियाँ, सूचियाँ और शब्दकोश भी शामिल हैं।
प्राकृतिक विकल्प एक्सचेंज फॉर्मेट के रूप में Json था। वैकल्पिक रूप से, न्यूटनसॉफ्ट से Json.NET लाइब्रेरी को चुना गया था।

और इसलिए, क्लाइंट को सर्वर को एक विशिष्ट एप्लिकेशन विधि (RPC) को कॉल करने में सक्षम होना चाहिए और सर्वर से स्पष्ट उत्तर प्राप्त करना चाहिए। एक विधि एक नाम के साथ एक स्ट्रिंग द्वारा दी गई है। विधि को मापदंडों की आवश्यकता है। उसे सही ढंग से पहचानना और उन्हें संसाधित करना होगा। अधिक लचीलेपन के लिए, विधियाँ न केवल सर्वर के लिए, बल्कि सर्वर पर उपलब्ध किसी भी असेंबली के लिए भी हो सकती हैं, हालाँकि, कुछ सुरक्षा प्रतिबंधों के अधीन।
REST शैली लोकप्रिय है, लेकिन पूरी तरह से लचीली नहीं है। यह एक "टेम्पलेट" शैली है। बाएं और दाएं कदम, और बहुमुखी प्रतिभा खो जाती है। एक अपरिहार्य QueryString बनी हुई है।

सर्वर को फॉर्म के क्लाइंट से एक अनुरोध प्राप्त होता है:
/service.ashx? विधि = GetImage ("DSCN2099.JPG")

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

पूर्ण क्वेरी स्ट्रिंग प्रारूप:

 /service.ashx?
 सत्र = xxxxxxxxxxxxxxxxxxx - सत्र आईडी
 वर्ग = पूर्ण असेंबली टाइपनेम और "फुलटाइपनेम, असेंबली नेम"
 विधि = MethodName (पैरामीटर) और - (केस-संवेदी विधि नाम)
 प्रारूप = Json / DotNetBinary & –– डेटा प्रारूप (एक्स्टेंसिबल)
 zip = on / off - क्या विधि के इनपुट पैरामीटर संपीड़ित हैं

यदि कोई भी पैरामीटर गायब है, तो उसका डिफ़ॉल्ट मान उपयोग किया जाता है। केवल एक चीज जिसे इंगित किया जाना चाहिए, उसे तथाकथित विधि का नाम है।

ग्राहक को क्या लौटना है? क्लाइंट एप्लिकेशन पर ही निर्भर करता है। यदि चित्र एक थंबनेल है, तो बाइट्स की एक सरणी वापस आ सकती है। यदि यह एक बड़ी तस्वीर है, तो धारा को वापस करना बेहतर है।

और इसलिए, एप्लिकेशन सर्वर अनुरोध प्राप्त करता है, इसे संसाधित करता है (पर्स करता है), निर्दिष्ट विधि का निष्पादन संदर्भ बनाता है, और निष्पादन के लिए विधि को कॉल करता है। विधि लागू किया तर्क और अंत में रिटर्न परिणाम; और यह परिणाम आगे कहां जाता है? हवा में नहीं। और परिणाम विधि से वापस सर्वर सर्वर कोर में एक सार्वभौमिक वस्तु के रूप में वापस आ जाता है। अगला, वापसी मान के प्रकार का विश्लेषण किया जाता है। यदि यह टाइपोफ़ (शून्य) है, तो कुछ और नहीं किया जाता है, अगर यह स्ट्रीम है, तो इसे HttpResponse के आउटपुट स्ट्रीम में रीडायरेक्ट किया जाता है। अन्यथा, परिणाम एक स्ट्रिंग में रूपांतरण के लिए धारावाहिक के लिए Json में वापस आ जाता है, और फिर इस स्ट्रिंग को HttpResponse-> Write () के माध्यम से लिखा जाता है।

इस प्रकार, Http अनुरोध के संदर्भ में पहुंच होने पर, हम एप्लिकेशन सर्वर इन्फ्रास्ट्रक्चर कोर के कार्यान्वयन का चयन करने के लिए स्वतंत्र थे।

SOAP .asmx WebService बुनियादी ढांचे को लगभग उसी तरह से लागू किया गया है। केवल भारी लेकिन सर्वाहारी XML है, और यहाँ हल्का और तेज Json है। .aspx और WCF भी हैंडलर हैं।

तो हमारे ग्राहकों का क्या, जिनके लिए यह सब शुरू हुआ?

.NET के साथ, सब कुछ सरल है।
यहां आपके पास मूल द्विआधारी प्रारूप और Json का विकल्प है, और HttpWebResponse-> GetResponseStream () एक ही स्ट्रीम है जो हमारे एप्लिकेशन विधि "GetImage ()" का एप्लिकेशन सर्वर वापस आ गया है, अंतर केवल इस स्ट्रीम के प्रकार में है, यहां यह एक नेटवर्क स्ट्रीम होगा - .NET फ्रेमवर्क के आंतरिक वर्गों में से एक। हाँ, यह हमारे लिए महत्वपूर्ण नहीं है। यह महत्वपूर्ण है कि हम इसे पढ़ सकते हैं और उदाहरण के लिए बना सकते हैं Image.FromStream () या बस इसे किसी फ़ाइल में सहेजें। यदि एप्लिकेशन सर्वर ने बाइनरी डेटा (बाइट []) की एक सरणी लौटा दी है, तो यह अनिवार्य रूप से एक ही है, क्योंकि GetResponseStream () के अलावा और कोई रास्ता नहीं है। केवल हमें इसे उसी सरणी में वापस बदलना होगा। इस स्ट्रीम के साथ क्या करना है, इसका निर्णय क्लाइंट एप्लिकेशन के डेवलपर द्वारा किया जाता है, एप्लिकेशन API के आधार पर जो एप्लिकेशन सर्वर उसे प्रदान करता है।

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

अजाक्स
एप्लिकेशन सर्वर की प्रस्तुत विचारधारा Ajax चौखटे के आधार पर ग्राहकों के कार्यान्वयन में बहुत अच्छी तरह से फिट बैठती है। आखिरकार, XML की तुलना में Json उन्हें और भी अधिक प्रिय है।

 Ext.Ajax.request({ method: 'GET', url: '/service.ashx?method=GetImageInfo(“DSCN2099.JPG”)', success: function(response, options) { var result = Ext.decode(response.responseText); }, failure: function(response, options) { ... } }); 

सर्वर विधि:

 public ImageInfo GetImageInfo(Json json) { string fileName = json.AsString; string filePath = Path.Combine(IMAGES_DIR, fileName); return new ImageInfo(filePath); } 

GetImageInfo () विधि द्वारा लौटाए गए ImageInfo संरचना को जेन्स धारावाहिककर्ता द्वारा निम्नलिखित में से कुछ के रूप में परिवर्तित किया जाएगा:

 {
    "नाम": "DSCN2099.JPG",
    "ऊंचाई": 1536,
    "चौड़ाई": 2048,
    "PixelFormat": 137224,
    "रॉफार्मेट": "जेपीईजी",
    "क्षैतिज क्षैतिजता": 300.0,
    "वर्टिकल इंडक्शन": 300.0,
    "थम्बइमेज": "/ 9j / 4AAQSkZJRgABAQ ...",
    "फाइलइन्फो": {
       "फाइलसाइज़": 1849625,
       "क्रिएशनटाइम": "\ / दिनांक (1246514398257 + 0400) \ /"
       "FileAttributes": 32
    }
 }

और एप्लिकेशन सर्वर इसे क्लाइंट को भेज देगा, जहां इसे जावास्क्रिप्ट ऑब्जेक्ट में डिकोड किया जाएगा।
दिनांक को कॉल करके प्राप्त किया जा सकता है:

 var date = Date.parseDate(result.FileInfo.CreationTime, 'M$').format('dmY h:i'), 

और पैर:

 var image = { xtype: 'box', autoEl: { tag: 'div', children: [{ tag: 'img', src: String.format('data:image/jpg;base64,{0}', result.ThumbImage) }] }, listeners: { render: function(comp) { comp.getEl().on({ dblclick: function() { var url = '/service.ashx?method=GetImage(result.Name)'; window.open(url, 'imageWindow', 'menubar=no, location=no, resizable=yes, scrollbars=yes, status=no, width=640, height=480'); }, scope: comp }); } } }; 

हमारा बेस 64 थम्बैमेज सफलतापूर्वक उचित आकार की तस्वीर में बदल गया है, और इस पर डबल क्लिक करने से एक नई ब्राउज़र विंडो खुलेगी और एक पूर्ण चित्र प्रदर्शित होगा।

उदाहरण के लिए, ऐसी चाल। स्टाइलशीट से एक लाइन। प्रतीक संसाधन सभा में हैं:

 .loading { background-image: url(/service.ashx?method=LoadIcon%28%22loading.gif%22%29) !important; } 

खैर, यह इतना अच्छा लगता है। हमारे पास पहले से दो ग्राहक हैं।

सिल्वरलाइट ट्राई करते हैं?
"मोटी" .NET क्लाइंट से अंतर HttpWebRequest और HttpWebResponse में सिंक्रोनस मेटाटोस की पूर्ण अनुपस्थिति है। Json के साथ काम करने के लिए, Silverlight के लिए Json.NET का कार्यान्वयन है। बाकी डेस्कटॉप डेस्कटॉप अनुप्रयोगों के लिए लगभग समान है।
एप्लिकेशन सर्वर के साथ बातचीत को सरल बनाने के लिए, एक विशेष अनुरोध वर्ग विकसित किया गया है जो एक क्वेरी स्ट्रिंग बनाता है और इसे निष्पादित करता है। यह HttpWebRequest और HttpWebResponse के साथ काम को इनकैप्सुलेट करता है:

 RequestParams requestParams = new RequestParams(); requestParams.Method.Name = "GetImage(fileName)"; requestParams.Method.Params.Add("fileName", "DSCN2099"); Request request = new Request("http://localhost/AppService"); request.Execute(requestParams, Action<RequestCompletedEventArgs> onRequestCompleted); 

यानी अनुरोध पैरामीटर तैयार करने के बाद, हम बस सर्वर विधि को कॉल करते हैं और कॉलबैक विधि में परिणाम को संसाधित करते हैं। यह आसान नहीं हो सकता है!

अगली पंक्ति में जावा है।
मुख्य वर्ग HttpURLConnection है, जिसमें एक getInputStream () विधि है। कहा जाता है - .NET से दो अंतर पाते हैं (नाम की गिनती नहीं)। विचार एक ही है - सहायक वर्ग अनुरोधपत्र और अनुरोध बनाए जाते हैं। RequestParams वर्ग को विधि और उसके मापदंडों का नाम है, और अनुरोध HttpURLConnection के साथ काम करने के लिए तर्क को अतिक्रमण करता है। Json क्रमांकन के लिए, Google की एक लाइब्रेरी का उपयोग किया जाता है - Gson, जिसका उपयोग Android के विकास के लिए भी किया जा सकता है। जावा के संबंध में एक विरोधी मंच पर कार्यान्वित एक एप्लिकेशन सर्वर से जोसन प्रारूप में आने वाली हर चीज, समस्याओं के बिना "पचा" है। केवल एक चीज जिसे जावा डिफ़ॉल्ट रूप से नहीं समझता है वह एमएस से तारीख प्रारूप है। लेकिन Gson एक एक्स्टेंसिबल लाइब्रेरी है, और समस्या बस हल हो गई है:

 public class MSDateJsonSerializer implements JsonSerializer<Date> { public JsonElement serialize(Date date, Type typeOfT, JsonSerializationContext context) { return new JsonPrimitive("/Date(" + date.getTime() + ")/"); } } public class MSDateJsonDeserializer implements JsonDeserializer<Date> { public Date deserialize(JsonElement json, Type typeOfT, JsonDeserializationContext context) throws JsonParseException { String jsonDateToMilliseconds = "\\/(Date\\((.*?)(\\+.*)?\\))\\/"; Pattern pattern = Pattern.compile(jsonDateToMilliseconds); Matcher matcher = pattern.matcher(json.getAsJsonPrimitive().getAsString()); String result = matcher.replaceAll("$2"); return new Date(new Long(result)); } } 

.NET से स्ट्रीम जावा के साथ भी संगत हैं (वे अफ्रीका में भी स्ट्रीम हैं):

 ImageIcon icon = new ImageIcon(“http://localhost/AppService/service.ashx? method=GetImage('DSCN2099.JPG')”); 

तो, हमारे पास पहले से ही 4 क्लाइंट हैं, और इस तथ्य को ध्यान में रखते हुए कि एंड्रॉइड एप्लिकेशन जावा में लिखे गए हैं, फिर सभी 5।

मुझे लगता है कि अब यह स्पष्ट हो गया है कि ग्राहकों के प्रकार पर व्यावहारिक रूप से कोई प्रतिबंध नहीं है, और सभी प्लेटफ़ॉर्म जो कि Http और Json के साथ काम कर सकते हैं, हमारे एप्लिकेशन सर्वर के साथ बातचीत करने में सक्षम होंगे।