वेब सेवा बनाम टीसीपी/आईपी सॉकेट (जावा) + एसक्यूएल कनेक्शन

Question

हम वर्तमान में हमारे उत्पाद जीवन चक्र में एक मंच पर हैं जहां हम वेब सेवाओं में जाने के बारे में सोच रहे हैं। हमारी प्रणाली जावा में लिखी गई है जिसमें कई क्लाइंट और सर्वर अनुप्रयोग शामिल हैं जो टीसीपी सॉकेट पर एक-दूसरे से बात करते हैं और डेटा पुनर्प्राप्ति और अपडेट (yuk! मुझे पता है) करने के लिए इन-लाइन एसक्यूएल भी है जो हमारे स्वयं के एसक्यूएल कनेक्शन क्लास का उपयोग करता है जो Microsoft JDBC ड्राइवर का उपयोग कर SQL सर्वर डेटाबेस से कनेक्ट करने के लिए java.sql.Connection का उपयोग करता है।

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

सोचा

तो हम एक वेब सेवा से सभी डेटा का उपयोग और टीसीपी संचार परिवर्तित करने पर देख रहे हैं।

वेब सेवा को एक कंपनी सुरक्षित इंटरनेट साइट पर चलाने के लिए डिज़ाइन किया जाएगा। विचार यह होगा कि उपयोगकर्ता अपने ग्राहकों को घर से वेब सेवा से जोड़ सकते हैं - जब वे कंपनी नेटवर्क पर नहीं होते - या काम पर, जब वे होते हैं।

क्लाइंट एप्लिकेशन वेब सेवा का उपयोग कर सर्वर साइड एप्लिकेशन से संदेशों को भेज/प्राप्त करेंगे। ग्राहक अनुप्रयोग वेब सेवा का उपयोग कर डेटाबेस में डेटा पुनर्प्राप्त और अद्यतन करेंगे।

प्रश्न

मैं सिर्फ पता है कि लोगों के अनुभव 2 रास्ता संचार (अनुरोध और धक्का) एक वेब सेवा से अधिक (यदि संभव हो) और क्या विचार ऐसा करने के बारे में हैं के साथ कुछ भी करने की है चाहते हैं।

किसी वेब सेवा में डेटा पहुंच को कनवर्ट करना काफी आगे लगता है - मैं प्रदर्शन के साथ कुछ मुद्दों को निकाल सकता हूं जहां सिस्टम के कुछ हिस्सों में बड़े डेटा सेट पुनर्प्राप्त किए जाते हैं।

मैं इस मामले पर विभिन्न पढ़ने सामग्री देख रहा हूं क्योंकि यह कुछ समय है क्योंकि मैंने वेब सेवाओं को स्पर्श किया है (सी # और एएसपी.नेट का उपयोग करके)। वर्तमान में "जावा ™ के साथ बिल्डिंग वेब सेवाएं पढ़ना: एक्सएमएल, एसओएपी, डब्लूएसडीएल, और यूडीडीआई का भाव बनाना"। मुझे स्वीकार करना होगा कि मैंने सोचा था कि वेब सेवाएं हमेशा स्टेटलेस थीं लेकिन उन्होंने अभी पढ़ा है कि वे नहीं हैं!

धन्यवाद,

Andez

Answer 1

यह परिवहन परत पर किसी भी अन्य वेब अनुप्रयोग के रूप में ही किया जा रहा है के रूप में WebServices के बारे में सोच में मदद करता है। यह एचटीएमएल/एचटीटीपीएस प्रोटोकॉल का उपयोग उसी तरह करता है, यह सिर्फ HTML भेजने की बजाय, यह एक पूर्वनिर्धारित प्रारूप (एसओएपी) के अनुसार एक्सएमएल भेजता है। जैसे:

• यह अनुरोध/प्रतिक्रिया पर केंद्रित
• के रूप में एक वेब पेज स्टेटफुल हो सकता है, सत्र (का उपयोग कर यह सोचते हैं आप एक वेब सेवा ग्राहक कि सत्र कुकीज़ भर में बनाए रखने का समर्थन करता है है उसी तरह से स्टेटफुल किया जा सकता है अनुरोध)
• सभी अनुरोधों को अंततः सर्वर

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

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