एसओएपी वेब सेवा कॉलबैक आर्किटेक्चर?

Question

मैं वेब सेवाओं, जेएक्स-डब्ल्यूएस इत्यादि के लिए काफी नया हूं इसलिए शायद नोब सवाल ...

तो, मैं दो सिस्टम को संवाद करने के लिए एक वेब सेवा लागू करना चाहता हूं। "क्लाइंट" सिस्टम उन घटनाओं में रुचि रखता है जो "सर्वर" सिस्टम पर उत्पन्न होते हैं। लेकिन "क्लाइंट सिस्टम" स्वयं एक अलग ऐप के लिए एक सर्वर है। सर्वर जावा है (टोमकैट में युद्ध)। ग्राहक नेट है।

केवल एक क्लाइंट सिस्टम होना चाहिए, लेकिन क्लाइंट सिस्टम के अंदर कई ग्राहक प्रक्रियाएं, प्रत्येक घटनाओं की विशिष्ट श्रेणियों में रुचि रखते हैं।

मैं सर्वर-साइड और एक परीक्षण क्लाइंट को कार्यान्वित करूंगा। कोई और नेट कोड लागू करेगा।

चल अनुक्रम इस रेखा के साथ किया जाना चाहिए:

1. सर्वर चल रहा है ...
2. ग्राहक बातचीत शुरू की, सर्वर के लिए "रजिस्टर", और कुछ प्रारंभिक डेटा अनुरोध करता है।
3. सर्वर पंजीकृत ग्राहकों के एंडपॉइंट्स की एक सूची रखता है
4. सर्वर में एक श्रोता है जो कुछ घटनाओं के दौरान अधिसूचित किया जाता है। इसके बाद यह पंजीकृत ग्राहकों की सूची के माध्यम से जाएगा और उनमें से प्रत्येक को घटना
5. किसी बिंदु पर, क्लाइंट सर्वर को सूचित नहीं कर सकता है कि वह घटनाओं को प्राप्त नहीं करना चाहता है।

सबसे पहले, क्या यह कुछ उचित रूप से करने योग्य लगता है?

और एसओएपी (सर्वर पर जेएक्स-डब्ल्यूएस, जो भी नेट के साथ उपलब्ध है) का उपयोग कर एक मानक अंतर्निर्मित तंत्र है - सर्वर क्लाइंट से कॉलबैक एंडपॉइंट प्राप्त करने के लिए उपयोग कर सकता है?

उदाहरण के लिए, मैंने आरएमआई का उपयोग करके बहुत कुछ किया है, इस मामले में ग्राहक केवल अपने लिए एक दूरस्थ संदर्भ भेज सकता है, कि सर्वर केवल बाद में एंटी संदर्भ स्टोर कर सकता है।

अंत में

, वहाँ अंतिमबिंदुओं संदर्भ, बनाने के (सामूहिक) कॉलबैक स्टोर करने के लिए, और शायद अप करने की तारीख, ग्राहकों है कि जवाब नहीं है तो कुछ "पिंग" कॉल को हटाने सूची रखने के लिए एक मानक पुस्तकालय है?

स्पष्टता के लिए नोट: मुझे कॉलबैक के साथ केवल असीमित विधि से अधिक की आवश्यकता है: क्लाइंट से एक संदेश सर्वर से क्लाइंट से कई कॉलबैक संदेश उत्पन्न करेगा।

Answer 1

लगता है कि आप मनमाने ढंग से अज्ञात ग्राहकों को सूचित करने के लिए एक अधिसूचना सुविधा लागू करना चाहते हैं।

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

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

सोप विकल्प:

1. मालिकाना SOAP संदेश - "100% क्या इसे-स्वयं विकल्प"

   पूर्ण सोप पेलोड स्कीमा और संदेश विनिमय पैटर्न डिजाइन।

   यदि आप ग्राहक की SOAP एंडपॉइंट पता जानने ग्राहक के लिए सर्वर से अधिसूचना धक्का कर सकते हैं। ग्राहक मूल एसओएपी अनुरोध पेलोड के भीतर अपने एसओएपी एंडपॉइंट पते को स्थानांतरित कर सकता है। कुछ समय बाद सर्वर क्लाइंट को एसओएपी अनुरोध भेज सकता है।

   समस्याएं/अनुमान: (1) के अनुरोधों के लिए एक सोप/HTTP संचार पथ की जरूरत है सर्वर से ग्राहक - इसकी गारंटी नहीं है जब फायरवॉल मौजूद हैं; (2) ग्राहक को आपकी अधिसूचना स्कीमा से अवगत होना चाहिए - वास्तव में ग्राहक को एसओएपी अधिसूचना अनुरोध प्राप्त करने के लिए सेवा समापन बिंदु के रूप में कार्य करने की आवश्यकता है। यह दो बड़ी धारणा है यदि आप मनमाने ढंग से अज्ञात क्लाइंट का समर्थन करने की कोशिश कर रहे हैं - यह कुछ नहीं है SOAP "बस समर्थन करता है" दोनों सिरों को यह सब विस्तार से डिजाइन करने की आवश्यकता है। वास्तव में यह सेवा प्रकार के तरीके से करने के लिए, क्लाइंट को वास्तव में अपनी स्वयं की सेवा डब्लूएसडीएल इंटरफ़ेस घोषित करना चाहिए ताकि आप इसे आ सकें। (3) जैसा कि पहले संकेत दिया गया था, कई ग्राहक "केवल ग्राहक" हैं - उनके पास SOAP अनुरोध स्वीकार करने के लिए HTTP सर्वर नहीं हो सकता है।

   तो मालिकाना "पुश" अधिसूचना काम करने के लिए, दोनों पक्षों सर्वर की जरूरत है और दोनों अपने एसओए इंटरफेस प्रकाशित करने के लिए की जरूरत है।

   वैकल्पिक रूप से, आप ग्राहक को अधिसूचना खींच सकते हैं। ग्राहक सर्वर पर अधिसूचना अनुरोध का उपयोग कर सकता है जो या तो अवरुद्ध या मतदान कर रहा है। सर्वर अधिसूचना या कुछ भी या त्रुटि के साथ प्रतिक्रिया कर सकते हैं।

   समस्याएं/धारणाएं: (1) HTTP सर्वर (यानी एसओएपी सर्वर) नियम के रूप में ब्लॉकिंग अनुरोधों का समर्थन नहीं करते हैं, जिसका अर्थ है कि आपको मतदान करना होगा; (2) ग्राहक को आपकी अधिसूचना स्कीमा से अवगत होना चाहिए - वास्तव में ग्राहक को एसओएपी अधिसूचना अनुरोध प्राप्त करने के लिए सेवा समापन बिंदु के रूप में कार्य करने की आवश्यकता है। यह मनमाने ढंग से अज्ञात क्लाइंट के लिए दो बहुत बड़ी धारणा है - यह कुछ नहीं है SOAP "बस समर्थन करता है" दोनों सिरों को यह सब विस्तार से डिजाइन करने की आवश्यकता है।वास्तव में यह सेवा प्रकार के तरीके से करने के लिए, क्लाइंट को वास्तव में अपनी स्वयं की सेवा डब्लूएसडीएल इंटरफ़ेस घोषित करना चाहिए ताकि आप इसे आ सकें।

2. उपर्युक्त जैसा ही है, लेकिन दूसरे के एंडपॉइंट पते के दोनों तरफ सूचित करने के लिए एसओएपी हेडर में डब्ल्यूएस-एड्रेसिंग डेटा शामिल करें।

   मूल रूप से वही समस्या/अनुमान पहले विकल्प के रूप में। डब्ल्यूएस-एड्रेसिंग पते आपको समझदारी से एसओएपी संदेशों को सही यूआरएल पते पर रूट करने में मदद करेंगे, लेकिन अब और नहीं।

3. उपयोग WS-अधिसूचना

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

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

4. HTTP में समझाया यातायात के साथ एक संदेश कतार समाधान (जैसे JMS) का प्रयोग करें यह पेलोड क्लाइंट और सर्वर के बीच गुजरने वाली मालिकाना डिजाइन की आवश्यकता है वापस - दोनों पक्षों के बीच अनुबंध का गठन किया। एक फायदा यह है कि क्लाइंट एक शुद्ध ग्राहक हो सकता है, जब एक संदेश प्राप्त होने पर एक संदेश श्रोता को थ्रेड में बुलाया जाता है।

   समस्याएं/सीमाएं: (1) उपरोक्त वर्णित फायरवॉल के माध्यम से HTTP अधिसूचनाओं के साथ यह वही समस्याएं हैं। (2) क्या यह स्वयं का कार्यान्वयन है। (3) वर्तमान में उपयोग करने के बाद और अधिक तकनीक का उपयोग करता है।

अंत परिणाम:
आप अपने समाधान के कम से कम हिस्सा जरूरत है एक मालिकाना डिजाइन होने के लिए - सोप/WS मानकों अपना पूरा आवश्यकताओं को पूरा नहीं करते। सिद्धांत रूप में यह मालिकाना डिजाइन कई लेगवर्क प्रदान करने के लिए एक उत्पाद का लाभ उठा सकता है, लेकिन अधिसूचना स्कीमा डिज़ाइन को आपके द्वारा बनाया और एकीकृत करने की आवश्यकता होगी।

यदि आप पुश सूचनाएं करना चाहते हैं, आप की जरूरत सूचनाएं ग्राहक को पारित करने के लिए अनुबंध के कुछ तरह, ग्राहक एक SOA सर्वर के रूप में कार्य करने की जरूरत है, और आप की जरूरत फायरवॉल अपने यातायात के लिए openned। अधिकांश निगमों नामंज़ूर HTTP अनुरोध एक सर्वर छोड़ने और एक ग्राहक के लिए गुजर - आप सामान्य रूप से फ़ायरवॉल बंदरगाहों और फिर भी खोलने के लिए एक बहुत ही अच्छा कारण की जरूरत है, कई निगमों यह अनुमति नहीं देंगे ...

यदि आप सूचनाओं के लिए ग्राहकों को मतदान करना चाहते हैं , आपको केवल सर्वर पक्ष पर एक मूल WSDL इंटरफ़ेस की आवश्यकता है जिसे अक्सर क्लाइंट द्वारा बुलाया जा सकता है।

भविष्य विकल्प: एचटीएमएल 5 वेब सॉकेट
यदि आपका ग्राहक एक HTML5 ऐप है, तो वेब सॉकेट सक्षम सर्वर ब्राउज़र पर यातायात को धक्का दे सकते हैं - और कुछ मौके निगम फायरवॉल खोलेंगे। एसओएपी संदेश HTTP वेब सॉकेट पर यात्रा कर सकते हैं, जिससे आप अधिसूचनाओं को पुश कर सकते हैं।

Answer 2

Async क्लाइंट्स polling and callbacks के उपयोग के माध्यम से डब्लूएसडीएल आधारित सेवाओं के लिए समर्थित हैं। आपके मामले में मुझे लगता है कि आवश्यकता अपेक्षाकृत अधिक जटिल है।

ओरेकल संलयन मिडलवेयर doc page में एक परिदृश्य है जो आपकी मदद करेगा। यह एक विधि का विवरण देता है जो ग्राहकों को उन अनुरोधों को भेजने की अनुमति देता है जो HTTP 202 (स्वीकृत) उत्पन्न करते हैं और क्लाइंट संदेश कतारों पर प्रतिक्रिया के लिए प्रतीक्षा करते हैं। आपके मामले में परिदृश्य नीचे दिखाए गए एक से tweaked किया जा सकता है।

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

बेशक आप इस लागू करने के लिए ओरेकल fusionware जरूरत नहीं है। आप ग्राहक पर एक संदेश की प्राप्ति को स्वीकार करने के लिए RabbitMQ या Redis (लेनदेन के साथ) का उपयोग कर सकते हैं। यदि आपका ग्राहक अन-रजिस्टर करना चाहता है तो उसे कॉल करें और कतार सुनना बंद करें।

मैं किसी भी उद्योग मानक है कि अपने परिदृश्य फिट होगा के बारे में पता कर रहा हूँ, लेकिन मेरा मानना ​​है कि इस समाधान आप के लिए अच्छी तरह से काम करना चाहिए।

Answer 3

क्या आपने मैसेजिंग उत्पाद का उपयोग करके "पब-सब" का सरल दृष्टिकोण माना है? (जैसे एमक्यू, ईएमएस, या एक्टिवएमक्यू)

आपके द्वारा वर्णित आवश्यकताओं को "क्लासिक" अनुरोध/उत्तर सिंक/एसिंक एसओएपी वेब सेवा परिदृश्य फिट नहीं लगता है।

एक पब/उप समाधान में, ग्राहक एक बार एक विषय की सदस्यता लेता है, और प्रकाशक (आपके मामले में, सर्वर) सभी ग्राहकों को किसी भी प्रासंगिक संदेश पोस्ट कर सकता है।

बोनस के रूप में, अधिकांश संदेश उत्पादों में "टिकाऊ ग्राहक" के लिए समर्थन शामिल है, इसलिए क्लाइंट कई बार ऑफ़लाइन हो सकता है और फिर से कनेक्शन के बाद सभी संदेश प्राप्त कर सकता है।

आपके मामले में, सर्वर एक (फ्री) ActiveMQ सर्वर बना सकता है ... जो सुविधा आप ढूंढ रहे हैं उसे प्रदान करना।

यदि आप इस तरह से जाते हैं, तो मेरा सुझाव है कि आप .NET के लिए समर्थन के साथ एक जेएमएस अनुपालन उत्पाद चुनें।

Answer 4

खोज इंजन से यहां हो रही है उन लोगों के लिए:

आप वेब APIs आजकल के लिए एक WebHook, जो अनिवार्य रूप से काम करता है के रूप में ओ पी वर्णित उपयोग कर सकते हैं।

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

हो सकता है कि जावा या नेट अब तक WebHooks के लिए पुस्तकालय हैं।

उस ने कहा, एसएसई और वेबसाइटॉक मानक मानक और धक्का के साथ संगत होने पर वास्तविक धक्का और वास्तविक समय संदेश प्रदान करते हैं।

अतीत में लंबी मतदान भिन्नताओं का भी उपयोग किया जाता था, और अब कभी-कभी धूमकेतु को कुल मिलाकर कहा जाता है।