WebSockets, STOMP, SockJS और स्प्रिंग फ्रेमवर्क 4.0 के साथ सरल और स्केलेबल इवेंट सदस्यता

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

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

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

स्टॉक पोर्टफोलियो ऐप

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


हम इस तरह से एक आवेदन कैसे लागू करते हैं? HTTP और REST में, हमें यह बताने के लिए URL और HTTP तरीकों पर भरोसा करने के लिए उपयोग किया जाता है कि क्या किया जाना चाहिए। लेकिन केवल एक सॉकेट और संदेशों का एक गुच्छा है। कैसे बताएं कि संदेश किसके लिए है और इसका क्या मतलब है?


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

सरल / स्ट्रीमिंग टेक्स्ट-ओरिएंटेड मैसेजिंग प्रोटोकॉल (STOMP)

STOMP एक बहुत ही सरल मैसेजिंग प्रोटोकॉल है। HTTP पर तैयार किए गए फ़्रेम के आधार पर। एक फ्रेम में एक कमांड, वैकल्पिक हेडर और एक वैकल्पिक बॉडी होती है।

उदाहरण के लिए, स्टॉक पोर्टफोलियो एप्लिकेशन उद्धरण भेज सकता है, ग्राहक एक SUBSCRIBE फ्रेम भेजेगा, जहां "गंतव्य" शीर्षक इंगित करता है कि वास्तव में यह क्या सदस्यता ले रहा है:

SUBSCRIBE id:sub-1 destination:/topic/price.stock.* 

जैसे ही स्टॉक उद्धरण उपलब्ध होते हैं, सर्वर संबंधित "गंतव्य" और सदस्यता पहचानकर्ता के साथ एक संदेश फ्रेम भेजता है, साथ ही "सामग्री-प्रकार" हेडर और बॉडी:

 MESSAGE subscription:sub-1 message-id:wm2si1tj-4 content-type: application/json destination:/topic/stocks.PRICE.STOCK.NASDAQ.EMC {\"ticker\":\"EMC\",\"price\":24.19} 

ब्राउज़र में यह सब संयोजित करने के लिए, हम stomp.js और SockJS क्लाइंट का उपयोग करते हैं:

 var socket = new SockJS('/spring-websocket-portfolio/portfolio'); var client = Stomp.over(socket); var onConnect = function() { client.subscribe("/topic/price.stock.*", function(message) { //   }); }; client.connect('guest', 'guest', onConnect); 

यह एक गंभीर अग्रिम है! हमारे पास क्लाइंट संदेश पर एक मानक संदेश प्रारूप और समर्थन है।

अब हम आगे बढ़ सकते हैं - सर्वर की तरफ।

संदेश दलाल

संदेश-ब्रोकर एक विशिष्ट सर्वर समाधान है जहां पारंपरिक ब्रोकरों जैसे कि रैबिटएमक्यू, एक्टिवएमक्यू, आदि के बीच संदेश भेजे जाते हैं। अधिकांश, यदि सभी नहीं, तो TCP पर STOMP, कुछ समर्थन WebSocket का समर्थन करते हैं, लेकिन RabbitMQ सबसे उन्नत है, और यह SockJS के साथ भी काम करता है।

हमारी वास्तुकला इस तरह दिखाई देगी:


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

अगर हमने REST दृष्टिकोण से कुछ सीखा है, तो यह हमारे सिस्टम, डेटाबेस डिवाइस या डोमेन मॉडल के कार्यान्वयन के विवरणों को प्रकट करने के लायक नहीं है।

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

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

आवेदन + संदेश-दलाल

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


हमने इस दृष्टिकोण को चुना है। इसे बेहतर ढंग से समझाने के लिए यहां कुछ परिदृश्य हैं।

पदों का एक पोर्टफोलियो लोड हो रहा है

• ग्राहक पदों के एक पोर्टफोलियो का अनुरोध करता है
• आवेदन सदस्यता के लिए डेटा लोड और वापस करके अनुरोध को संसाधित करता है
• संदेश-ब्रोकर इस सहभागिता में शामिल नहीं है

स्टॉक कोट्स के लिए सदस्यता

• ग्राहक एक सदस्यता अनुरोध भेजता है
• एप्लिकेशन ब्रोकर को एक संदेश भेजता है
• संदेश-ब्रोकर सभी हस्ताक्षरित क्लाइंट को संदेश भेजता है

स्टॉक भाव प्राप्त करना

• QuoteService दलाल को स्टॉक उद्धरण संदेश भेजता है
• संदेश-ब्रोकर सभी हस्ताक्षरित क्लाइंट को संदेश भेजता है

लेन-देन का आयोजन

• ग्राहक एक व्यापार अनुरोध भेजता है
• आवेदन इसे संसाधित नहीं करता है, सभी लेनदेन TradeService के माध्यम से जाते हैं
• संदेश-ब्रोकर इस सहभागिता में शामिल नहीं है

अद्यतित पदों को पुनः प्राप्त करना

• TradeService ब्रोकर की कतार में स्थिति को अपडेट करने के बारे में एक संदेश भेजता है
• संदेश-दलाल क्लाइंट को एक स्थिति अपडेट भेजता है
• किसी विशिष्ट उपयोगकर्ता को संदेश भेजना नीचे विस्तार से चर्चा की गई है।

सख्ती से बोलना, संदेश ब्रोकर का उपयोग करना वैकल्पिक है। हम एक "सरल" बॉक्सिंग विकल्प प्रदान करते हैं। हालांकि, स्केलेबिलिटी के लिए एक संदेश ब्रोकर के उपयोग की सिफारिश की जाती है और जब कई एप्लिकेशन सर्वर के साथ तैनात किया जाता है।

कोड स्निपेट

आइए सर्वर और क्लाइंट कोड के कुछ उदाहरण देखें।

यह पोर्टफोलियो से पदों के एक पोर्टफोलियो के लिए एक अनुरोध है। जेएस :

 stompClient.subscribe("/app/positions", function(message) { self.portfolio().loadPositions(JSON.parse(message.body)); }); 

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

 @Controller public class PortfolioController { // ... @SubscribeEvent("/app/positions") public List<PortfolioPosition> getPortfolios(Principal principal) { String user = principal.getName(); Portfolio portfolio = this.portfolioService.findPortfolio(user); return portfolio.getPositions(); } } 

यहां पोर्टफोलियो.जेएस व्यापार अनुरोध भेजता है:

 stompClient.send("/app/trade", {}, JSON.stringify(trade)); 

सर्वर साइड पर, PortContController इसे निष्पादन के लिए पास करता है:

 @Controller public class PortfolioController { // ... @MessageMapping(value="/app/trade") public void executeTrade(Trade trade, Principal principal) { trade.setUsername(principal.getName()); this.tradeService.executeTrade(trade); } } 

PortContController उपयोगकर्ता को एक संदेश भेजकर अप्रत्याशित अपवादों को भी संभाल सकता है:

 @Controller public class PortfolioController { // ... @MessageExceptionHandler @ReplyToUser(value="/queue/errors") public String handleException(Throwable exception) { return exception.getMessage(); } } 

सभी सब्सक्राइबर ग्राहकों को संदेश भेजने के बारे में क्या? तो QuoteService भेजता कोटा:

 @Service public class QuoteService { private final MessageSendingOperations<String> messagingTemplate; @Scheduled(fixedDelay=1000) public void sendQuotes() { for (Quote quote : this.quoteGenerator.generateQuotes()) { String destination = "/topic/price.stock." + quote.getTicker(); this.messagingTemplate.convertAndSend(destination, quote); } } } 

और इसलिए TradeService ने सौदा पूरा होने के बाद एक स्थिति अपडेट भेजा:

 @Service public class TradeService { // ... @Scheduled(fixedDelay=1500) public void sendTradeNotifications() { for (TradeResult tr : this.tradeResults) { String queue = "/queue/position-updates"; this.messagingTemplate.convertAndSendToUser(tr.user, queue, tr.position); } } } 

और बस के मामले में, यदि आप रुचि रखते हैं ... हाँ, PortCortController में स्प्रिंग MVC विधियाँ हो सकती हैं (उदाहरण के लिए, @RequestMapping ), जैसा कि पहले ऑनलाइन गेम बनाने वाले डेवलपर द्वारा इस टिकट में सुझाया गया था:

और बस QuoteService और TradeService की तरह, स्प्रिंग MVC नियंत्रक विधियाँ भी संदेश पोस्ट कर सकती हैं।

वसंत अनुप्रयोगों में संदेश समर्थन

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

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

अब, इसे ध्यान में रखते हुए, हम स्टॉक पोर्टफोलियो एप्लिकेशन की आंतरिक संरचना के आरेख पर एक नज़र डाल सकते हैं:


StompWebSocketHandler प्रेषण चैनल में आने वाले क्लाइंट संदेशों को रखता है। इस चैनल के 3 सब्सक्राइबर हैं। पहला एक एनोटेट तरीकों के लिए जिम्मेदार है, दूसरा एक STOMP ब्रोकर को संदेश भेजता है, जबकि तीसरा एक व्यक्तिगत उपयोगकर्ताओं के संदेशों को गंतव्य पते को अद्वितीय नामों की एक कतार में परिवर्तित करके संसाधित करता है जिसे ग्राहक ने सब्सक्राइब किया है।

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


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

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

व्यक्तिगत उपयोगकर्ताओं को संदेश भेजना

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

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

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

 client.connect('guest', 'guest', function(frame) { var suffix = frame.headers['queue-suffix']; client.subscribe("/queue/error" + suffix, function(msg) { //   }); client.subscribe("/queue/position-updates" + suffix, function(msg) { //    }); }); 

फिर सर्वर साइड पर, आप @ReplyToUser एनोटेशन को चिह्नित विधि @MessageExceptionHandler (या किसी अन्य संदेश प्रसंस्करण विधि) में जोड़ सकते हैं और संदेश के रूप में रिटर्न मान भेज सकते हैं:

 @MessageExceptionHandler @ReplyToUser(value="/queue/errors") public String handleException(Throwable exception) { // ... } 

TradeService जैसी अन्य सभी कक्षाएं, समान प्राप्त करने के लिए मैसेजिंग टेमप्लेट का उपयोग कर सकती हैं:

 String user = "fabrice"; String queue = "/queue/position-updates"; this.messagingTemplate.convertAndSendToUser(user, queue, position); 

दोनों मामलों में, सही कतार नाम को पुनर्स्थापित करने के लिए हमारे अंदर उपयोगकर्ता कतार प्रत्यय (कॉन्फ़िगर किए गए UserQueueSuffixResolver के माध्यम से) है। फिलहाल, एक साधारण रिज़ॉल्वर का केवल एक कार्यान्वयन है। हालांकि, Redis- आधारित कार्यान्वयन को जोड़ना काफी आसान है जो उपयोगकर्ता या किसी अन्य एप्लिकेशन सर्वर से कनेक्ट होने के बावजूद फ़ंक्शन का समर्थन करेगा।

निष्कर्ष

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