2009-04-23 17 views
5

मान लीजिए कि मेरे पास कई व्यावसायिक घटकों (ग्राहक अनुप्रयोगों, नेटवर्क, भुगतान इत्यादि) के बीच मध्यस्थता अनुरोधों का मध्यस्थता है। मिडलवेयर स्टैक ऑर्केस्ट्रेशन, रूटिंग, ट्रांसफॉर्मेशन और अन्य सामान (ग्रेगोर होपे द्वारा एंटरप्राइज़ इंटीग्रेशन पैटर्न बुक के समान) के लिए ज़िम्मेदार है।क्या मिडलवेयर ऐप्स को व्यावसायिक तर्क करने की आवश्यकता है?

मेरा प्रश्न है: क्या यह बिज़नेस लॉजिक को मिडलवेयर पर रखने के लिए अच्छा डिजाइन है?

मान लें कि मेरा ऐप ए मिडलवेयर से कुछ ग्राहक डेटा का अनुरोध करता है। लेकिन इस डेटा को प्राप्त करने के लिए, मुझे ग्राहक आईडी और कुछ अन्य पैरामीटर प्रदान करना होगा। इस पैरामीटर को प्राप्त करने के लिए अनुरोध करने वाले ऐप द्वारा किया जाना चाहिए या 'सुविधा' के लिए जिम्मेदार मिडलवेयर है और ग्राहक आईडी प्राप्त करने वाला इंटरफ़ेस प्रदान करता है और आंतरिक रूप से अन्य पैरामीटर प्राप्त करता है?

मुझे एहसास है कि यह एक साधारण सवाल नहीं है (व्यापार तर्क की परिभाषा के कारण), लेकिन मैं सोच रहा था कि यह एक सामान्य दृष्टिकोण या कुछ दिशानिर्देश हैं।

उत्तर

2

यह "समग्र आवेदन" पैटर्न है; एक सेवा उन्मुख वास्तुकला का दिल। यही कारण है कि ईएसबी विक्रेता बेच रहे हैं: अतिरिक्त व्यवसाय तर्क कहीं भी एक ऐसा तरीका जो मौजूदा अनुप्रयोगों से एक समग्र अनुप्रयोग बनाता है।

यह आसान नहीं है क्योंकि आपका समग्र एप्लिकेशन सिर्फ रूटिंग नहीं है। यह रूटिंग के शीर्ष पर एक उचित नया समग्र लेनदेन है।

संकेत। बहुत आगे जाने से पहले एक अच्छा ईएसबी प्राप्त करने के लिए देखो। यह तेजी से नियंत्रण से बाहर हो जाता है और कुछ अतिरिक्त समर्थन सहायक होता है। यहां तक ​​कि यदि आप सूर्य के JCAPS या Open ESB जैसे कुछ नहीं खरीदते हैं, तो भी आपको खुशी होगी कि आपने यह सीखा है कि यह क्या करता है और वे जटिल समग्र अनुप्रयोगों को कैसे व्यवस्थित करते हैं।

+0

कठिन हिस्सा उत्तरदायित्व है: किसके लिए जिम्मेदार होना चाहिए। मेरा मानना ​​है कि यह एक सांस्कृतिक समस्या essencialy है। बीटीडब्ल्यू, मेरा प्रश्न पूरी तरह से काल्पनिक था, जिस परियोजना में मैं पहले से ही पूरी तरह से समाप्त हो चुका हूं, और हम एक अच्छा मिडलवेयर उत्पाद का उपयोग कर रहे हैं। –

+1

कठिन भाग को "शासन" कहा जाता है और इसमें उत्तरदायित्व के साथ-साथ नियंत्रण नियंत्रण और तकनीकी मानकों को भी शामिल किया जाता है। यह "सांस्कृतिक" नहीं है - यह उससे बड़ा है - और यह आमतौर पर बहुत कठिन होता है। –

0

मिडलवेयर एप्लिकेशन को यह करना चाहिए। सिस्टम ए को यह नहीं पता होना चाहिए कि दूसरा पैरामीटर मौजूद है, और निश्चित रूप से इसे प्राप्त करने के बारे में कोई जानकारी नहीं होगी।

1

ऑर्केस्ट्रेशन, रूटिंग और ट्रांसफॉर्मेशन।

आप इनमें से कोई भी तकनीकी कारणों से यादृच्छिक रूप से या मस्ती के लिए ऐसा नहीं करते हैं, तो आप ऐसा इसलिए करते हैं क्योंकि आपके पास कुछ व्यावसायिक आवश्यकता है - ergo में व्यापार तर्क शामिल है।

एकमात्र चीज जो आप एक पूर्ण व्यवसाय प्रणाली के लिए गायब हैं, गणना और रिपोर्टिंग है (मान लीजिए कि आपके पास पहले से ही सुरक्षा है!)।

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

टर्मिनोलिजी के रूप में 'बिजनेस लॉजिक' की पसंद बहुत खराब थी और इससे डिजाइन और वास्तुकला के अंतहीन विकृतियां हुईं।

व्यवसाय तर्क द्वारा सबसे अच्छे डिजाइनर/आर्किटेक्ट का मतलब गणना और विश्लेषण है।

यदि आप "% s/व्यापार तर्क/गणना/जी" अधिकांश वास्तुशिल्प संपादकों को अधिक समझ में आता है।

4

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