ESB

2012-10-26 44 views
9

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

मैंने कुछ शोध किया है लेकिन मुझे अभी भी यह वास्तव में नहीं मिलता है। मैं सिद्धांत के बजाय उदाहरण के द्वारा बहुत बेहतर काम करता हूं।

तो क्या कोई व्यक्ति यह दिखाने के लिए एक सरल उदाहरण दिखा सकता है कि कोई एंटरप्राइज़ सर्विस बस का उपयोग केवल एक कतार, एक वेब सेवा, फ़ाइल सिस्टम या अन्यथा क्यों करेगा?

मैं ईएसबी की क्षमताओं को बढ़ाने के लिए उदाहरण चाहता हूं जिसे किसी अन्य पारंपरिक एकीकरण विधि या कम से कम एक ही दक्षता के साथ हासिल नहीं किया जा सका।

सभी उत्तरों की बहुत सराहना की जाती है।

धन्यवाद, बॉब

उत्तर

9

इसमें कुछ समय कठोर ध्वनि करने के लिए जा रहा है, लेकिन मूल रूप से यदि आप एक ESB की जरूरत है, तो आप जानते होंगे आप एक ESB की जरूरत है।

उपयोग के अधिकांश मामलों के लिए, ईएसबी एक समाधान की तलाश में एक समाधान है। यह ज्यादातर परिदृश्यों के लिए इंजीनियर पर सॉफ्टवेयर का एक ढेर है। अधिकांश लोग बस इसे वारंट करने के लिए प्रसंस्करण की पर्याप्त विविधता नहीं करते हैं। "एंटरप्राइज़" के लिए "ई" यहां उल्लेखनीय है।

एक सरल मामले में:

tail -F server.log | grep SEVERE >> severe.log 

कि एक ESB परिदृश्य का एक उदाहरण के एक तुच्छ उदाहरण है।

"लेकिन यह सिर्फ एक यूनिक्स कमांड पाइपलाइन है!"

हां, बिल्कुल।

"ईएसबी" भाग "|" है और ">>"

ESB रन टाइम के भीतर जो आप एक साथ मॉड्यूल लिंक कर सकते हैं, यातायात की निगरानी है, डिजाइन प्रशंसक बहिष्कार की तरह whacky परिदृश्यों के सभी प्रकार के और जुड़ जाता है, आदि आदि

ESBs उल्लेखनीय हैं स्रोतों का एक समूह पढ़ने और स्थलों का एक समूह लिखने के लिए कनेक्टर्स का एक समूह होने के लिए। वे मोटे तर्क तर्कों का उपयोग करके प्रसंस्करण के लिए अधिक जटिल ग्राफ और वर्कफ़्लो बुनाई के लिए उल्लेखनीय हैं।

लेकिन क्या सबसे लोगों को आम तौर पर करते हैं:

input -> DO_STUFF -> output 
एक ESB के साथ

वे मिल:

ESB[input -> DO_STUFF -> output] 

जंगली में, सबसे पाइपलाइनों बस है कि जटिल नहीं हैं। उनके पास तर्क से एक होता है जो पुन: प्रयोज्य नहीं होता है, और लोग इसे एक ही तर्क मॉड्यूल में एक साथ ग्लोब करते हैं।

ठीक है, हेक, आप इसे पर्ल स्क्रिप्ट के साथ कर सकते हैं।

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

तो, कहें, सीएसवी आता है, एक्सएमएल में परिवर्तित हो जाता है, इसे संसाधित करता है, एक्सएमएल के रूप में इनपुट के लिए एक्सएमएल आउटपुट करता है, जो इसे मार्शल करता है, उस पर काम करता है, इसे फिर भी एक और चरण के लिए एक्सएमएल में परिवर्तित करता है। कुल्ला और दोहराएं जब तक कि सीपीयू 400% (बहु-कोर एफटीडब्लू) हिट नहीं करता।

तब कोई व्यक्ति "हे, अगर मैं इन मॉड्यूल को एक ही दिनचर्या में एक बूंद खींचता हूं, तो हम इस एक्सएमएल जंक को छोड़ देते हैं!", और आप "इनपुट -> DO_STUFF -> आउटपुट" के साथ समाप्त होते हैं। ।

बड़ी प्रणालियों के लिए, ऐसी कई वेब सेवाओं के साथ जो आरामदायक, विज्ञापन एकीकरण करने की आवश्यकता है, वे ठीक हो सकते हैं। यदि आप ऐसे व्यवसाय में हैं जो बहुत कुछ करता है, तो वे वास्तव में अच्छी तरह से काम कर सकते हैं। जब आपके पास दर्जनों पाइपलाइन हैं, तो वे उन्हें प्रबंधित करने के परिचालन पहलू में मदद कर सकते हैं।

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

यदि नहीं, तो यदि आपके पास एक इंटरफ़ेस है तो आपको खड़े होने की आवश्यकता है - फिर बस इसे करें। इसे पर्ल में, जावा में, सी # में, जो भी हो, में करें। बाहर निकलें और कुछ अजीब 100 एमबी बुनियादी ढांचे और जटिलता को स्पूल करें जो अब आप सीखने, मास्टर करने और बनाए रखने के लिए प्राप्त करते हैं।

तो, फिर, यदि आपको ईएसबी की आवश्यकता है, तो आप इसे जान लेंगे। वास्तव में। आपके पास अलग-अलग सामानों के साथ जो भी सिस्टम बनाया गया है, आप इसके साथ लड़ रहे होंगे, सहकर्मियों से बात कर रहे हैं कि यह सब कुछ क्या दर्द है, और आप किसी विक्रेता को कुछ लिंक में कुछ विक्रेता को पढ़ सकते हैं और पढ़ सकते हैं एक श्वेत पत्र और "यह है!" जाओ, लेकिन अगर आपने अभी तक ऐसा नहीं किया है, तो आप कुछ भी याद नहीं कर रहे हैं।

+0

ओवर इंजीनियरिंग के लिए +1 और" अधिकांश लोग बस इसे वारंट करने के लिए प्रसंस्करण की पर्याप्त विविधता नहीं करते हैं " – kolossus

1

@WillHartung के रूप में निष्कर्ष निकाला गया, ईएसबी बड़े, जटिल परिस्थितियों में उचित रूप से उपयोग किया जाता है। और यही कारण है कि इसे एंटरप्राइज़ सेवा बस नाम दिया गया है।

अब, वास्तव में आपके सवाल का जवाब देना, ESBs आम तौर पर:

  • कई प्रोटोकॉल पर संवाद (जैसे HTTP, संदेश कतार, आदि), दोनों इनपुट और आउटपुट

  • एक आम की स्थापना के लिए संदेश प्रारूप, और अक्सर अन्य प्रारूपों से 'कैनोनिकल' प्रारूप में अनुवाद करते हैं

  • एंडपॉइंट पारदर्शिता प्रदान करें (उदाहरण के लिए आप बस को एक संदेश भेजते हैं, और एक उत्तर वापस प्राप्त करते हैं, लेकिन आप स्पष्ट रूप से नहीं जानते कि कौन सी सेवा उपाध्यक्ष, बस से जुड़ा हुआ, आपके अनुरोध को संभाला।

  • प्रदान करें निगरानी और प्रबंधन क्षमताओं

  • सेवाओं और संदेशों

  • सुरक्षा, लागू जब जरूरत के संस्करण की सुविधा प्रदान करना।

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

3

ईएसबी उन मामलों के लिए है जहां आपके पास एक ही सिस्टम में वह वेब सेवा और कतार और फ़ाइल सिस्टम है और उन्हें एकीकृत करने की आवश्यकता है। एक ESB उत्पाद आमतौर पर निम्नलिखित

  1. सुरक्षा
  2. संदेश मार्ग
  3. आर्केस्ट्रा (जो उन्नत संदेश मार्ग है)
  4. प्रोटोकॉल परिवर्तन
  5. संदेश परिवर्तन
  6. निगरानी
  7. ईवेंटीग
  8. हल करती है

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

0

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

आप एक ईएसबी का उपयोग करते हैं।

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

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

4

इससे आपको ईएसबी की अवधारणा को समझने में मदद मिलेगी।

A Buyers Guide to an Enterprise Service Bus (ESB) यह ईएसबी के बारे में एक क्रिस्टल स्पष्ट विचार प्रदान करेगा।

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

इस सत्र में महत्वपूर्ण कारकों को ध्यान में रखा है जिनमें से कुछ की जरूरत है कि के एक सिंहावलोकन प्रदान करेगा में शामिल हैं -

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