आधुनिक जावा प्रौद्योगिकियों (आराम/एसओएपी/ईजेबी)

Question

पर कोर्बा एप्लिकेशन माइग्रेट करना मुझे किसी भी नवीनतम जावा तकनीक में विरासत कोर्बा सिस्टम माइग्रेट करने की आवश्यकता है। मुझे जिस मुख्य समस्या का सामना करना पड़ रहा है वह प्रस्तावित प्रणाली में लंबे समय तक रहने वाले लेनदेन (डीबी) प्रदान करना है। वर्तमान में क्लाइंट (स्विंग ऐप) कॉरबा सेवा ऑब्जेक्ट को बनाए रखता है और वास्तव में सभी टीएक्सएन को वापस/रोलिंग करने से पहले एकाधिक डीबी टीएक्सएन करता है। सेवा परत लेनदेन को पूरा करने के लिए कनेक्शन ऑब्जेक्ट की स्थिति को बनाए रखती है।

मैं इस तंत्र को अपने नए सिस्टम (आरईएसटी/डब्ल्यूएस) में पुन: उत्पन्न करना चाहता था ताकि या तो स्विंग क्लाइंट/वेब (भविष्य) उसी तरह काम कर सके।

जैसे:

try { 
    service1.updateXXData(); // --> insert in to table XX 
    service2.updateUUData() //--> insert in to table UU 
    service1.updateZZData(); // --> insert in to table ZZ 
    service2.updateAAData(); // --> insert in to table AA 

    service1.commit(); // con.commmit(); 
    service2.commit(); // con.commmit(); 

} 
exception(){ 
    service1.rollback(); // con.rollback(); 
    service2.rollback(); // con.rollback(); 
} 

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

मेरे लिए उपलब्ध विकल्पों में से

जोड़ी

1. माइग्रेट RMI के लिए CORBA हैं -> ताकि मौजूदा प्रणाली में आवश्यक परिवर्तन बहुत कम हैं, लेकिन लेन-देन प्रबंधन, कनेक्शन पूलिंग, को बनाए रखना राज्य मेरी स्वयं की ज़रूरत है।

2. स्टेटबिल ईजेबी को कॉरबा माइग्रेट करें -> आरएमआई की तुलना में अधिक परिवर्तनों की तुलना करें, लेकिन बेहतर है क्योंकि मैं कंटेनर प्रबंधित कनेक्शन पूलिंग का उपयोग कर सकता हूं, बेहतर तरीके से राज्य को बनाए रख सकता हूं।

3. माइग्रेट CORBA स्टेटफुल वेब सेवा करने के लिए (SOAP) -> और अधिक भविष्य है, लेकिन आवश्यक परिवर्तन की बहुत - कैसे कभी मैं डबल्यूएसडीएल को आईडीएल में बदल सकते हैं, और कार्यान्वयन परत करने के लिए कॉल को सौंपने

4. माइग्रेट CORBA आराम -> यदि संभव हो तो सबसे वांछित - लेकिन माइग्रेट करने के लिए आवश्यक समय की मात्रा बहुत बड़ी है, कोड परिवर्तनों को UI परत से सेवा परत तक की आवश्यकता होगी।

अग्रिम

Answer 1

जिस क्रम में मैं विकल्प का चयन करेंगे, सबसे खराब करने के लिए सबसे अच्छा से, हो सकता है 4, 3, 2, और 1, हालांकि मैं स्टेटफुल सेम से बचने चाहते हैं में आपको बहुत बहुत धन्यवाद या सेवाओं को मानव रूप से ऐसा करने के लिए संभव है।

मैं आपको विस्तार से क्या करना होगा इसके कार्यान्वयन विवरण पर जाउंगा।

इनमें से किसी भी समाधान के लिए, आपको XA-compliant data sources and transactions का उपयोग करना होगा ताकि आप एसीआईडी ​​अनुपालन, preferably from an application server so you don't have to generate the transaction yourself की गारंटी दे सकें। यह आपके मौजूदा आवेदन से एक सुधार होना चाहिए क्योंकि यह लगभग निश्चित रूप से इसकी गारंटी नहीं दे सकता है, लेकिन सलाह दी जानी चाहिए कि मेरे अनुभव में, लोगों ने अनिवार्य रूप से जेटीए को फिर से शुरू करने के लिए हैक का भार रखा है, इसलिए इसके लिए देखें।

4 के लिए, आप container-managed transactions with XA का उपयोग करना चाहेंगे। आप इसे injecting a @PersistenceContext backed by a JTA connection द्वारा कर सकते हैं। हां, यह समय, परीक्षण और प्रयास का एक टन खर्च करता है, लेकिन इसमें दो बोनस हैं: सबसे पहले, वेब पर जाने से बहुत आसान हो जाएगा, और ऐसा लगता है कि वह समय आ रहा है। दूसरा, जो आपके बाद आते हैं वे नॉर कोर्बा और आरएमआई की तुलना में नई वेब सेवा प्रौद्योगिकियों में अच्छी तरह से परिचित होने की संभावना रखते हैं।

3 के लिए, आप container-managed transactions with XA का उपयोग भी करना चाहेंगे। एसओएपी मेरी पहली पसंद नहीं होगी क्योंकि यह बहुत वर्बोज़ संदेश का उपयोग करता है और आरईएसटी अधिक लोकप्रिय है, लेकिन यह किया जा सकता है।यदि यह राज्यपूर्ण है, तो आपको bean-managed transactions instead और फिर hang on to resources across web service calls का उपयोग करना होगा। यह खतरनाक है, क्योंकि यह पूरी प्रणाली को संभावित रूप से खराब कर सकता है।

2 के लिए, आप stateless session facade for a stateful EJB का उपयोग कर container-managed transactions with XA का उपयोग करके दो तरीकों से जा सकते हैं। आप use a client JAR for your EJB और स्विंग ऐप के साथ पैकेज कर सकते हैं। स्टेटलेस मुखौटा का उपयोग करना बेहतर है, क्योंकि इससे आपके एप्लिकेशन सर्वर पर लोड कम हो जाएगा। ध्यान रखें कि आप web services from stateless EJB beans भी उत्पन्न कर सकते हैं, अनिवार्य रूप से इसे # 3 में बदल सकते हैं।

1 के लिए ... अच्छा, शुभकामनाएं। use RMI to interface with EJB's करना संभव है, और अपना स्वयं का स्टब और टाई उत्पन्न करें, हालांकि इसकी अनुशंसा नहीं की जाती है, और बहुत अच्छे कारण के लिए। यह वर्षों के लिए एक लोकप्रिय अभ्यास नहीं रहा है, समय-समय पर पुन: उत्पन्न होने के लिए स्टब्स और संबंधों की आवश्यकता हो सकती है, और ऐप सर्वर के निम्न-स्तरीय कार्यों की समझ की आवश्यकता हो सकती है। यहां तक ​​कि, आप एक्सए लेनदेन चाहते हैं। यदि संभव हो, तो आप लेनदेन प्रबंधन को स्वयं संभाल नहीं लेना चाहते हैं।

आखिरकार, जैसा कि मुझे यकीन है कि सभी सहमत होंगे, पसंद यह है कि क्या करना है, और ऊपर बताई गई राय के बावजूद कोई "सही" या "गलत" तरीका नहीं है। यदि यह मेरे थे (और यह नहीं है), मैं अपने आप को और अपने ग्राहक के दो महत्वपूर्ण सवाल पूछने चाहते हैं:

1. इस एक अनुबंध या अस्थायी सगाई के लिए है, और अवधि यदि ऐसा है तो क्या है? क्या मुझे पहले उसी सिस्टम के लिए एक और अनुबंध में चुनना होगा जब वे अतिरिक्त अपडेट चाहते हैं? (दूसरे शब्दों में, मैं इस बनाम से कितना पैसा निकालने जा रहा हूं। मैं कितना समय व्यतीत कर रहा हूं? यदि यह एक लंबी अवधि होगी, तो मैं 4 या 3 के साथ जाऊंगा, अन्यथा 3 या 2 बेहतर होगा ।)

2. क्यों कॉर्बा से छुटकारा पाएं? "क्योंकि यह पुराना है" एक ईमानदार जवाब है, लेकिन "पुरानी गर्मता" से छुटकारा पाने का उत्साह क्या है? क्या वे भविष्य में इस प्रणाली के उपयोग को बढ़ाने की योजना बना रहे हैं? क्या समाप्त होने के बारे में कुछ लाइसेंस है और वे सिर्फ रोशनी रखना चाहते हैं? ऐसा इसलिए है क्योंकि वे इसे कुछ छोटे प्रोग्रामर पर डंप नहीं करना चाहते हैं जो शायद इस तरह की निम्न-स्तरीय सामग्री से निपटने के बारे में नहीं जानते? आप सिस्टम को दो साल, पांच साल या उससे अधिक समय में क्या करना चाहते हैं?

(ठीक है, इतना है कि दो से अधिक सवाल है: डी)