सबसे पहले एक्टिविटी को देखें

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

पृष्ठभूमि की एक बिट

jBPM 3

एक बार jBPM के रूप में जावा के लिए एक ऐसी वर्कफ़्लो रूपरेखा थी । फ्रेमवर्क अच्छा था (सिद्धांत रूप में, यह अभी भी मौजूद है, लेकिन पिछले तनाव में क्यों यह बाद में स्पष्ट हो जाएगा)। मैंने इसे EmForge के पहले संस्करण को विकसित करने के दिनों में वापस इस्तेमाल किया। मुझे कई कारणों से यह रूपरेखा पसंद आई:

* आवेदन में आसान एम्बेड - वास्तव में, आप अपने आवेदन में एक जार उपनाम (निर्भरता के साथ) डाल - और आप अपने आवेदन में विन्यास प्रक्रियाओं के लिए समर्थन है;

* साफ़ एपीआई;

* परिचित तकनीक (वही हाइबरनेट);

* हाइबरनेट का उपयोग करने के परिणामस्वरूप - बड़ी संख्या में डेटाबेस के लिए समर्थन;

* डेवलपर के लिए "निकटता" - प्रक्रियाएं ग्रहण में खींची गई हैं, आप तुरंत यूनिट-टेस्ट लिख सकते हैं जो लिखित प्रक्रिया का परीक्षण करता है;

* JPDL संकेतन का उपयोग किया जाता है, हालांकि यह एक मानक नहीं था, "हर रोज़" प्रक्रियाओं का वर्णन करने के लिए सुविधाजनक था।



यह सब मुख्य रूप से डेवलपर के लिए jBPM को बहुत ही अनुकूल बनाता है, जबकि "गंभीर" आर्किटेक्ट के लिए SOA समाधान एक "खिलौना" बना रहा - jbpm में BPEL समर्थन ने जड़ नहीं ली, और यह सब किसी तरह के तुच्छ, "बचकाने" की तरह लग रहा था निर्णय - ठीक है, प्रत्येक अपने स्वयं के लिए। फिर भी, jBPM बन गया है (मुझे लगता है कि मैं गलत नहीं होगा) जावा के लिए सबसे लोकप्रिय वर्कफ़्लो समाधान।



उस संस्करण में जिसके साथ मैंने काम करना शुरू किया (jBPM 3), सब कुछ सुचारू रूप से नहीं चला - समस्याएं थीं। मैं प्रकाश डालूंगा:

* "बैसाखी" स्प्रिंग-मॉड्यूल के माध्यम से स्प्रिंग फ्रेमवर्क के साथ एकीकरण;

* हाइबरनेट के लिए अभिविन्यास - मैं अलग-अलग कार्यान्वयन के साथ काम करने की क्षमता के साथ जेपीए का उपयोग करना पसंद करूंगा (यह विकसित अनुप्रयोग में एकीकरण क्षमताओं में सुधार करेगा);

* एपीआई कार्यों और प्रक्रियाओं के "खोज" के कार्यान्वयन के लिए असुविधाजनक था - मुझे अपने स्वयं के "प्रत्यक्ष" एसक्यूएल प्रश्नों को लिखना था, अर्थात, जेबीपीएम कार्यान्वयन के अंदर चढ़ना।

* प्रक्रियाओं के विवरण में कुछ सीमाएँ थीं।



हम कुछ के साथ रखा था, कुछ लागत बैसाखी, कुछ हमारे अपने "अधिरचना" द्वारा तय किया गया था। सामान्य तौर पर - "सुधार" और "सुधार" के अगले संस्करण से उम्मीद करना तर्कसंगत होगा

jBPM 4

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

* वसंत के साथ मूल एकीकरण

* जावा कोड या वसंत घटकों के लिए प्रक्रियाओं और कॉल का अधिक सुविधाजनक विवरण;

* एपीआई अधिक सुविधाजनक खोज के लिए;

* डेटा और "इतिहास" के रनटाइम डेटाबेस में अलग भंडारण - सिद्धांत रूप में, काम को गति देना चाहिए।



सामान्य तौर पर, नए संस्करण ने एक अच्छी छाप छोड़ी - हालांकि सभी कार्यक्षमता जो जेबीपीएम 3 में मौजूद नहीं थी, जेबीपीएम 4 में थी। कमियों में से, आप शायद हाइबरनेट के लिए पिछली बाइंडिंग को विशेषता दे सकते हैं - हालांकि यह काफी संभव है कि यह समाधान राजनीतिक है - क्योंकि jBPM को jBoss के "विंग के तहत" विकसित किया गया था

activiti

खैर, कोड को वापस कर दिया गया है, आप उपयोगकर्ताओं को भी संतुष्ट कर सकते हैं - अर्थात, नए संस्करण को ध्यान में रखें। लेकिन - यह वहां नहीं था JBPM के मुख्य डेवलपर - टॉम बेयेंस रेडहैट (jBoss) को छोड़कर अल्फ्रेस्को में चले जाते हैं

नतीजतन, एक नई परियोजना, एक्टीविटी , लॉन्च की गई है। परियोजना को तुरंत संस्करण 5.0 (jBPM की निरंतरता पर संकेत) प्राप्त होता है और अब तक चरण 5.0.rc1 तक पहुंच गया है। मुख्य परिवर्तनों में से:

* हाइबरनेट को बाहर फेंक दिया जाता है - iBatis (colotitis!) के बजाय प्रयोग किया जाता है। जैसा कि मैं इसे समझता हूं, समाधान राजनीतिक है: अपाचे लाइसेंस के तहत केवल घटकों का उपयोग करना (मुझे समझ नहीं आया कि एलजीपीएल से घटकों को क्या रोका गया है - यह सिद्धांत रूप में अंतिम उत्पाद पर लाइसेंस प्रतिबंध नहीं लगाता है), प्लस अल्फ्रेस्को कुछ कारणों से हाइबरनेट से iBatis पर स्विच करता है;

* JPDL के बजाय, BPMN2 संकेतन का उपयोग किया जाता है;



मैंने एक्टीविटी और लाइफ़रे इंटीग्रेशन को लागू करने में एक्टिविटी के साथ काम किया। और यहां वर्तमान संस्करण के कुछ इंप्रेशन हैं (रिलीज़ के करीब):

* एपीआई जेबीपीएम 4 के समान था - वास्तव में, उन्होंने पैकेज और क्लास के नाम बदल दिए;

* ऐसा लगता है कि जेपीए के माध्यम से डेटाबेस के साथ काम करने के लिए एक लंबी चर्चा के बाद उन्होंने समर्थन जोड़ा - हालांकि यह आपके अपने जोखिम और जोखिम पर "प्रयोगात्मक" है (मैंने अभी तक इसकी कोशिश नहीं की है);

* अन्य कंपनियां परियोजना में शामिल हुईं - जो व्यापक समर्थन का वादा करती है (हालाँकि कई समर्थित जेबीपीएम का भी इस्तेमाल किया गया है);



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



लेकिन जैसा कि हमें मिलता है:

* समर्थित डेटाबेस की सूची को काफी कम कर दिया गया है (myBatis के पक्ष में हाइबरनेट की अस्वीकृति के कारण), साथ ही डेटाबेस का प्रकार स्वचालित रूप से निर्धारित नहीं किया गया है, योजना के उन्नयन के साथ कुछ गलतफहमी हैं;

* BPMN2 के पक्ष में jPDL की अस्वीकृति के कारण, कुछ सुविधाजनक विशेषताएं जो jPDL में थीं, वे खो गईं (उदाहरण के लिए, कार्यों से कई आउटपुट संक्रमण)। मैं मानकों का उपयोग करने के लिए हूं, लेकिन जहां भी उचित हो। एक्टिविटी डिज़ाइनर में वर्णित प्रक्रिया को एक्टीविटी के अलावा कहीं भी प्रदर्शित नहीं किया जा सकता है, इसलिए मानक यहाँ कुछ भी नहीं देता है, और जेपीडीएल रोजमर्रा के कार्यों के लिए अधिक सुविधाजनक था (बीपीएमएन अधिक अकादमिक है - और वास्तव में, एक मानव बीपीईएल है)। सामान्य तौर पर, यह स्पष्ट है कि कोई बहस कर सकता है और बहस कर सकता है - लेकिन तथ्य यह है कि - कुछ चीजें जो जेबीपीएम 4 में आसानी से की गई थीं - एक्टीविटी में नहीं की जा सकती हैं;

* कोड की गुणवत्ता मुझे बदतर लग रही थी। इसने मेरी आंख को पकड़ लिया - सेवा इंटरफ़ेस का वर्णन न केवल वस्तुओं के इंटरफेस पर काम करता है (क्योंकि यह जेबीपीएम 4 में था), बल्कि विशिष्ट कार्यान्वयन पर भी। उदाहरण के लिए, IdentitySession न केवल उपयोगकर्ता और समूह इंटरफेस के साथ काम करता है, बल्कि उनके कार्यान्वयन के साथ भी - UserEntity और GroupEity। तुलना के लिए - जेबीपीएम में एक ही वर्ग - जावाडॉक टिप्पणियों की संख्या पर ध्यान दें। यह सब मूल रूप से trifles है - लेकिन मुझे यह धारणा मिलती है कि एक्टीविटी जल्दी में विकसित की जा रही है - जो कोड की गुणवत्ता को बहुत अच्छी तरह से प्रभावित नहीं कर सकती है। (वैसे - मैं खुद को परिपूर्ण नहीं हूँ - और मैं हमेशा javadoc टिप्पणियाँ नहीं लिखता - लेकिन मुद्दा यह है कि वे jbpm में थे - लेकिन वे सक्रियता में नहीं थे)

* बहुत नई कार्यक्षमता नहीं थी (एपीआई और प्रक्रिया विकास के दृष्टिकोण से) - लेकिन जेबीपीएम में बहुत कुछ "खोया" था। यही है, यदि आप वर्तमान में jBPM 4 का उपयोग कर रहे हैं, तो मुझे Activiti पर स्विच करने का कोई कारण नहीं दिखता है।

अंत में दुखी विचार क्यों हैं?

* एक अच्छे प्रोजेक्ट के व्यवस्थित, विकासवादी विकास के बजाय, हमें रिफैक्टिंग-रीब्रांडिंग और "राजनीतिक" लीप्स की एक श्रृंखला मिलती है, जिसके परिणामस्वरूप प्रोजेक्ट (IMHO) केवल कार्यक्षमता में खो जाता है;

* jBPM अनिवार्य रूप से मृत है। मुझे संदेह है कि परियोजना अपने मुख्य डेवलपर के जाने के बाद भी जारी रहेगी, हालांकि jBoss ने jBMM 5.0 की घोषणा की

* एक ही समय में, कैसे सक्रियता जारी रहेगी पूरी तरह से स्पष्ट नहीं है। यह संभव है कि एक अच्छे इंजन के बजाय हमें दो मिलें - लेकिन वे क्या होंगे?



ठीक है - रोया - और यह पर्याप्त है। मुझे उम्मीद है कि यहां प्रस्तुत जानकारी आपको अगले प्रोजेक्ट के लिए एक वर्कफ़्लो इंजन चुनने में मदद करेगी, हालांकि अब, ईमानदार होने के लिए, मैंने खो दिया है कि क्या विकल्प सही है।