ਬੀਪੀਐਮ ਸਟਾਈਲ ਏਕੀਕਰਣ

ਹੈਲੋ, ਹਬਰ!

ਸਾਡੀ ਕੰਪਨੀ ਈਆਰਪੀ-ਸ਼੍ਰੇਣੀ ਦੇ ਸੌਫਟਵੇਅਰ ਹੱਲਾਂ ਦੇ ਵਿਕਾਸ ਵਿੱਚ ਮੁਹਾਰਤ ਰੱਖਦੀ ਹੈ, ਜਿਸਦਾ ਵੱਡਾ ਹਿੱਸਾ ਵਪਾਰਕ ਤਰਕ ਅਤੇ ਦਸਤਾਵੇਜ਼ ਪ੍ਰਵਾਹ ਇੱਕ ਲਾ EDMS ਦੇ ਨਾਲ ਟ੍ਰਾਂਜੈਕਸ਼ਨਲ ਪ੍ਰਣਾਲੀਆਂ ਦੁਆਰਾ ਕਬਜ਼ਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਸਾਡੇ ਉਤਪਾਦਾਂ ਦੇ ਮੌਜੂਦਾ ਸੰਸਕਰਣ JavaEE ਤਕਨਾਲੋਜੀਆਂ 'ਤੇ ਅਧਾਰਤ ਹਨ, ਪਰ ਅਸੀਂ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਦੇ ਨਾਲ ਸਰਗਰਮੀ ਨਾਲ ਪ੍ਰਯੋਗ ਵੀ ਕਰ ਰਹੇ ਹਾਂ। ਅਜਿਹੇ ਹੱਲਾਂ ਦੇ ਸਭ ਤੋਂ ਵੱਧ ਸਮੱਸਿਆ ਵਾਲੇ ਖੇਤਰਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ ਨੇੜਲੇ ਡੋਮੇਨਾਂ ਨਾਲ ਸਬੰਧਤ ਵੱਖ-ਵੱਖ ਉਪ-ਪ੍ਰਣਾਲੀਆਂ ਦਾ ਏਕੀਕਰਣ। ਏਕੀਕਰਣ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੇ ਹਮੇਸ਼ਾ ਸਾਨੂੰ ਇੱਕ ਬਹੁਤ ਵੱਡਾ ਸਿਰਦਰਦ ਦਿੱਤਾ ਹੈ, ਭਾਵੇਂ ਅਸੀਂ ਆਰਕੀਟੈਕਚਰਲ ਸਟਾਈਲ, ਤਕਨਾਲੋਜੀ ਸਟੈਕ ਅਤੇ ਫਰੇਮਵਰਕ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ, ਪਰ ਹਾਲ ਹੀ ਵਿੱਚ ਅਜਿਹੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਵਿੱਚ ਤਰੱਕੀ ਹੋਈ ਹੈ।

ਲੇਖ ਵਿੱਚ ਜੋ ਮੈਂ ਤੁਹਾਡੇ ਧਿਆਨ ਵਿੱਚ ਲਿਆਉਂਦਾ ਹਾਂ, ਮੈਂ ਉਸ ਅਨੁਭਵ ਅਤੇ ਆਰਕੀਟੈਕਚਰਲ ਖੋਜ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗਾ ਜੋ NPO ਕ੍ਰਿਸਟਾ ਦੁਆਰਾ ਮਨੋਨੀਤ ਖੇਤਰ ਵਿੱਚ ਹੈ। ਅਸੀਂ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਡਿਵੈਲਪਰ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ ਇੱਕ ਏਕੀਕਰਣ ਸਮੱਸਿਆ ਦੇ ਇੱਕ ਸਧਾਰਨ ਹੱਲ ਦੀ ਇੱਕ ਉਦਾਹਰਣ ਵੀ ਦੇਖਾਂਗੇ ਅਤੇ ਇਹ ਪਤਾ ਲਗਾਵਾਂਗੇ ਕਿ ਇਸ ਸਾਦਗੀ ਦੇ ਪਿੱਛੇ ਕੀ ਛੁਪਿਆ ਹੋਇਆ ਹੈ।

ਬੇਦਾਅਵਾ

ਲੇਖ ਵਿੱਚ ਵਰਣਿਤ ਆਰਕੀਟੈਕਚਰਲ ਅਤੇ ਤਕਨੀਕੀ ਹੱਲ ਮੇਰੇ ਦੁਆਰਾ ਵਿਸ਼ੇਸ਼ ਕਾਰਜਾਂ ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਨਿੱਜੀ ਅਨੁਭਵ ਦੇ ਅਧਾਰ ਤੇ ਪ੍ਰਸਤਾਵਿਤ ਹਨ। ਇਹ ਹੱਲ ਸਰਵ ਵਿਆਪਕ ਹੋਣ ਦਾ ਦਾਅਵਾ ਨਹੀਂ ਕਰਦੇ ਹਨ ਅਤੇ ਵਰਤੋਂ ਦੀਆਂ ਹੋਰ ਸ਼ਰਤਾਂ ਅਧੀਨ ਅਨੁਕੂਲ ਨਹੀਂ ਹੋ ਸਕਦੇ ਹਨ।

ਬੀਪੀਐਮ ਦਾ ਇਸ ਨਾਲ ਕੀ ਲੈਣਾ ਦੇਣਾ ਹੈ?

ਇਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇਣ ਲਈ, ਸਾਨੂੰ ਸਾਡੇ ਹੱਲਾਂ ਦੀਆਂ ਲਾਗੂ ਸਮੱਸਿਆਵਾਂ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਿੱਚ ਥੋੜਾ ਡੂੰਘਾਈ ਨਾਲ ਜਾਣ ਦੀ ਲੋੜ ਹੈ। ਸਾਡੇ ਆਮ ਟ੍ਰਾਂਜੈਕਸ਼ਨਲ ਸਿਸਟਮ ਵਿੱਚ ਵਪਾਰਕ ਤਰਕ ਦਾ ਮੁੱਖ ਹਿੱਸਾ ਉਪਭੋਗਤਾ ਇੰਟਰਫੇਸ ਦੁਆਰਾ ਡੇਟਾਬੇਸ ਵਿੱਚ ਡੇਟਾ ਦਾਖਲ ਕਰਨਾ, ਇਸ ਡੇਟਾ ਦੀ ਮੈਨੂਅਲ ਅਤੇ ਸਵੈਚਲਿਤ ਤਸਦੀਕ ਕਰਨਾ, ਇਸਨੂੰ ਕੁਝ ਵਰਕਫਲੋ ਦੁਆਰਾ ਪੂਰਾ ਕਰਨਾ, ਇਸਨੂੰ ਕਿਸੇ ਹੋਰ ਸਿਸਟਮ / ਵਿਸ਼ਲੇਸ਼ਣਾਤਮਕ ਡੇਟਾਬੇਸ / ਆਰਕਾਈਵ ਵਿੱਚ ਪ੍ਰਕਾਸ਼ਤ ਕਰਨਾ, ਰਿਪੋਰਟਾਂ ਤਿਆਰ ਕਰਨਾ . ਇਸ ਤਰ੍ਹਾਂ, ਗਾਹਕਾਂ ਲਈ ਸਿਸਟਮ ਦਾ ਮੁੱਖ ਕੰਮ ਉਹਨਾਂ ਦੀਆਂ ਅੰਦਰੂਨੀ ਕਾਰੋਬਾਰੀ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦਾ ਸਵੈਚਾਲਨ ਹੈ।

ਸਹੂਲਤ ਲਈ, ਅਸੀਂ ਸੰਚਾਰ ਵਿੱਚ "ਦਸਤਾਵੇਜ਼" ਸ਼ਬਦ ਦੀ ਵਰਤੋਂ ਇੱਕ ਆਮ ਕੁੰਜੀ ਦੁਆਰਾ ਸੰਯੁਕਤ ਡੇਟਾ ਦੇ ਇੱਕ ਸਮੂਹ ਦੇ ਕੁਝ ਐਬਸਟਰੈਕਸ਼ਨ ਵਜੋਂ ਕਰਦੇ ਹਾਂ ਜਿਸ ਨਾਲ ਇੱਕ ਖਾਸ ਵਰਕਫਲੋ "ਲਿੰਕ" ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
ਪਰ ਏਕੀਕਰਣ ਤਰਕ ਬਾਰੇ ਕੀ? ਆਖਰਕਾਰ, ਏਕੀਕਰਣ ਕਾਰਜ ਸਿਸਟਮ ਦੇ ਆਰਕੀਟੈਕਚਰ ਦੁਆਰਾ ਤਿਆਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜੋ ਕਿ ਗਾਹਕ ਦੀ ਬੇਨਤੀ 'ਤੇ ਨਹੀਂ, ਪਰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੱਖ-ਵੱਖ ਕਾਰਕਾਂ ਦੇ ਪ੍ਰਭਾਵ ਅਧੀਨ ਹਿੱਸਿਆਂ ਵਿੱਚ "ਕੱਟਿਆ" ਜਾਂਦਾ ਹੈ:

• ਕੋਨਵੇ ਦੇ ਕਾਨੂੰਨ ਦੇ ਅਧੀਨ;
• ਦੂਜੇ ਉਤਪਾਦਾਂ ਲਈ ਪਹਿਲਾਂ ਵਿਕਸਤ ਕੀਤੇ ਉਪ-ਪ੍ਰਣਾਲੀਆਂ ਦੀ ਮੁੜ ਵਰਤੋਂ ਦੇ ਨਤੀਜੇ ਵਜੋਂ;
• ਆਰਕੀਟੈਕਟ ਦੇ ਵਿਵੇਕ 'ਤੇ, ਗੈਰ-ਕਾਰਜਸ਼ੀਲ ਲੋੜਾਂ ਦੇ ਆਧਾਰ 'ਤੇ।

ਏਕੀਕਰਣ ਤਰਕ ਨੂੰ ਮੁੱਖ ਵਰਕਫਲੋ ਦੇ ਵਪਾਰਕ ਤਰਕ ਤੋਂ ਵੱਖ ਕਰਨ ਦਾ ਇੱਕ ਬਹੁਤ ਵੱਡਾ ਪਰਤਾਵਾ ਹੈ, ਤਾਂ ਜੋ ਏਕੀਕਰਣ ਕਲਾਤਮਕ ਚੀਜ਼ਾਂ ਨਾਲ ਵਪਾਰਕ ਤਰਕ ਨੂੰ ਪ੍ਰਦੂਸ਼ਿਤ ਨਾ ਕੀਤਾ ਜਾ ਸਕੇ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਡਿਵੈਲਪਰ ਨੂੰ ਸਿਸਟਮ ਦੇ ਆਰਕੀਟੈਕਚਰਲ ਲੈਂਡਸਕੇਪ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਿੱਚ ਖੋਜ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਤੋਂ ਬਚਾਇਆ ਜਾ ਸਕੇ। ਇਸ ਪਹੁੰਚ ਦੇ ਬਹੁਤ ਸਾਰੇ ਫਾਇਦੇ ਹਨ, ਪਰ ਅਭਿਆਸ ਇਸਦੀ ਬੇਅਸਰਤਾ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ:

• ਏਕੀਕਰਣ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨਾ ਮੁੱਖ ਵਰਕਫਲੋ ਨੂੰ ਲਾਗੂ ਕਰਨ ਵਿੱਚ ਸੀਮਤ ਵਿਸਤਾਰ ਬਿੰਦੂਆਂ ਦੇ ਕਾਰਨ ਸਿੰਕ੍ਰੋਨਸ ਕਾਲਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਸਧਾਰਨ ਵਿਕਲਪਾਂ 'ਤੇ ਵਾਪਸ ਆਉਂਦਾ ਹੈ (ਸਮਕਾਲੀ ਏਕੀਕਰਣ ਦੇ ਨੁਕਸਾਨਾਂ ਦੀ ਹੇਠਾਂ ਚਰਚਾ ਕੀਤੀ ਗਈ ਹੈ);
• ਜਦੋਂ ਕਿਸੇ ਹੋਰ ਉਪ-ਸਿਸਟਮ ਤੋਂ ਫੀਡਬੈਕ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਤਾਂ ਏਕੀਕਰਣ ਕਲਾਤਮਕ ਚੀਜ਼ਾਂ ਅਜੇ ਵੀ ਮੁੱਖ ਕਾਰੋਬਾਰੀ ਤਰਕ ਨੂੰ ਪਾਰ ਕਰਦੀਆਂ ਹਨ;
• ਐਪਲੀਕੇਸ਼ਨ ਡਿਵੈਲਪਰ ਏਕੀਕਰਣ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦਾ ਹੈ ਅਤੇ ਵਰਕਫਲੋ ਨੂੰ ਬਦਲ ਕੇ ਇਸਨੂੰ ਆਸਾਨੀ ਨਾਲ ਤੋੜ ਸਕਦਾ ਹੈ;
• ਉਪਭੋਗਤਾ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ ਸਿਸਟਮ ਇੱਕ ਸਿੰਗਲ ਬਣਨਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ, ਸਬ-ਸਿਸਟਮ ਦੇ ਵਿਚਕਾਰ "ਸੀਮਜ਼" ਧਿਆਨ ਦੇਣ ਯੋਗ ਬਣ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਬੇਲੋੜੇ ਉਪਭੋਗਤਾ ਓਪਰੇਸ਼ਨ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ, ਇੱਕ ਉਪ-ਸਿਸਟਮ ਤੋਂ ਦੂਜੇ ਵਿੱਚ ਡੇਟਾ ਦੇ ਟ੍ਰਾਂਸਫਰ ਨੂੰ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋਏ।

ਇੱਕ ਹੋਰ ਪਹੁੰਚ ਹੈ ਏਕੀਕਰਣ ਪਰਸਪਰ ਪ੍ਰਭਾਵ ਨੂੰ ਕੋਰ ਕਾਰੋਬਾਰੀ ਤਰਕ ਅਤੇ ਵਰਕਫਲੋ ਦੇ ਇੱਕ ਅਨਿੱਖੜਵੇਂ ਹਿੱਸੇ ਵਜੋਂ ਵਿਚਾਰਨਾ। ਐਪਲੀਕੇਸ਼ਨ ਡਿਵੈਲਪਰ ਯੋਗਤਾਵਾਂ ਨੂੰ ਅਸਮਾਨ ਛੂਹਣ ਤੋਂ ਰੋਕਣ ਲਈ, ਨਵੇਂ ਏਕੀਕਰਣ ਪਰਸਪਰ ਕ੍ਰਿਆਵਾਂ ਨੂੰ ਬਣਾਉਣਾ ਆਸਾਨ ਅਤੇ ਆਸਾਨ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਇੱਕ ਹੱਲ ਚੁਣਨ ਦੇ ਘੱਟੋ-ਘੱਟ ਮੌਕੇ ਦੇ ਨਾਲ। ਇਹ ਇਸ ਤੋਂ ਵੱਧ ਕਰਨਾ ਔਖਾ ਹੈ: ਟੂਲ ਇੰਨਾ ਸ਼ਕਤੀਸ਼ਾਲੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਉਹ ਉਪਭੋਗਤਾ ਨੂੰ "ਆਪਣੇ ਆਪ ਨੂੰ ਪੈਰਾਂ ਵਿੱਚ ਗੋਲੀ ਮਾਰਨ" ਦੀ ਇਜਾਜ਼ਤ ਦਿੱਤੇ ਬਿਨਾਂ, ਇਸਦੀ ਵਰਤੋਂ ਲਈ ਲੋੜੀਂਦੇ ਵੱਖ-ਵੱਖ ਵਿਕਲਪ ਪ੍ਰਦਾਨ ਕਰ ਸਕੇ। ਬਹੁਤ ਸਾਰੇ ਸਵਾਲ ਹਨ ਜੋ ਇੱਕ ਇੰਜੀਨੀਅਰ ਨੂੰ ਏਕੀਕਰਣ ਕਾਰਜਾਂ ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਜਵਾਬ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ, ਪਰ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਡਿਵੈਲਪਰ ਨੂੰ ਆਪਣੇ ਰੋਜ਼ਾਨਾ ਦੇ ਕੰਮ ਵਿੱਚ ਇਸ ਬਾਰੇ ਨਹੀਂ ਸੋਚਣਾ ਚਾਹੀਦਾ ਹੈ: ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਸੀਮਾਵਾਂ, ਇਕਸਾਰਤਾ, ਪ੍ਰਮਾਣੂ, ਸੁਰੱਖਿਆ, ਸਕੇਲਿੰਗ, ਲੋਡ ਅਤੇ ਸਰੋਤ ਵੰਡ, ਰੂਟਿੰਗ, ਮਾਰਸ਼ਲਿੰਗ, ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਅਤੇ ਸਵਿਚਿੰਗ ਪ੍ਰਸੰਗ, ਆਦਿ। ਐਪਲੀਕੇਸ਼ਨ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਕਾਫ਼ੀ ਸਧਾਰਨ ਹੱਲ ਟੈਂਪਲੇਟਸ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ ਜਿਸ ਵਿੱਚ ਅਜਿਹੇ ਸਾਰੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਪਹਿਲਾਂ ਹੀ ਲੁਕੇ ਹੋਏ ਹਨ। ਇਹ ਟੈਂਪਲੇਟਸ ਕਾਫ਼ੀ ਸੁਰੱਖਿਅਤ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ: ਵਪਾਰਕ ਤਰਕ ਬਹੁਤ ਅਕਸਰ ਬਦਲਦਾ ਹੈ, ਜੋ ਗਲਤੀਆਂ ਨੂੰ ਪੇਸ਼ ਕਰਨ ਦੇ ਜੋਖਮ ਨੂੰ ਵਧਾਉਂਦਾ ਹੈ, ਗਲਤੀਆਂ ਦੀ ਕੀਮਤ ਕਾਫ਼ੀ ਘੱਟ ਪੱਧਰ 'ਤੇ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।

ਪਰ ਬੀਪੀਐਮ ਦਾ ਇਸ ਨਾਲ ਕੀ ਲੈਣਾ ਦੇਣਾ ਹੈ? ਵਰਕਫਲੋ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਬਹੁਤ ਸਾਰੇ ਵਿਕਲਪ ਹਨ...
ਵਾਸਤਵ ਵਿੱਚ, ਵਪਾਰਕ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦਾ ਇੱਕ ਹੋਰ ਲਾਗੂਕਰਨ ਸਾਡੇ ਹੱਲਾਂ ਵਿੱਚ ਬਹੁਤ ਮਸ਼ਹੂਰ ਹੈ - ਇੱਕ ਰਾਜ ਪਰਿਵਰਤਨ ਚਿੱਤਰ ਦੀ ਘੋਸ਼ਣਾਤਮਕ ਪਰਿਭਾਸ਼ਾ ਅਤੇ ਪਰਿਵਰਤਨ ਲਈ ਵਪਾਰਕ ਤਰਕ ਦੇ ਨਾਲ ਹੈਂਡਲਰ ਦੇ ਕਨੈਕਸ਼ਨ ਦੁਆਰਾ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਰਾਜ ਜੋ ਵਪਾਰਕ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ "ਦਸਤਾਵੇਜ਼" ਦੀ ਮੌਜੂਦਾ ਸਥਿਤੀ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ, ਉਹ "ਦਸਤਾਵੇਜ਼" ਦਾ ਇੱਕ ਗੁਣ ਹੈ।

ਇਹ ਉਹ ਹੈ ਜੋ ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਦੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਪ੍ਰਕਿਰਿਆ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ

ਇਸ ਲਾਗੂ ਕਰਨ ਦੀ ਪ੍ਰਸਿੱਧੀ ਲੀਨੀਅਰ ਕਾਰੋਬਾਰੀ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਬਣਾਉਣ ਦੀ ਤੁਲਨਾਤਮਕ ਸਰਲਤਾ ਅਤੇ ਗਤੀ ਦੇ ਕਾਰਨ ਹੈ। ਹਾਲਾਂਕਿ, ਜਿਵੇਂ ਕਿ ਸੌਫਟਵੇਅਰ ਸਿਸਟਮ ਲਗਾਤਾਰ ਵਧੇਰੇ ਗੁੰਝਲਦਾਰ ਬਣਦੇ ਹਨ, ਕਾਰੋਬਾਰੀ ਪ੍ਰਕਿਰਿਆ ਦਾ ਸਵੈਚਾਲਿਤ ਹਿੱਸਾ ਵਧਦਾ ਹੈ ਅਤੇ ਵਧੇਰੇ ਗੁੰਝਲਦਾਰ ਬਣ ਜਾਂਦਾ ਹੈ। ਸੜਨ, ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੇ ਹਿੱਸਿਆਂ ਦੀ ਮੁੜ ਵਰਤੋਂ ਦੇ ਨਾਲ-ਨਾਲ ਬ੍ਰਾਂਚਿੰਗ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਤਾਂ ਜੋ ਹਰੇਕ ਸ਼ਾਖਾ ਨੂੰ ਸਮਾਨਾਂਤਰ ਵਿੱਚ ਚਲਾਇਆ ਜਾ ਸਕੇ। ਅਜਿਹੀਆਂ ਸਥਿਤੀਆਂ ਵਿੱਚ, ਟੂਲ ਅਸੁਵਿਧਾਜਨਕ ਹੋ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਰਾਜ ਪਰਿਵਰਤਨ ਚਿੱਤਰ ਆਪਣੀ ਜਾਣਕਾਰੀ ਸਮੱਗਰੀ ਨੂੰ ਗੁਆ ਦਿੰਦਾ ਹੈ (ਏਕੀਕਰਣ ਪਰਸਪਰ ਪ੍ਰਭਾਵ ਡਾਇਗ੍ਰਾਮ ਵਿੱਚ ਬਿਲਕੁਲ ਨਹੀਂ ਪ੍ਰਤੀਬਿੰਬਤ ਹੁੰਦਾ ਹੈ)।

ਲੋੜਾਂ ਦੇ ਸਪੱਸ਼ਟੀਕਰਨ ਦੇ ਕਈ ਦੁਹਰਾਓ ਤੋਂ ਬਾਅਦ ਇਹ ਪ੍ਰਕਿਰਿਆ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ।

ਇਸ ਸਥਿਤੀ ਤੋਂ ਬਾਹਰ ਦਾ ਰਸਤਾ ਇੰਜਣ ਦਾ ਏਕੀਕਰਣ ਸੀ jBPM ਸਭ ਤੋਂ ਗੁੰਝਲਦਾਰ ਕਾਰੋਬਾਰੀ ਪ੍ਰਕਿਰਿਆਵਾਂ ਵਾਲੇ ਕੁਝ ਉਤਪਾਦਾਂ ਵਿੱਚ। ਥੋੜ੍ਹੇ ਸਮੇਂ ਵਿੱਚ, ਇਸ ਹੱਲ ਨੂੰ ਕੁਝ ਸਫਲਤਾ ਮਿਲੀ: ਨੋਟੇਸ਼ਨ ਵਿੱਚ ਇੱਕ ਕਾਫ਼ੀ ਜਾਣਕਾਰੀ ਭਰਪੂਰ ਅਤੇ ਸੰਬੰਧਿਤ ਚਿੱਤਰ ਨੂੰ ਕਾਇਮ ਰੱਖਦੇ ਹੋਏ ਗੁੰਝਲਦਾਰ ਕਾਰੋਬਾਰੀ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਸੰਭਵ ਹੋ ਗਿਆ। BPMN2.

ਇੱਕ ਗੁੰਝਲਦਾਰ ਕਾਰੋਬਾਰੀ ਪ੍ਰਕਿਰਿਆ ਦਾ ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਹਿੱਸਾ

ਲੰਬੇ ਸਮੇਂ ਵਿੱਚ, ਹੱਲ ਉਮੀਦਾਂ 'ਤੇ ਖਰਾ ਨਹੀਂ ਉਤਰਿਆ: ਵਿਜ਼ੂਅਲ ਟੂਲਸ ਦੁਆਰਾ ਕਾਰੋਬਾਰੀ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਬਣਾਉਣ ਦੀ ਉੱਚ ਲੇਬਰ ਤੀਬਰਤਾ ਨੇ ਸਵੀਕਾਰਯੋਗ ਉਤਪਾਦਕਤਾ ਸੂਚਕਾਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦਿੱਤੀ, ਅਤੇ ਇਹ ਸੰਦ ਖੁਦ ਡਿਵੈਲਪਰਾਂ ਵਿੱਚ ਸਭ ਤੋਂ ਵੱਧ ਨਾਪਸੰਦ ਬਣ ਗਿਆ। ਇੰਜਣ ਦੀ ਅੰਦਰੂਨੀ ਬਣਤਰ ਬਾਰੇ ਵੀ ਸ਼ਿਕਾਇਤਾਂ ਸਨ, ਜਿਸ ਕਾਰਨ ਬਹੁਤ ਸਾਰੇ "ਪੈਚ" ਅਤੇ "ਬਸਾਖੀਆਂ" ਦੀ ਦਿੱਖ ਦਿਖਾਈ ਦਿੱਤੀ।

jBPM ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਮੁੱਖ ਸਕਾਰਾਤਮਕ ਪਹਿਲੂ ਇੱਕ ਕਾਰੋਬਾਰੀ ਪ੍ਰਕਿਰਿਆ ਦੀ ਆਪਣੀ ਨਿਰੰਤਰ ਸਥਿਤੀ ਹੋਣ ਦੇ ਲਾਭਾਂ ਅਤੇ ਨੁਕਸਾਨਾਂ ਬਾਰੇ ਜਾਗਰੂਕਤਾ ਸੀ। ਅਸੀਂ ਸਿਗਨਲਾਂ ਅਤੇ ਸੰਦੇਸ਼ਾਂ ਦੁਆਰਾ ਅਸਿੰਕਰੋਨਸ ਪਰਸਪਰ ਕ੍ਰਿਆਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਵੱਖ-ਵੱਖ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿਚਕਾਰ ਗੁੰਝਲਦਾਰ ਏਕੀਕਰਣ ਪ੍ਰੋਟੋਕੋਲ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਪਹੁੰਚ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਸੰਭਾਵਨਾ ਵੀ ਵੇਖੀ ਹੈ। ਇੱਕ ਸਥਿਰ ਰਾਜ ਦੀ ਮੌਜੂਦਗੀ ਇਸ ਵਿੱਚ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਭੂਮਿਕਾ ਨਿਭਾਉਂਦੀ ਹੈ.

ਉਪਰੋਕਤ ਦੇ ਅਧਾਰ ਤੇ, ਅਸੀਂ ਸਿੱਟਾ ਕੱਢ ਸਕਦੇ ਹਾਂ: BPM ਸ਼ੈਲੀ ਵਿੱਚ ਪ੍ਰਕਿਰਿਆ ਪਹੁੰਚ ਸਾਨੂੰ ਵਧਦੀ ਗੁੰਝਲਦਾਰ ਵਪਾਰਕ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਸਵੈਚਾਲਤ ਕਰਨ ਲਈ, ਇਹਨਾਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਵਿੱਚ ਏਕੀਕਰਣ ਦੀਆਂ ਗਤੀਵਿਧੀਆਂ ਨੂੰ ਇਕਸੁਰਤਾ ਨਾਲ ਫਿੱਟ ਕਰਨ ਅਤੇ ਇੱਕ ਢੁਕਵੇਂ ਸੰਕੇਤ ਵਿੱਚ ਲਾਗੂ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਦ੍ਰਿਸ਼ਟੀਗਤ ਰੂਪ ਵਿੱਚ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਣ ਲਈ ਕਾਰਜਾਂ ਦੀ ਇੱਕ ਵਿਸ਼ਾਲ ਸ਼੍ਰੇਣੀ ਨੂੰ ਹੱਲ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ।

ਏਕੀਕਰਣ ਪੈਟਰਨ ਦੇ ਰੂਪ ਵਿੱਚ ਸਮਕਾਲੀ ਕਾਲਾਂ ਦੇ ਨੁਕਸਾਨ

ਸਮਕਾਲੀ ਏਕੀਕਰਣ ਸਭ ਤੋਂ ਸਰਲ ਬਲਾਕਿੰਗ ਕਾਲ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ। ਇੱਕ ਸਬ-ਸਿਸਟਮ ਸਰਵਰ ਸਾਈਡ ਵਜੋਂ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਲੋੜੀਂਦੇ ਢੰਗ ਨਾਲ API ਨੂੰ ਉਜਾਗਰ ਕਰਦਾ ਹੈ। ਇਕ ਹੋਰ ਸਬ-ਸਿਸਟਮ ਕਲਾਇੰਟ ਸਾਈਡ ਵਜੋਂ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਸਹੀ ਸਮੇਂ 'ਤੇ ਕਾਲ ਕਰਦਾ ਹੈ ਅਤੇ ਨਤੀਜੇ ਦੀ ਉਡੀਕ ਕਰਦਾ ਹੈ। ਸਿਸਟਮ ਆਰਕੀਟੈਕਚਰ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹੋਏ, ਕਲਾਇੰਟ ਅਤੇ ਸਰਵਰ ਸਾਈਡਾਂ ਜਾਂ ਤਾਂ ਇੱਕੋ ਐਪਲੀਕੇਸ਼ਨ ਅਤੇ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ, ਜਾਂ ਵੱਖ-ਵੱਖ ਵਿੱਚ ਸਥਿਤ ਹੋ ਸਕਦੇ ਹਨ। ਦੂਜੇ ਕੇਸ ਵਿੱਚ, ਤੁਹਾਨੂੰ ਕੁਝ ਆਰਪੀਸੀ ਲਾਗੂ ਕਰਨ ਅਤੇ ਪੈਰਾਮੀਟਰਾਂ ਦੀ ਮਾਰਸ਼ਲਿੰਗ ਅਤੇ ਕਾਲ ਦੇ ਨਤੀਜੇ ਪ੍ਰਦਾਨ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

ਇਸ ਏਕੀਕਰਣ ਪੈਟਰਨ ਦੇ ਨੁਕਸਾਨਾਂ ਦਾ ਕਾਫ਼ੀ ਵੱਡਾ ਸਮੂਹ ਹੈ, ਪਰ ਇਸਦੀ ਸਾਦਗੀ ਦੇ ਕਾਰਨ ਅਭਿਆਸ ਵਿੱਚ ਇਹ ਬਹੁਤ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਲਾਗੂ ਕਰਨ ਦੀ ਗਤੀ ਤੁਹਾਨੂੰ ਆਕਰਸ਼ਿਤ ਕਰਦੀ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਡੈੱਡਲਾਈਨ ਦਬਾਉਣ, ਹੱਲ ਨੂੰ ਤਕਨੀਕੀ ਕਰਜ਼ੇ ਵਜੋਂ ਰਿਕਾਰਡ ਕਰਨ ਦੇ ਬਾਵਜੂਦ ਇਸਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰਦੀ ਹੈ। ਪਰ ਇਹ ਵੀ ਹੁੰਦਾ ਹੈ ਕਿ ਭੋਲੇ-ਭਾਲੇ ਡਿਵੈਲਪਰ ਅਣਜਾਣੇ ਵਿੱਚ ਇਸਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ, ਸਿਰਫ਼ ਨਕਾਰਾਤਮਕ ਨਤੀਜਿਆਂ ਨੂੰ ਮਹਿਸੂਸ ਨਹੀਂ ਕਰਦੇ.

ਸਬ-ਸਿਸਟਮ ਕਨੈਕਟੀਵਿਟੀ ਵਿੱਚ ਸਭ ਤੋਂ ਵੱਧ ਸਪੱਸ਼ਟ ਵਾਧੇ ਤੋਂ ਇਲਾਵਾ, "ਵਧ ਰਹੇ" ਅਤੇ "ਖਿੱਚਣ" ਲੈਣ-ਦੇਣ ਵਿੱਚ ਘੱਟ ਸਪੱਸ਼ਟ ਸਮੱਸਿਆਵਾਂ ਵੀ ਹਨ। ਦਰਅਸਲ, ਜੇਕਰ ਕਾਰੋਬਾਰੀ ਤਰਕ ਕੁਝ ਬਦਲਾਅ ਕਰਦਾ ਹੈ, ਤਾਂ ਲੈਣ-ਦੇਣ ਤੋਂ ਬਚਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ, ਅਤੇ ਬਦਲੇ ਵਿੱਚ, ਲੈਣ-ਦੇਣ, ਇਹਨਾਂ ਤਬਦੀਲੀਆਂ ਦੁਆਰਾ ਪ੍ਰਭਾਵਿਤ ਕੁਝ ਐਪਲੀਕੇਸ਼ਨ ਸਰੋਤਾਂ ਨੂੰ ਬਲੌਕ ਕਰਦਾ ਹੈ। ਭਾਵ, ਜਦੋਂ ਤੱਕ ਇੱਕ ਉਪ-ਸਿਸਟਮ ਦੂਜੇ ਤੋਂ ਜਵਾਬ ਦੀ ਉਡੀਕ ਨਹੀਂ ਕਰਦਾ, ਇਹ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਨੂੰ ਪੂਰਾ ਕਰਨ ਅਤੇ ਤਾਲੇ ਨੂੰ ਹਟਾਉਣ ਦੇ ਯੋਗ ਨਹੀਂ ਹੋਵੇਗਾ। ਇਹ ਕਈ ਤਰ੍ਹਾਂ ਦੇ ਪ੍ਰਭਾਵਾਂ ਦੇ ਜੋਖਮ ਨੂੰ ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ ਵਧਾਉਂਦਾ ਹੈ:

• ਸਿਸਟਮ ਦੀ ਜਵਾਬਦੇਹੀ ਖਤਮ ਹੋ ਗਈ ਹੈ, ਉਪਭੋਗਤਾ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬਾਂ ਲਈ ਲੰਮਾ ਸਮਾਂ ਉਡੀਕ ਕਰਦੇ ਹਨ;
• ਸਰਵਰ ਆਮ ਤੌਰ 'ਤੇ ਭੀੜ-ਭੜੱਕੇ ਵਾਲੇ ਥ੍ਰੈੱਡ ਪੂਲ ਦੇ ਕਾਰਨ ਉਪਭੋਗਤਾ ਦੀਆਂ ਬੇਨਤੀਆਂ ਦਾ ਜਵਾਬ ਦੇਣਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ: ਬਹੁਤੇ ਥ੍ਰੈੱਡ ਇੱਕ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਦੁਆਰਾ ਕਬਜ਼ੇ ਵਿੱਚ ਕੀਤੇ ਸਰੋਤ 'ਤੇ ਲਾਕ ਕੀਤੇ ਜਾਂਦੇ ਹਨ;
• ਡੈੱਡਲਾਕ ਦਿਖਾਈ ਦੇਣ ਲੱਗ ਪੈਂਦੇ ਹਨ: ਉਹਨਾਂ ਦੇ ਹੋਣ ਦੀ ਸੰਭਾਵਨਾ ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਦੀ ਮਿਆਦ, ਵਪਾਰਕ ਤਰਕ ਦੀ ਮਾਤਰਾ ਅਤੇ ਲੈਣ-ਦੇਣ ਵਿੱਚ ਸ਼ਾਮਲ ਤਾਲੇ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ;
• ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਟਾਈਮਆਉਟ ਗਲਤੀਆਂ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ;
• ਸਰਵਰ OutOfMemory ਦੇ ਨਾਲ "ਫੇਲ" ਹੋ ਜਾਂਦਾ ਹੈ ਜੇਕਰ ਕਾਰਜ ਲਈ ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ ਡੇਟਾ ਨੂੰ ਪ੍ਰੋਸੈਸ ਕਰਨ ਅਤੇ ਬਦਲਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਸਮਕਾਲੀ ਏਕੀਕਰਣ ਦੀ ਮੌਜੂਦਗੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ "ਹਲਕੇ" ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਵਿੱਚ ਵੰਡਣਾ ਬਹੁਤ ਮੁਸ਼ਕਲ ਬਣਾਉਂਦੀ ਹੈ।

ਇੱਕ ਆਰਕੀਟੈਕਚਰਲ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਏਕੀਕਰਣ ਦੇ ਦੌਰਾਨ ਬਲੌਕਿੰਗ ਕਾਲਾਂ ਦੀ ਵਰਤੋਂ ਵਿਅਕਤੀਗਤ ਉਪ-ਪ੍ਰਣਾਲੀਆਂ ਦੀ ਗੁਣਵੱਤਾ 'ਤੇ ਨਿਯੰਤਰਣ ਦੇ ਨੁਕਸਾਨ ਵੱਲ ਲੈ ਜਾਂਦੀ ਹੈ: ਕਿਸੇ ਹੋਰ ਉਪ-ਪ੍ਰਣਾਲੀ ਦੇ ਗੁਣਵੱਤਾ ਸੂਚਕਾਂ ਤੋਂ ਅਲੱਗਤਾ ਵਿੱਚ ਇੱਕ ਉਪ-ਪ੍ਰਣਾਲੀ ਦੇ ਟੀਚੇ ਦੀ ਗੁਣਵੱਤਾ ਸੂਚਕਾਂ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣਾ ਅਸੰਭਵ ਹੈ। ਜੇਕਰ ਸਬ-ਸਿਸਟਮ ਵੱਖ-ਵੱਖ ਟੀਮਾਂ ਦੁਆਰਾ ਵਿਕਸਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਇਹ ਇੱਕ ਵੱਡੀ ਸਮੱਸਿਆ ਹੈ।

ਚੀਜ਼ਾਂ ਹੋਰ ਵੀ ਦਿਲਚਸਪ ਹੋ ਜਾਂਦੀਆਂ ਹਨ ਜੇਕਰ ਏਕੀਕ੍ਰਿਤ ਕੀਤੇ ਜਾ ਰਹੇ ਉਪ-ਸਿਸਟਮ ਵੱਖ-ਵੱਖ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ ਹਨ ਅਤੇ ਤੁਹਾਨੂੰ ਦੋਵਾਂ ਪਾਸਿਆਂ 'ਤੇ ਸਮਕਾਲੀ ਤਬਦੀਲੀਆਂ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਇਹਨਾਂ ਤਬਦੀਲੀਆਂ ਦੀ ਲੈਣ-ਦੇਣ ਨੂੰ ਕਿਵੇਂ ਯਕੀਨੀ ਬਣਾਇਆ ਜਾਵੇ?

ਜੇਕਰ ਬਦਲਾਵ ਵੱਖਰੇ ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਵਿੱਚ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਤੁਹਾਨੂੰ ਭਰੋਸੇਯੋਗ ਅਪਵਾਦ ਹੈਂਡਲਿੰਗ ਅਤੇ ਮੁਆਵਜ਼ਾ ਪ੍ਰਦਾਨ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੋਏਗੀ, ਅਤੇ ਇਹ ਸਮਕਾਲੀ ਏਕੀਕਰਣ ਦੇ ਮੁੱਖ ਲਾਭ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਖਤਮ ਕਰਦਾ ਹੈ - ਸਾਦਗੀ.

ਵੰਡੇ ਗਏ ਲੈਣ-ਦੇਣ ਵੀ ਮਨ ਵਿੱਚ ਆਉਂਦੇ ਹਨ, ਪਰ ਅਸੀਂ ਉਹਨਾਂ ਨੂੰ ਆਪਣੇ ਹੱਲਾਂ ਵਿੱਚ ਨਹੀਂ ਵਰਤਦੇ: ਭਰੋਸੇਯੋਗਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣਾ ਮੁਸ਼ਕਲ ਹੈ।

ਲੈਣ-ਦੇਣ ਦੀ ਸਮੱਸਿਆ ਦੇ ਹੱਲ ਵਜੋਂ "ਸਾਗਾ"

ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਦੀ ਵਧਦੀ ਪ੍ਰਸਿੱਧੀ ਦੇ ਨਾਲ, ਦੀ ਮੰਗ ਸਾਗਾ ਪੈਟਰਨ.

ਇਹ ਪੈਟਰਨ ਲੰਬੇ ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਦੀਆਂ ਉੱਪਰ ਦੱਸੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਹੱਲ ਕਰਦਾ ਹੈ, ਅਤੇ ਵਪਾਰਕ ਤਰਕ ਦੇ ਪੱਖ ਤੋਂ ਸਿਸਟਮ ਦੀ ਸਥਿਤੀ ਦੇ ਪ੍ਰਬੰਧਨ ਦੀਆਂ ਸਮਰੱਥਾਵਾਂ ਦਾ ਵਿਸਤਾਰ ਵੀ ਕਰਦਾ ਹੈ: ਇੱਕ ਅਸਫਲ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਤੋਂ ਬਾਅਦ ਮੁਆਵਜ਼ਾ ਸਿਸਟਮ ਨੂੰ ਇਸਦੀ ਅਸਲ ਸਥਿਤੀ ਵਿੱਚ ਵਾਪਸ ਨਹੀਂ ਲਿਆ ਸਕਦਾ, ਪਰ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ. ਇੱਕ ਵਿਕਲਪਿਕ ਡਾਟਾ ਪ੍ਰੋਸੈਸਿੰਗ ਰੂਟ. ਇਹ ਤੁਹਾਨੂੰ ਪ੍ਰਕਿਰਿਆ ਨੂੰ "ਚੰਗੇ" ਅੰਤ ਤੱਕ ਲਿਆਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਸਮੇਂ ਸਫਲਤਾਪੂਰਵਕ ਮੁਕੰਮਲ ਕੀਤੇ ਡੇਟਾ ਪ੍ਰੋਸੈਸਿੰਗ ਕਦਮਾਂ ਨੂੰ ਦੁਹਰਾਉਣ ਤੋਂ ਬਚਣ ਦੀ ਵੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ।

ਦਿਲਚਸਪ ਗੱਲ ਇਹ ਹੈ ਕਿ, ਮੋਨੋਲੀਥਿਕ ਪ੍ਰਣਾਲੀਆਂ ਵਿੱਚ ਇਹ ਪੈਟਰਨ ਉਦੋਂ ਵੀ ਢੁਕਵਾਂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਇਹ ਢਿੱਲੇ ਤੌਰ 'ਤੇ ਜੋੜੇ ਹੋਏ ਉਪ-ਪ੍ਰਣਾਲੀਆਂ ਦੇ ਏਕੀਕਰਨ ਦੀ ਗੱਲ ਆਉਂਦੀ ਹੈ ਅਤੇ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਚੱਲ ਰਹੇ ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਅਤੇ ਸੰਬੰਧਿਤ ਸਰੋਤ ਲਾਕ ਦੇ ਕਾਰਨ ਨਕਾਰਾਤਮਕ ਪ੍ਰਭਾਵਾਂ ਨੂੰ ਦੇਖਿਆ ਜਾਂਦਾ ਹੈ।

ਬੀਪੀਐਮ ਸ਼ੈਲੀ ਵਿੱਚ ਸਾਡੀਆਂ ਵਪਾਰਕ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੇ ਸਬੰਧ ਵਿੱਚ, "ਸਾਗਾਸ" ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਬਹੁਤ ਅਸਾਨ ਹੈ: "ਸਾਗਾ" ਦੇ ਵਿਅਕਤੀਗਤ ਕਦਮਾਂ ਨੂੰ ਵਪਾਰਕ ਪ੍ਰਕਿਰਿਆ ਦੇ ਅੰਦਰ ਗਤੀਵਿਧੀਆਂ ਦੇ ਤੌਰ ਤੇ ਨਿਰਧਾਰਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਵਪਾਰਕ ਪ੍ਰਕਿਰਿਆ ਦੀ ਨਿਰੰਤਰ ਸਥਿਤੀ ਵੀ "ਸਾਗਾ" ਦੀ ਅੰਦਰੂਨੀ ਸਥਿਤੀ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ। ਭਾਵ, ਸਾਨੂੰ ਕਿਸੇ ਵਾਧੂ ਤਾਲਮੇਲ ਵਿਧੀ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਤੁਹਾਨੂੰ ਸਿਰਫ਼ ਇੱਕ ਸੰਦੇਸ਼ ਬ੍ਰੋਕਰ ਦੀ ਲੋੜ ਹੈ ਜੋ "ਘੱਟੋ-ਘੱਟ ਇੱਕ ਵਾਰ" ਟਰਾਂਸਪੋਰਟ ਵਜੋਂ ਗਾਰੰਟੀ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ।

ਪਰ ਇਸ ਹੱਲ ਦੀ ਆਪਣੀ "ਕੀਮਤ" ਵੀ ਹੈ:

• ਕਾਰੋਬਾਰੀ ਤਰਕ ਹੋਰ ਗੁੰਝਲਦਾਰ ਬਣ ਜਾਂਦਾ ਹੈ: ਮੁਆਵਜ਼ੇ 'ਤੇ ਕੰਮ ਕਰਨ ਦੀ ਲੋੜ ਹੈ;
• ਪੂਰੀ ਇਕਸਾਰਤਾ ਨੂੰ ਛੱਡਣਾ ਜ਼ਰੂਰੀ ਹੋਵੇਗਾ, ਜੋ ਕਿ ਮੋਨੋਲੀਥਿਕ ਪ੍ਰਣਾਲੀਆਂ ਲਈ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਸੰਵੇਦਨਸ਼ੀਲ ਹੋ ਸਕਦਾ ਹੈ;
• ਆਰਕੀਟੈਕਚਰ ਥੋੜਾ ਹੋਰ ਗੁੰਝਲਦਾਰ ਹੋ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਸੁਨੇਹਾ ਬ੍ਰੋਕਰ ਲਈ ਇੱਕ ਵਾਧੂ ਲੋੜ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ;
• ਵਾਧੂ ਨਿਗਰਾਨੀ ਅਤੇ ਪ੍ਰਸ਼ਾਸਨ ਸਾਧਨਾਂ ਦੀ ਲੋੜ ਹੋਵੇਗੀ (ਹਾਲਾਂਕਿ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਚੰਗਾ ਹੈ: ਸਿਸਟਮ ਸੇਵਾ ਦੀ ਗੁਣਵੱਤਾ ਵਧੇਗੀ)।

ਮੋਨੋਲਿਥਿਕ ਪ੍ਰਣਾਲੀਆਂ ਲਈ, "ਸੈਗ" ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਉਚਿਤਤਾ ਇੰਨੀ ਸਪੱਸ਼ਟ ਨਹੀਂ ਹੈ। ਮਾਈਕ੍ਰੋਸੇਵਾਵਾਂ ਅਤੇ ਹੋਰ SOA ਲਈ, ਜਿੱਥੇ ਜ਼ਿਆਦਾਤਰ ਸੰਭਾਵਨਾ ਹੈ ਕਿ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਬ੍ਰੋਕਰ ਹੈ, ਅਤੇ ਪ੍ਰੋਜੈਕਟ ਦੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਪੂਰੀ ਇਕਸਾਰਤਾ ਦੀ ਬਲੀ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ, ਇਸ ਪੈਟਰਨ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੇ ਫਾਇਦੇ ਨੁਕਸਾਨਾਂ ਤੋਂ ਕਾਫ਼ੀ ਜ਼ਿਆਦਾ ਹੋ ਸਕਦੇ ਹਨ, ਖਾਸ ਤੌਰ 'ਤੇ ਜੇਕਰ ਵਪਾਰਕ ਤਰਕ 'ਤੇ ਇੱਕ ਸੁਵਿਧਾਜਨਕ API ਹੈ। ਪੱਧਰ।

ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਵਿੱਚ ਕਾਰੋਬਾਰੀ ਤਰਕ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨਾ

ਜਦੋਂ ਅਸੀਂ ਮਾਈਕ੍ਰੋਸਰਵਿਸਿਜ਼ ਦੇ ਨਾਲ ਪ੍ਰਯੋਗ ਕਰਨਾ ਸ਼ੁਰੂ ਕੀਤਾ, ਤਾਂ ਇੱਕ ਵਾਜਬ ਸਵਾਲ ਪੈਦਾ ਹੋਇਆ: ਡੋਮੇਨ ਡੇਟਾ ਦੀ ਨਿਰੰਤਰਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਵਾਲੀ ਸੇਵਾ ਦੇ ਸਬੰਧ ਵਿੱਚ ਡੋਮੇਨ ਵਪਾਰ ਤਰਕ ਨੂੰ ਕਿੱਥੇ ਰੱਖਣਾ ਹੈ?

ਵੱਖ-ਵੱਖ BPMSs ਦੇ ਢਾਂਚੇ ਨੂੰ ਦੇਖਦੇ ਹੋਏ, ਕਾਰੋਬਾਰੀ ਤਰਕ ਨੂੰ ਸਥਿਰਤਾ ਤੋਂ ਵੱਖ ਕਰਨਾ ਵਾਜਬ ਜਾਪਦਾ ਹੈ: ਪਲੇਟਫਾਰਮ ਅਤੇ ਡੋਮੇਨ-ਸੁਤੰਤਰ ਮਾਈਕ੍ਰੋਸਰਵਿਸਿਜ਼ ਦੀ ਇੱਕ ਪਰਤ ਬਣਾਓ ਜੋ ਡੋਮੇਨ ਵਪਾਰਕ ਤਰਕ ਨੂੰ ਚਲਾਉਣ ਲਈ ਇੱਕ ਵਾਤਾਵਰਣ ਅਤੇ ਕੰਟੇਨਰ ਬਣਾਉਂਦੀ ਹੈ, ਅਤੇ ਡੋਮੇਨ ਡੇਟਾ ਦੀ ਸਥਿਰਤਾ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਈਨ ਕਰਦੀ ਹੈ ਬਹੁਤ ਹੀ ਸਧਾਰਨ ਅਤੇ ਹਲਕੇ ਮਾਈਕ੍ਰੋਸੇਵਾਵਾਂ ਦੀ ਇੱਕ ਵੱਖਰੀ ਪਰਤ। ਇਸ ਕੇਸ ਵਿੱਚ ਵਪਾਰਕ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨਿਰੰਤਰਤਾ ਪਰਤ ਦੀਆਂ ਸੇਵਾਵਾਂ ਦਾ ਆਰਕੈਸਟਰੇਸ਼ਨ ਕਰਦੀਆਂ ਹਨ।

ਇਸ ਪਹੁੰਚ ਦਾ ਇੱਕ ਬਹੁਤ ਵੱਡਾ ਫਾਇਦਾ ਹੈ: ਤੁਸੀਂ ਪਲੇਟਫਾਰਮ ਦੀ ਕਾਰਜਕੁਸ਼ਲਤਾ ਨੂੰ ਜਿੰਨਾ ਚਾਹੋ ਵਧਾ ਸਕਦੇ ਹੋ, ਅਤੇ ਪਲੇਟਫਾਰਮ ਮਾਈਕਰੋ ਸਰਵਿਸਿਜ਼ ਦੀ ਸਿਰਫ ਅਨੁਸਾਰੀ ਪਰਤ ਇਸ ਤੋਂ "ਚਰਬੀ" ਬਣ ਜਾਵੇਗੀ। ਕਿਸੇ ਵੀ ਡੋਮੇਨ ਤੋਂ ਵਪਾਰਕ ਪ੍ਰਕਿਰਿਆਵਾਂ ਪਲੇਟਫਾਰਮ ਦੀ ਨਵੀਂ ਕਾਰਜਕੁਸ਼ਲਤਾ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੇ ਯੋਗ ਹੋ ਜਾਂਦੀਆਂ ਹਨ ਜਿਵੇਂ ਹੀ ਇਸਨੂੰ ਅਪਡੇਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ.

ਇੱਕ ਹੋਰ ਵਿਸਤ੍ਰਿਤ ਅਧਿਐਨ ਨੇ ਇਸ ਪਹੁੰਚ ਦੇ ਮਹੱਤਵਪੂਰਨ ਨੁਕਸਾਨਾਂ ਦਾ ਖੁਲਾਸਾ ਕੀਤਾ:

• ਇੱਕ ਪਲੇਟਫਾਰਮ ਸੇਵਾ ਜੋ ਇੱਕ ਵਾਰ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਡੋਮੇਨਾਂ ਦੇ ਵਪਾਰਕ ਤਰਕ ਨੂੰ ਲਾਗੂ ਕਰਦੀ ਹੈ, ਅਸਫਲਤਾ ਦੇ ਇੱਕ ਬਿੰਦੂ ਦੇ ਰੂਪ ਵਿੱਚ ਬਹੁਤ ਜੋਖਮ ਲੈਂਦੀ ਹੈ। ਵਪਾਰਕ ਤਰਕ ਵਿੱਚ ਵਾਰ-ਵਾਰ ਤਬਦੀਲੀਆਂ ਸਿਸਟਮ-ਵਿਆਪਕ ਅਸਫਲਤਾਵਾਂ ਵੱਲ ਲੈ ਜਾਣ ਵਾਲੀਆਂ ਗਲਤੀਆਂ ਦੇ ਜੋਖਮ ਨੂੰ ਵਧਾਉਂਦੀਆਂ ਹਨ;
• ਪ੍ਰਦਰਸ਼ਨ ਮੁੱਦੇ: ਵਪਾਰਕ ਤਰਕ ਇੱਕ ਤੰਗ ਅਤੇ ਹੌਲੀ ਇੰਟਰਫੇਸ ਦੁਆਰਾ ਇਸਦੇ ਡੇਟਾ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ:
  • ਡੇਟਾ ਨੂੰ ਇੱਕ ਵਾਰ ਫਿਰ ਮਾਰਸ਼ਲ ਕੀਤਾ ਜਾਵੇਗਾ ਅਤੇ ਨੈਟਵਰਕ ਸਟੈਕ ਦੁਆਰਾ ਪੰਪ ਕੀਤਾ ਜਾਵੇਗਾ;
  • ਇੱਕ ਡੋਮੇਨ ਸੇਵਾ ਅਕਸਰ ਸੇਵਾ ਦੇ ਬਾਹਰੀ API ਦੇ ਪੱਧਰ 'ਤੇ ਪੈਰਾਮੀਟਰਾਈਜ਼ਿੰਗ ਬੇਨਤੀਆਂ ਲਈ ਨਾਕਾਫ਼ੀ ਸਮਰੱਥਾ ਦੇ ਕਾਰਨ ਕਾਰੋਬਾਰੀ ਤਰਕ ਦੀ ਪ੍ਰਕਿਰਿਆ ਲਈ ਲੋੜ ਤੋਂ ਵੱਧ ਡੇਟਾ ਪ੍ਰਦਾਨ ਕਰੇਗੀ;
  • ਕਾਰੋਬਾਰੀ ਤਰਕ ਦੇ ਕਈ ਸੁਤੰਤਰ ਟੁਕੜੇ ਪ੍ਰੋਸੈਸਿੰਗ ਲਈ ਉਸੇ ਡੇਟਾ ਨੂੰ ਵਾਰ-ਵਾਰ ਦੁਬਾਰਾ ਬੇਨਤੀ ਕਰ ਸਕਦੇ ਹਨ (ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਸੈਸ਼ਨ ਭਾਗਾਂ ਨੂੰ ਜੋੜ ਕੇ ਘੱਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਜੋ ਡੇਟਾ ਨੂੰ ਕੈਸ਼ ਕਰਦੇ ਹਨ, ਪਰ ਇਹ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਹੋਰ ਗੁੰਝਲਦਾਰ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਡੇਟਾ ਪ੍ਰਸੰਗਿਕਤਾ ਅਤੇ ਕੈਸ਼ ਅਯੋਗਤਾ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕਰਦਾ ਹੈ);
• ਲੈਣ-ਦੇਣ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ:
  • ਸਥਿਰ ਸਥਿਤੀ ਵਾਲੀਆਂ ਵਪਾਰਕ ਪ੍ਰਕਿਰਿਆਵਾਂ, ਜੋ ਇੱਕ ਪਲੇਟਫਾਰਮ ਸੇਵਾ ਦੁਆਰਾ ਸਟੋਰ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਡੋਮੇਨ ਡੇਟਾ ਨਾਲ ਅਸੰਗਤ ਹਨ, ਅਤੇ ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਦੇ ਕੋਈ ਆਸਾਨ ਤਰੀਕੇ ਨਹੀਂ ਹਨ;
  • ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਤੋਂ ਬਾਹਰ ਡੋਮੇਨ ਡੇਟਾ ਨੂੰ ਬਲੌਕ ਕਰਨਾ: ਜੇਕਰ ਡੋਮੇਨ ਕਾਰੋਬਾਰ ਦੇ ਤਰਕ ਨੂੰ ਪਹਿਲਾਂ ਮੌਜੂਦਾ ਡੇਟਾ ਦੀ ਸ਼ੁੱਧਤਾ ਦੀ ਜਾਂਚ ਕਰਨ ਤੋਂ ਬਾਅਦ ਤਬਦੀਲੀਆਂ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਤਾਂ ਪ੍ਰਕਿਰਿਆ ਕੀਤੇ ਡੇਟਾ ਵਿੱਚ ਪ੍ਰਤੀਯੋਗੀ ਤਬਦੀਲੀ ਦੀ ਸੰਭਾਵਨਾ ਨੂੰ ਬਾਹਰ ਕੱਢਣਾ ਜ਼ਰੂਰੀ ਹੈ। ਬਾਹਰੀ ਡੇਟਾ ਬਲਾਕਿੰਗ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦੀ ਹੈ, ਪਰ ਅਜਿਹਾ ਹੱਲ ਵਾਧੂ ਜੋਖਮ ਰੱਖਦਾ ਹੈ ਅਤੇ ਸਿਸਟਮ ਦੀ ਸਮੁੱਚੀ ਭਰੋਸੇਯੋਗਤਾ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ;
• ਅੱਪਡੇਟ ਕਰਨ ਵੇਲੇ ਅਤਿਰਿਕਤ ਮੁਸ਼ਕਲਾਂ: ਕੁਝ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਸਥਿਰਤਾ ਸੇਵਾ ਅਤੇ ਵਪਾਰਕ ਤਰਕ ਨੂੰ ਸਮਕਾਲੀ ਜਾਂ ਸਖ਼ਤ ਕ੍ਰਮ ਵਿੱਚ ਅੱਪਡੇਟ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਆਖਰਕਾਰ, ਸਾਨੂੰ ਮੂਲ ਗੱਲਾਂ 'ਤੇ ਵਾਪਸ ਜਾਣਾ ਪਿਆ: ਡੋਮੇਨ ਡੇਟਾ ਅਤੇ ਡੋਮੇਨ ਵਪਾਰ ਤਰਕ ਨੂੰ ਇੱਕ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰੋ। ਇਹ ਪਹੁੰਚ ਸਿਸਟਮ ਦੇ ਇੱਕ ਅਨਿੱਖੜਵੇਂ ਹਿੱਸੇ ਵਜੋਂ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਦੀ ਧਾਰਨਾ ਨੂੰ ਸਰਲ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਉਪਰੋਕਤ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਜਨਮ ਨਹੀਂ ਦਿੰਦਾ ਹੈ। ਇਹ ਮੁਫਤ ਵਿੱਚ ਵੀ ਨਹੀਂ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ:

• ਕਾਰੋਬਾਰੀ ਤਰਕ (ਖਾਸ ਤੌਰ 'ਤੇ, ਵਪਾਰਕ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਉਪਭੋਗਤਾ ਗਤੀਵਿਧੀਆਂ ਪ੍ਰਦਾਨ ਕਰਨ ਲਈ) ਅਤੇ API ਪਲੇਟਫਾਰਮ ਸੇਵਾਵਾਂ ਨਾਲ ਗੱਲਬਾਤ ਕਰਨ ਲਈ API ਮਾਨਕੀਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ; API ਤਬਦੀਲੀਆਂ, ਅੱਗੇ ਅਤੇ ਪਿੱਛੇ ਅਨੁਕੂਲਤਾ ਵੱਲ ਵਧੇਰੇ ਧਿਆਨ ਦੇਣ ਦੀ ਲੋੜ ਹੈ;
• ਹਰੇਕ ਅਜਿਹੇ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਵਪਾਰਕ ਤਰਕ ਦੇ ਕੰਮਕਾਜ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਵਾਧੂ ਰਨਟਾਈਮ ਲਾਇਬ੍ਰੇਰੀਆਂ ਨੂੰ ਜੋੜਨਾ ਜ਼ਰੂਰੀ ਹੈ, ਅਤੇ ਇਹ ਅਜਿਹੀਆਂ ਲਾਇਬ੍ਰੇਰੀਆਂ ਲਈ ਨਵੀਆਂ ਲੋੜਾਂ ਨੂੰ ਜਨਮ ਦਿੰਦਾ ਹੈ: ਹਲਕੀਤਾ ਅਤੇ ਘੱਟੋ-ਘੱਟ ਪਰਿਵਰਤਨਸ਼ੀਲ ਨਿਰਭਰਤਾ;
• ਬਿਜ਼ਨਸ ਤਰਕ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਲਾਇਬ੍ਰੇਰੀ ਸੰਸਕਰਣਾਂ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ: ਜੇਕਰ ਇੱਕ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਨੂੰ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਅੰਤਿਮ ਰੂਪ ਨਹੀਂ ਦਿੱਤਾ ਗਿਆ ਹੈ, ਤਾਂ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ ਇਸ ਵਿੱਚ ਲਾਇਬ੍ਰੇਰੀਆਂ ਦਾ ਪੁਰਾਣਾ ਸੰਸਕਰਣ ਸ਼ਾਮਲ ਹੋਵੇਗਾ। ਇਹ ਇੱਕ ਨਵੀਂ ਵਿਸ਼ੇਸ਼ਤਾ ਜੋੜਨ ਵਿੱਚ ਇੱਕ ਅਚਾਨਕ ਰੁਕਾਵਟ ਹੋ ਸਕਦੀ ਹੈ ਅਤੇ ਜੇਕਰ ਸੰਸਕਰਣਾਂ ਵਿੱਚ ਅਸੰਗਤ ਤਬਦੀਲੀਆਂ ਹੁੰਦੀਆਂ ਹਨ ਤਾਂ ਲਾਇਬ੍ਰੇਰੀਆਂ ਦੇ ਨਵੇਂ ਸੰਸਕਰਣਾਂ ਵਿੱਚ ਅਜਿਹੀ ਸੇਵਾ ਦੇ ਪੁਰਾਣੇ ਵਪਾਰਕ ਤਰਕ ਨੂੰ ਮਾਈਗਰੇਟ ਕਰਨ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ।

ਪਲੇਟਫਾਰਮ ਸੇਵਾਵਾਂ ਦੀ ਇੱਕ ਪਰਤ ਵੀ ਅਜਿਹੀ ਆਰਕੀਟੈਕਚਰ ਵਿੱਚ ਮੌਜੂਦ ਹੈ, ਪਰ ਇਹ ਪਰਤ ਹੁਣ ਡੋਮੇਨ ਵਪਾਰਕ ਤਰਕ ਨੂੰ ਚਲਾਉਣ ਲਈ ਇੱਕ ਕੰਟੇਨਰ ਨਹੀਂ ਬਣਾਉਂਦੀ ਹੈ, ਪਰ ਸਿਰਫ ਇਸਦਾ ਵਾਤਾਵਰਣ, ਸਹਾਇਕ "ਪਲੇਟਫਾਰਮ" ਫੰਕਸ਼ਨ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਅਜਿਹੀ ਪਰਤ ਦੀ ਲੋੜ ਨਾ ਸਿਰਫ਼ ਡੋਮੇਨ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਦੇ ਹਲਕੇ ਸੁਭਾਅ ਨੂੰ ਬਣਾਈ ਰੱਖਣ ਲਈ ਹੈ, ਸਗੋਂ ਪ੍ਰਬੰਧਨ ਨੂੰ ਕੇਂਦਰਿਤ ਕਰਨ ਲਈ ਵੀ ਹੈ।

ਉਦਾਹਰਨ ਲਈ, ਵਪਾਰਕ ਪ੍ਰਕਿਰਿਆਵਾਂ ਵਿੱਚ ਉਪਭੋਗਤਾ ਗਤੀਵਿਧੀਆਂ ਕਾਰਜ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ। ਹਾਲਾਂਕਿ, ਕਾਰਜਾਂ ਦੇ ਨਾਲ ਕੰਮ ਕਰਦੇ ਸਮੇਂ, ਉਪਭੋਗਤਾ ਨੂੰ ਆਮ ਸੂਚੀ ਵਿੱਚ ਸਾਰੇ ਡੋਮੇਨਾਂ ਤੋਂ ਕਾਰਜਾਂ ਨੂੰ ਦੇਖਣਾ ਚਾਹੀਦਾ ਹੈ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਡੋਮੇਨ ਕਾਰੋਬਾਰ ਦੇ ਤਰਕ ਤੋਂ ਸਾਫ਼ ਇੱਕ ਅਨੁਸਾਰੀ ਪਲੇਟਫਾਰਮ ਟਾਸਕ ਰਜਿਸਟ੍ਰੇਸ਼ਨ ਸੇਵਾ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਅਜਿਹੇ ਸੰਦਰਭ ਵਿੱਚ ਵਪਾਰਕ ਤਰਕ ਦੇ ਐਨਕੈਪਸੂਲੇਸ਼ਨ ਨੂੰ ਕਾਇਮ ਰੱਖਣਾ ਕਾਫ਼ੀ ਸਮੱਸਿਆ ਵਾਲਾ ਹੈ, ਅਤੇ ਇਹ ਇਸ ਆਰਕੀਟੈਕਚਰ ਦਾ ਇੱਕ ਹੋਰ ਸਮਝੌਤਾ ਹੈ।

ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਡਿਵੈਲਪਰ ਦੀਆਂ ਅੱਖਾਂ ਦੁਆਰਾ ਵਪਾਰਕ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦਾ ਏਕੀਕਰਣ

ਜਿਵੇਂ ਕਿ ਉੱਪਰ ਦੱਸਿਆ ਗਿਆ ਹੈ, ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਡਿਵੈਲਪਰ ਨੂੰ ਕਈ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੇ ਆਪਸੀ ਤਾਲਮੇਲ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀਆਂ ਤਕਨੀਕੀ ਅਤੇ ਇੰਜੀਨੀਅਰਿੰਗ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਤੋਂ ਵੱਖ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਜੋ ਕੋਈ ਚੰਗੀ ਵਿਕਾਸ ਉਤਪਾਦਕਤਾ 'ਤੇ ਭਰੋਸਾ ਕਰ ਸਕੇ।

ਆਉ ਇੱਕ ਮੁਸ਼ਕਲ ਏਕੀਕਰਣ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ, ਖਾਸ ਤੌਰ 'ਤੇ ਲੇਖ ਲਈ ਖੋਜ ਕੀਤੀ ਗਈ ਹੈ. ਇਹ ਇੱਕ "ਗੇਮ" ਕਾਰਜ ਹੋਵੇਗਾ ਜਿਸ ਵਿੱਚ ਤਿੰਨ ਐਪਲੀਕੇਸ਼ਨ ਸ਼ਾਮਲ ਹਨ, ਜਿੱਥੇ ਉਹਨਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਇੱਕ ਖਾਸ ਡੋਮੇਨ ਨਾਮ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ: "ਐਪ1", "ਐਪ2", "ਐਪ3".

ਹਰੇਕ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਅੰਦਰ, ਕਾਰੋਬਾਰੀ ਪ੍ਰਕਿਰਿਆਵਾਂ ਸ਼ੁਰੂ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ ਜੋ ਏਕੀਕਰਣ ਬੱਸ ਦੁਆਰਾ "ਬਾਲ ਖੇਡਣ" ਨੂੰ ਸ਼ੁਰੂ ਕਰਦੀਆਂ ਹਨ। "ਬਾਲ" ਨਾਮ ਵਾਲੇ ਸੁਨੇਹੇ ਇੱਕ ਗੇਂਦ ਦੇ ਰੂਪ ਵਿੱਚ ਕੰਮ ਕਰਨਗੇ।

ਖੇਡ ਦੇ ਨਿਯਮ:

• ਪਹਿਲਾ ਖਿਡਾਰੀ ਸ਼ੁਰੂਆਤ ਕਰਨ ਵਾਲਾ ਹੈ। ਉਹ ਦੂਜੇ ਖਿਡਾਰੀਆਂ ਨੂੰ ਖੇਡ ਲਈ ਸੱਦਾ ਦਿੰਦਾ ਹੈ, ਖੇਡ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਕਿਸੇ ਵੀ ਸਮੇਂ ਖਤਮ ਕਰ ਸਕਦਾ ਹੈ;
• ਦੂਜੇ ਖਿਡਾਰੀ ਖੇਡ ਵਿੱਚ ਆਪਣੀ ਭਾਗੀਦਾਰੀ ਦਾ ਐਲਾਨ ਕਰਦੇ ਹਨ, ਇੱਕ ਦੂਜੇ ਅਤੇ ਪਹਿਲੇ ਖਿਡਾਰੀ ਨੂੰ "ਜਾਣੋ";
• ਗੇਂਦ ਪ੍ਰਾਪਤ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਖਿਡਾਰੀ ਇੱਕ ਹੋਰ ਭਾਗ ਲੈਣ ਵਾਲੇ ਖਿਡਾਰੀ ਨੂੰ ਚੁਣਦਾ ਹੈ ਅਤੇ ਉਸ ਨੂੰ ਗੇਂਦ ਦਿੰਦਾ ਹੈ। ਪ੍ਰਸਾਰਣ ਦੀ ਕੁੱਲ ਗਿਣਤੀ ਗਿਣੀ ਜਾਂਦੀ ਹੈ;
• ਹਰੇਕ ਖਿਡਾਰੀ ਵਿੱਚ "ਊਰਜਾ" ਹੁੰਦੀ ਹੈ ਜੋ ਉਸ ਖਿਡਾਰੀ ਦੁਆਰਾ ਗੇਂਦ ਦੇ ਹਰੇਕ ਪਾਸ ਨਾਲ ਘਟਦੀ ਹੈ। ਜਦੋਂ ਊਰਜਾ ਖਤਮ ਹੋ ਜਾਂਦੀ ਹੈ, ਖਿਡਾਰੀ ਆਪਣੇ ਅਸਤੀਫੇ ਦੀ ਘੋਸ਼ਣਾ ਕਰਦੇ ਹੋਏ ਖੇਡ ਨੂੰ ਛੱਡ ਦਿੰਦਾ ਹੈ;
• ਜੇ ਖਿਡਾਰੀ ਨੂੰ ਇਕੱਲਾ ਛੱਡ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਉਹ ਤੁਰੰਤ ਆਪਣੇ ਜਾਣ ਦਾ ਐਲਾਨ ਕਰਦਾ ਹੈ;
• ਜਦੋਂ ਸਾਰੇ ਖਿਡਾਰੀ ਖਤਮ ਹੋ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਪਹਿਲਾ ਖਿਡਾਰੀ ਖੇਡ ਖਤਮ ਹੋਣ ਦਾ ਐਲਾਨ ਕਰਦਾ ਹੈ। ਜੇ ਉਹ ਖੇਡ ਨੂੰ ਜਲਦੀ ਛੱਡ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਉਹ ਇਸਨੂੰ ਪੂਰਾ ਕਰਨ ਲਈ ਖੇਡ ਦਾ ਪਾਲਣ ਕਰਨਾ ਰਹਿੰਦਾ ਹੈ।

ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ, ਮੈਂ ਵਪਾਰਕ ਪ੍ਰਕਿਰਿਆਵਾਂ ਲਈ ਸਾਡੇ DSL ਦੀ ਵਰਤੋਂ ਕਰਾਂਗਾ, ਜੋ ਸਾਨੂੰ ਘੱਟੋ-ਘੱਟ ਬੋਇਲਰਪਲੇਟ ਦੇ ਨਾਲ, ਕੋਟਲਿਨ ਵਿੱਚ ਤਰਕ ਨੂੰ ਸੰਖੇਪ ਰੂਪ ਵਿੱਚ ਵਰਣਨ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ।

ਪਹਿਲੇ ਖਿਡਾਰੀ ਦੀ ਵਪਾਰਕ ਪ੍ਰਕਿਰਿਆ (ਉਰਫ਼ ਗੇਮ ਦੀ ਸ਼ੁਰੂਆਤ ਕਰਨ ਵਾਲਾ) ਐਪ1 ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਕੰਮ ਕਰੇਗੀ:

ਕਲਾਸ ਸ਼ੁਰੂਆਤੀ ਪਲੇਅਰ

import ru.krista.bpm.ProcessInstance
import ru.krista.bpm.runtime.ProcessImpl
import ru.krista.bpm.runtime.constraint.UniqueConstraints
import ru.krista.bpm.runtime.dsl.processModel
import ru.krista.bpm.runtime.dsl.taskOperation
import ru.krista.bpm.runtime.instance.MessageSendInstance

data class PlayerInfo(val name: String, val domain: String, val id: String)

class PlayersList : ArrayList<PlayerInfo>()

// Это класс экземпляра процесса: инкапсулирует его внутреннее состояние
class InitialPlayer : ProcessImpl<InitialPlayer>(initialPlayerModel) {
    var playerName: String by persistent("Player1")
    var energy: Int by persistent(30)
    var players: PlayersList by persistent(PlayersList())
    var shotCounter: Int = 0
}

// Это декларация модели процесса: создается один раз, используется всеми
// экземплярами процесса соответствующего класса
val initialPlayerModel = processModel<InitialPlayer>(name = "InitialPlayer",
                                                     version = 1) {

    // По правилам, первый игрок является инициатором игры и должен быть единственным
    uniqueConstraint = UniqueConstraints.singleton

    // Объявляем активности, из которых состоит бизнес-процесс
    val sendNewGameSignal = signal<String>("NewGame")
    val sendStopGameSignal = signal<String>("StopGame")
    val startTask = humanTask("Start") {
        taskOperation {
            processCondition { players.size > 0 }
            confirmation { "Подключилось ${players.size} игроков. Начинаем?" }
        }
    }
    val stopTask = humanTask("Stop") {
        taskOperation {}
    }
    val waitPlayerJoin = signalWait<String>("PlayerJoin") { signal ->
        players.add(PlayerInfo(
                signal.data!!,
                signal.sender.domain,
                signal.sender.processInstanceId))
        println("... join player ${signal.data} ...")
    }
    val waitPlayerOut = signalWait<String>("PlayerOut") { signal ->
        players.remove(PlayerInfo(
                signal.data!!,
                signal.sender.domain,
                signal.sender.processInstanceId))
        println("... player ${signal.data} is out ...")
    }
    val sendPlayerOut = signal<String>("PlayerOut") {
        signalData = { playerName }
    }
    val sendHandshake = messageSend<String>("Handshake") {
        messageData = { playerName }
        activation = {
            receiverDomain = process.players.last().domain
            receiverProcessInstanceId = process.players.last().id
        }
    }
    val throwStartBall = messageSend<Int>("Ball") {
        messageData = { 1 }
        activation = { selectNextPlayer() }
    }
    val throwBall = messageSend<Int>("Ball") {
        messageData = { shotCounter + 1 }
        activation = { selectNextPlayer() }
        onEntry { energy -= 1 }
    }
    val waitBall = messageWaitData<Int>("Ball") {
        shotCounter = it
    }

    // Теперь конструируем граф процесса из объявленных активностей
    startFrom(sendNewGameSignal)
            .fork("mainFork") {
                next(startTask)
                next(waitPlayerJoin).next(sendHandshake).next(waitPlayerJoin)
                next(waitPlayerOut)
                        .branch("checkPlayers") {
                            ifTrue { players.isEmpty() }
                                    .next(sendStopGameSignal)
                                    .terminate()
                            ifElse().next(waitPlayerOut)
                        }
            }
    startTask.fork("afterStart") {
        next(throwStartBall)
                .branch("mainLoop") {
                    ifTrue { energy < 5 }.next(sendPlayerOut).next(waitBall)
                    ifElse().next(waitBall).next(throwBall).loop()
                }
        next(stopTask).next(sendStopGameSignal)
    }

    // Навешаем на активности дополнительные обработчики для логирования
    sendNewGameSignal.onExit { println("Let's play!") }
    sendStopGameSignal.onExit { println("Stop!") }
    sendPlayerOut.onExit { println("$playerName: I'm out!") }
}

private fun MessageSendInstance<InitialPlayer, Int>.selectNextPlayer() {
    val player = process.players.random()
    receiverDomain = player.domain
    receiverProcessInstanceId = player.id
    println("Step ${process.shotCounter + 1}: " +
            "${process.playerName} >>> ${player.name}")
}

ਕਾਰੋਬਾਰੀ ਤਰਕ ਨੂੰ ਚਲਾਉਣ ਦੇ ਨਾਲ-ਨਾਲ, ਉਪਰੋਕਤ ਕੋਡ ਇੱਕ ਵਪਾਰਕ ਪ੍ਰਕਿਰਿਆ ਦਾ ਇੱਕ ਆਬਜੈਕਟ ਮਾਡਲ ਤਿਆਰ ਕਰ ਸਕਦਾ ਹੈ, ਜਿਸਨੂੰ ਇੱਕ ਚਿੱਤਰ ਦੇ ਰੂਪ ਵਿੱਚ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਅਸੀਂ ਅਜੇ ਤੱਕ ਵਿਜ਼ੂਅਲਾਈਜ਼ਰ ਨੂੰ ਲਾਗੂ ਨਹੀਂ ਕੀਤਾ ਹੈ, ਇਸਲਈ ਸਾਨੂੰ ਡਰਾਇੰਗ ਕਰਨ ਵਿੱਚ ਥੋੜ੍ਹਾ ਸਮਾਂ ਬਿਤਾਉਣਾ ਪਿਆ (ਇੱਥੇ ਮੈਂ ਹੇਠਾਂ ਦਿੱਤੇ ਕੋਡ ਨਾਲ ਚਿੱਤਰ ਦੀ ਇਕਸਾਰਤਾ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਲਈ ਗੇਟਾਂ ਦੀ ਵਰਤੋਂ ਦੇ ਸਬੰਧ ਵਿੱਚ BPMN ਨੋਟੇਸ਼ਨ ਨੂੰ ਥੋੜ੍ਹਾ ਜਿਹਾ ਸਰਲ ਕੀਤਾ ਹੈ):

ਐਪ 2 ਵਿੱਚ ਦੂਜੇ ਖਿਡਾਰੀ ਦੀ ਕਾਰੋਬਾਰੀ ਪ੍ਰਕਿਰਿਆ ਸ਼ਾਮਲ ਹੋਵੇਗੀ:

ਸ਼੍ਰੇਣੀ ਰੈਂਡਮ ਪਲੇਅਰ

import ru.krista.bpm.ProcessInstance
import ru.krista.bpm.runtime.ProcessImpl
import ru.krista.bpm.runtime.dsl.processModel
import ru.krista.bpm.runtime.instance.MessageSendInstance

data class PlayerInfo(val name: String, val domain: String, val id: String)

class PlayersList: ArrayList<PlayerInfo>()

class RandomPlayer : ProcessImpl<RandomPlayer>(randomPlayerModel) {

    var playerName: String by input(persistent = true, 
                                    defaultValue = "RandomPlayer")
    var energy: Int by input(persistent = true, defaultValue = 30)
    var players: PlayersList by persistent(PlayersList())
    var allPlayersOut: Boolean by persistent(false)
    var shotCounter: Int = 0

    val selfPlayer: PlayerInfo
        get() = PlayerInfo(playerName, env.eventDispatcher.domainName, id)
}

val randomPlayerModel = processModel<RandomPlayer>(name = "RandomPlayer", 
                                                   version = 1) {

    val waitNewGameSignal = signalWait<String>("NewGame")
    val waitStopGameSignal = signalWait<String>("StopGame")
    val sendPlayerJoin = signal<String>("PlayerJoin") {
        signalData = { playerName }
    }
    val sendPlayerOut = signal<String>("PlayerOut") {
        signalData = { playerName }
    }
    val waitPlayerJoin = signalWaitCustom<String>("PlayerJoin") {
        eventCondition = { signal ->
            signal.sender.processInstanceId != process.id 
                && !process.players.any { signal.sender.processInstanceId == it.id}
        }
        handler = { signal ->
            players.add(PlayerInfo(
                    signal.data!!,
                    signal.sender.domain,
                    signal.sender.processInstanceId))
        }
    }
    val waitPlayerOut = signalWait<String>("PlayerOut") { signal ->
        players.remove(PlayerInfo(
                signal.data!!,
                signal.sender.domain,
                signal.sender.processInstanceId))
        allPlayersOut = players.isEmpty()
    }
    val sendHandshake = messageSend<String>("Handshake") {
        messageData = { playerName }
        activation = {
            receiverDomain = process.players.last().domain
            receiverProcessInstanceId = process.players.last().id
        }
    }
    val receiveHandshake = messageWait<String>("Handshake") { message ->
        if (!players.any { message.sender.processInstanceId == it.id}) {
            players.add(PlayerInfo(
                    message.data!!, 
                    message.sender.domain, 
                    message.sender.processInstanceId))
        }
    }
    val throwBall = messageSend<Int>("Ball") {
        messageData = { shotCounter + 1 }
        activation = { selectNextPlayer() }
        onEntry { energy -= 1 }
    }
    val waitBall = messageWaitData<Int>("Ball") {
        shotCounter = it
    }

    startFrom(waitNewGameSignal)
            .fork("mainFork") {
                next(sendPlayerJoin)
                        .branch("mainLoop") {
                            ifTrue { energy < 5 || allPlayersOut }
                                    .next(sendPlayerOut)
                                    .next(waitBall)
                            ifElse()
                                    .next(waitBall)
                                    .next(throwBall)
                                    .loop()
                        }
                next(waitPlayerJoin).next(sendHandshake).next(waitPlayerJoin)
                next(waitPlayerOut).next(waitPlayerOut)
                next(receiveHandshake).next(receiveHandshake)
                next(waitStopGameSignal).terminate()
            }

    sendPlayerJoin.onExit { println("$playerName: I'm here!") }
    sendPlayerOut.onExit { println("$playerName: I'm out!") }
}

private fun MessageSendInstance<RandomPlayer, Int>.selectNextPlayer() {
    val player = if (process.players.isNotEmpty()) 
        process.players.random() 
    else 
        process.selfPlayer
    receiverDomain = player.domain
    receiverProcessInstanceId = player.id
    println("Step ${process.shotCounter + 1}: " +
            "${process.playerName} >>> ${player.name}")
}

ਚਿੱਤਰ:

ਐਪ 3 ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਅਸੀਂ ਇੱਕ ਖਿਡਾਰੀ ਨੂੰ ਥੋੜ੍ਹਾ ਵੱਖਰਾ ਵਿਹਾਰ ਬਣਾਵਾਂਗੇ: ਬੇਤਰਤੀਬ ਢੰਗ ਨਾਲ ਅਗਲੇ ਖਿਡਾਰੀ ਦੀ ਚੋਣ ਕਰਨ ਦੀ ਬਜਾਏ, ਉਹ ਰਾਊਂਡ-ਰੋਬਿਨ ਐਲਗੋਰਿਦਮ ਦੇ ਅਨੁਸਾਰ ਕੰਮ ਕਰੇਗਾ:

ਕਲਾਸ RoundRobinPlayer

import ru.krista.bpm.ProcessInstance
import ru.krista.bpm.runtime.ProcessImpl
import ru.krista.bpm.runtime.dsl.processModel
import ru.krista.bpm.runtime.instance.MessageSendInstance

data class PlayerInfo(val name: String, val domain: String, val id: String)

class PlayersList: ArrayList<PlayerInfo>()

class RoundRobinPlayer : ProcessImpl<RoundRobinPlayer>(roundRobinPlayerModel) {

    var playerName: String by input(persistent = true, 
                                    defaultValue = "RoundRobinPlayer")
    var energy: Int by input(persistent = true, defaultValue = 30)
    var players: PlayersList by persistent(PlayersList())
    var nextPlayerIndex: Int by persistent(-1)
    var allPlayersOut: Boolean by persistent(false)
    var shotCounter: Int = 0

    val selfPlayer: PlayerInfo
        get() = PlayerInfo(playerName, env.eventDispatcher.domainName, id)
}

val roundRobinPlayerModel = processModel<RoundRobinPlayer>(
        name = "RoundRobinPlayer", 
        version = 1) {

    val waitNewGameSignal = signalWait<String>("NewGame")
    val waitStopGameSignal = signalWait<String>("StopGame")
    val sendPlayerJoin = signal<String>("PlayerJoin") {
        signalData = { playerName }
    }
    val sendPlayerOut = signal<String>("PlayerOut") {
        signalData = { playerName }
    }
    val waitPlayerJoin = signalWaitCustom<String>("PlayerJoin") {
        eventCondition = { signal ->
            signal.sender.processInstanceId != process.id 
                && !process.players.any { signal.sender.processInstanceId == it.id}
        }
        handler = { signal ->
            players.add(PlayerInfo(
                    signal.data!!, 
                    signal.sender.domain, 
                    signal.sender.processInstanceId))
        }
    }
    val waitPlayerOut = signalWait<String>("PlayerOut") { signal ->
        players.remove(PlayerInfo(
                signal.data!!, 
                signal.sender.domain, 
                signal.sender.processInstanceId))
        allPlayersOut = players.isEmpty()
    }
    val sendHandshake = messageSend<String>("Handshake") {
        messageData = { playerName }
        activation = {
            receiverDomain = process.players.last().domain
            receiverProcessInstanceId = process.players.last().id
        }
    }
    val receiveHandshake = messageWait<String>("Handshake") { message ->
        if (!players.any { message.sender.processInstanceId == it.id}) {
            players.add(PlayerInfo(
                    message.data!!, 
                    message.sender.domain, 
                    message.sender.processInstanceId))
        }
    }
    val throwBall = messageSend<Int>("Ball") {
        messageData = { shotCounter + 1 }
        activation = { selectNextPlayer() }
        onEntry { energy -= 1 }
    }
    val waitBall = messageWaitData<Int>("Ball") {
        shotCounter = it
    }

    startFrom(waitNewGameSignal)
            .fork("mainFork") {
                next(sendPlayerJoin)
                        .branch("mainLoop") {
                            ifTrue { energy < 5 || allPlayersOut }
                                    .next(sendPlayerOut)
                                    .next(waitBall)
                            ifElse()
                                    .next(waitBall)
                                    .next(throwBall)
                                    .loop()
                        }
                next(waitPlayerJoin).next(sendHandshake).next(waitPlayerJoin)
                next(waitPlayerOut).next(waitPlayerOut)
                next(receiveHandshake).next(receiveHandshake)
                next(waitStopGameSignal).terminate()
            }

    sendPlayerJoin.onExit { println("$playerName: I'm here!") }
    sendPlayerOut.onExit { println("$playerName: I'm out!") }
}

private fun MessageSendInstance<RoundRobinPlayer, Int>.selectNextPlayer() {
    var idx = process.nextPlayerIndex + 1
    if (idx >= process.players.size) {
        idx = 0
    }
    process.nextPlayerIndex = idx
    val player = if (process.players.isNotEmpty()) 
        process.players[idx] 
    else 
        process.selfPlayer
    receiverDomain = player.domain
    receiverProcessInstanceId = player.id
    println("Step ${process.shotCounter + 1}: " +
            "${process.playerName} >>> ${player.name}")
}

ਨਹੀਂ ਤਾਂ, ਖਿਡਾਰੀ ਦਾ ਵਿਵਹਾਰ ਪਿਛਲੇ ਨਾਲੋਂ ਵੱਖਰਾ ਨਹੀਂ ਹੁੰਦਾ, ਇਸਲਈ ਚਿੱਤਰ ਨਹੀਂ ਬਦਲਦਾ।

ਹੁਣ ਸਾਨੂੰ ਇਹ ਸਭ ਚਲਾਉਣ ਲਈ ਇੱਕ ਟੈਸਟ ਦੀ ਲੋੜ ਹੈ. ਮੈਂ ਸਿਰਫ ਟੈਸਟ ਦਾ ਕੋਡ ਖੁਦ ਦੇਵਾਂਗਾ, ਤਾਂ ਕਿ ਲੇਖ ਨੂੰ ਇੱਕ ਬਾਇਲਰਪਲੇਟ ਨਾਲ ਗੜਬੜ ਨਾ ਕੀਤਾ ਜਾਵੇ (ਅਸਲ ਵਿੱਚ, ਮੈਂ ਹੋਰ ਕਾਰੋਬਾਰੀ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੇ ਏਕੀਕਰਣ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਪਹਿਲਾਂ ਬਣਾਏ ਗਏ ਟੈਸਟ ਵਾਤਾਵਰਨ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਸੀ):

ਟੈਸਟ ਗੇਮ()

@Test
public void testGame() throws InterruptedException {
    String pl2 = startProcess(app2, "RandomPlayer", playerParams("Player2", 20));
    String pl3 = startProcess(app2, "RandomPlayer", playerParams("Player3", 40));
    String pl4 = startProcess(app3, "RoundRobinPlayer", playerParams("Player4", 25));
    String pl5 = startProcess(app3, "RoundRobinPlayer", playerParams("Player5", 35));
    String pl1 = startProcess(app1, "InitialPlayer");
    // Теперь нужно немного подождать, пока игроки "познакомятся" друг с другом.
    // Ждать через sleep - плохое решение, зато самое простое. 
    // Не делайте так в серьезных тестах!
    Thread.sleep(1000);
    // Запускаем игру, закрывая пользовательскую активность
    assertTrue(closeTask(app1, pl1, "Start"));
    app1.getWaiting().waitProcessFinished(pl1);
    app2.getWaiting().waitProcessFinished(pl2);
    app2.getWaiting().waitProcessFinished(pl3);
    app3.getWaiting().waitProcessFinished(pl4);
    app3.getWaiting().waitProcessFinished(pl5);
}

private Map<String, Object> playerParams(String name, int energy) {
    Map<String, Object> params = new HashMap<>();
    params.put("playerName", name);
    params.put("energy", energy);
    return params;
}

ਆਉ ਟੈਸਟ ਚਲਾਉਂਦੇ ਹਾਂ ਅਤੇ ਲੌਗ ਨੂੰ ਵੇਖਦੇ ਹਾਂ:

ਕੰਸੋਲ ਆਉਟਪੁੱਟ

Взята блокировка ключа lock://app1/process/InitialPlayer
Let's play!
Снята блокировка ключа lock://app1/process/InitialPlayer
Player2: I'm here!
Player3: I'm here!
Player4: I'm here!
Player5: I'm here!
... join player Player2 ...
... join player Player4 ...
... join player Player3 ...
... join player Player5 ...
Step 1: Player1 >>> Player3
Step 2: Player3 >>> Player5
Step 3: Player5 >>> Player3
Step 4: Player3 >>> Player4
Step 5: Player4 >>> Player3
Step 6: Player3 >>> Player4
Step 7: Player4 >>> Player5
Step 8: Player5 >>> Player2
Step 9: Player2 >>> Player5
Step 10: Player5 >>> Player4
Step 11: Player4 >>> Player2
Step 12: Player2 >>> Player4
Step 13: Player4 >>> Player1
Step 14: Player1 >>> Player4
Step 15: Player4 >>> Player3
Step 16: Player3 >>> Player1
Step 17: Player1 >>> Player2
Step 18: Player2 >>> Player3
Step 19: Player3 >>> Player1
Step 20: Player1 >>> Player5
Step 21: Player5 >>> Player1
Step 22: Player1 >>> Player2
Step 23: Player2 >>> Player4
Step 24: Player4 >>> Player5
Step 25: Player5 >>> Player3
Step 26: Player3 >>> Player4
Step 27: Player4 >>> Player2
Step 28: Player2 >>> Player5
Step 29: Player5 >>> Player2
Step 30: Player2 >>> Player1
Step 31: Player1 >>> Player3
Step 32: Player3 >>> Player4
Step 33: Player4 >>> Player1
Step 34: Player1 >>> Player3
Step 35: Player3 >>> Player4
Step 36: Player4 >>> Player3
Step 37: Player3 >>> Player2
Step 38: Player2 >>> Player5
Step 39: Player5 >>> Player4
Step 40: Player4 >>> Player5
Step 41: Player5 >>> Player1
Step 42: Player1 >>> Player5
Step 43: Player5 >>> Player3
Step 44: Player3 >>> Player5
Step 45: Player5 >>> Player2
Step 46: Player2 >>> Player3
Step 47: Player3 >>> Player2
Step 48: Player2 >>> Player5
Step 49: Player5 >>> Player4
Step 50: Player4 >>> Player2
Step 51: Player2 >>> Player5
Step 52: Player5 >>> Player1
Step 53: Player1 >>> Player5
Step 54: Player5 >>> Player3
Step 55: Player3 >>> Player5
Step 56: Player5 >>> Player2
Step 57: Player2 >>> Player1
Step 58: Player1 >>> Player4
Step 59: Player4 >>> Player1
Step 60: Player1 >>> Player4
Step 61: Player4 >>> Player3
Step 62: Player3 >>> Player2
Step 63: Player2 >>> Player5
Step 64: Player5 >>> Player4
Step 65: Player4 >>> Player5
Step 66: Player5 >>> Player1
Step 67: Player1 >>> Player5
Step 68: Player5 >>> Player3
Step 69: Player3 >>> Player4
Step 70: Player4 >>> Player2
Step 71: Player2 >>> Player5
Step 72: Player5 >>> Player2
Step 73: Player2 >>> Player1
Step 74: Player1 >>> Player4
Step 75: Player4 >>> Player1
Step 76: Player1 >>> Player2
Step 77: Player2 >>> Player5
Step 78: Player5 >>> Player4
Step 79: Player4 >>> Player3
Step 80: Player3 >>> Player1
Step 81: Player1 >>> Player5
Step 82: Player5 >>> Player1
Step 83: Player1 >>> Player4
Step 84: Player4 >>> Player5
Step 85: Player5 >>> Player3
Step 86: Player3 >>> Player5
Step 87: Player5 >>> Player2
Step 88: Player2 >>> Player3
Player2: I'm out!
Step 89: Player3 >>> Player4
... player Player2 is out ...
Step 90: Player4 >>> Player1
Step 91: Player1 >>> Player3
Step 92: Player3 >>> Player1
Step 93: Player1 >>> Player4
Step 94: Player4 >>> Player3
Step 95: Player3 >>> Player5
Step 96: Player5 >>> Player1
Step 97: Player1 >>> Player5
Step 98: Player5 >>> Player3
Step 99: Player3 >>> Player5
Step 100: Player5 >>> Player4
Step 101: Player4 >>> Player5
Player4: I'm out!
... player Player4 is out ...
Step 102: Player5 >>> Player1
Step 103: Player1 >>> Player3
Step 104: Player3 >>> Player1
Step 105: Player1 >>> Player3
Step 106: Player3 >>> Player5
Step 107: Player5 >>> Player3
Step 108: Player3 >>> Player1
Step 109: Player1 >>> Player3
Step 110: Player3 >>> Player5
Step 111: Player5 >>> Player1
Step 112: Player1 >>> Player3
Step 113: Player3 >>> Player5
Step 114: Player5 >>> Player3
Step 115: Player3 >>> Player1
Step 116: Player1 >>> Player3
Step 117: Player3 >>> Player5
Step 118: Player5 >>> Player1
Step 119: Player1 >>> Player3
Step 120: Player3 >>> Player5
Step 121: Player5 >>> Player3
Player5: I'm out!
... player Player5 is out ...
Step 122: Player3 >>> Player5
Step 123: Player5 >>> Player1
Player5: I'm out!
Step 124: Player1 >>> Player3
... player Player5 is out ...
Step 125: Player3 >>> Player1
Step 126: Player1 >>> Player3
Player1: I'm out!
... player Player1 is out ...
Step 127: Player3 >>> Player3
Player3: I'm out!
Step 128: Player3 >>> Player3
... player Player3 is out ...
Player3: I'm out!
Stop!
Step 129: Player3 >>> Player3
Player3: I'm out!

ਇਸ ਸਭ ਤੋਂ ਅਸੀਂ ਕਈ ਮਹੱਤਵਪੂਰਨ ਸਿੱਟੇ ਕੱਢ ਸਕਦੇ ਹਾਂ:

• ਲੋੜੀਂਦੇ ਟੂਲਸ ਦੇ ਨਾਲ, ਐਪਲੀਕੇਸ਼ਨ ਡਿਵੈਲਪਰ ਬਿਜ਼ਨਸ ਤਰਕ ਨੂੰ ਰੋਕੇ ਬਿਨਾਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿਚਕਾਰ ਏਕੀਕਰਣ ਪਰਸਪਰ ਪ੍ਰਭਾਵ ਬਣਾ ਸਕਦੇ ਹਨ;
• ਇੱਕ ਏਕੀਕਰਣ ਕਾਰਜ ਦੀ ਗੁੰਝਲਤਾ ਜਿਸ ਲਈ ਇੰਜੀਨੀਅਰਿੰਗ ਯੋਗਤਾਵਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਨੂੰ ਫਰੇਮਵਰਕ ਦੇ ਅੰਦਰ ਲੁਕਾਇਆ ਜਾ ਸਕਦਾ ਹੈ ਜੇਕਰ ਇਹ ਸ਼ੁਰੂਆਤੀ ਰੂਪ ਵਿੱਚ ਫਰੇਮਵਰਕ ਦੇ ਆਰਕੀਟੈਕਚਰ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਕਿਸੇ ਸਮੱਸਿਆ ਦੀ ਮੁਸ਼ਕਲ ਨੂੰ ਲੁਕਾਇਆ ਨਹੀਂ ਜਾ ਸਕਦਾ, ਇਸ ਲਈ ਕੋਡ ਵਿੱਚ ਇੱਕ ਮੁਸ਼ਕਲ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦੇਵੇਗਾ;
• ਏਕੀਕਰਣ ਤਰਕ ਦਾ ਵਿਕਾਸ ਕਰਦੇ ਸਮੇਂ, ਅੰਤਮ ਇਕਸਾਰਤਾ ਅਤੇ ਸਾਰੇ ਏਕੀਕਰਣ ਭਾਗੀਦਾਰਾਂ ਦੀ ਸਥਿਤੀ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਦੀ ਰੇਖਿਕਤਾ ਦੀ ਘਾਟ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣਾ ਲਾਜ਼ਮੀ ਹੈ। ਇਹ ਸਾਨੂੰ ਤਰਕ ਨੂੰ ਗੁੰਝਲਦਾਰ ਬਣਾਉਣ ਲਈ ਮਜ਼ਬੂਰ ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ ਇਸ ਨੂੰ ਉਸ ਕ੍ਰਮ ਪ੍ਰਤੀ ਅਸੰਵੇਦਨਸ਼ੀਲ ਬਣਾਇਆ ਜਾ ਸਕੇ ਜਿਸ ਵਿੱਚ ਬਾਹਰੀ ਘਟਨਾਵਾਂ ਵਾਪਰਦੀਆਂ ਹਨ। ਸਾਡੇ ਉਦਾਹਰਨ ਵਿੱਚ, ਖਿਡਾਰੀ ਨੂੰ ਖੇਡ ਤੋਂ ਬਾਹਰ ਹੋਣ ਦਾ ਐਲਾਨ ਕਰਨ ਤੋਂ ਬਾਅਦ ਗੇਮ ਵਿੱਚ ਹਿੱਸਾ ਲੈਣ ਲਈ ਮਜਬੂਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ: ਦੂਜੇ ਖਿਡਾਰੀ ਉਸ ਨੂੰ ਗੇਂਦ ਨੂੰ ਪਾਸ ਕਰਨਾ ਜਾਰੀ ਰੱਖਣਗੇ ਜਦੋਂ ਤੱਕ ਉਸਦੇ ਬਾਹਰ ਜਾਣ ਦੀ ਜਾਣਕਾਰੀ ਨਹੀਂ ਪਹੁੰਚ ਜਾਂਦੀ ਅਤੇ ਸਾਰੇ ਭਾਗੀਦਾਰਾਂ ਦੁਆਰਾ ਪ੍ਰਕਿਰਿਆ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ। ਇਹ ਤਰਕ ਖੇਡ ਦੇ ਨਿਯਮਾਂ ਦੀ ਪਾਲਣਾ ਨਹੀਂ ਕਰਦਾ ਹੈ ਅਤੇ ਚੁਣੇ ਗਏ ਆਰਕੀਟੈਕਚਰ ਦੇ ਢਾਂਚੇ ਦੇ ਅੰਦਰ ਇੱਕ ਸਮਝੌਤਾ ਹੱਲ ਹੈ।

ਅੱਗੇ, ਅਸੀਂ ਆਪਣੇ ਹੱਲ, ਸਮਝੌਤਿਆਂ ਅਤੇ ਹੋਰ ਨੁਕਤਿਆਂ ਦੀਆਂ ਵੱਖ-ਵੱਖ ਪੇਚੀਦਗੀਆਂ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗੇ।

ਸਾਰੇ ਸੁਨੇਹੇ ਇੱਕ ਕਤਾਰ ਵਿੱਚ ਹਨ

ਸਾਰੀਆਂ ਏਕੀਕ੍ਰਿਤ ਐਪਲੀਕੇਸ਼ਨਾਂ ਇੱਕ ਏਕੀਕਰਣ ਬੱਸ ਦੇ ਨਾਲ ਕੰਮ ਕਰਦੀਆਂ ਹਨ, ਜੋ ਕਿ ਇੱਕ ਬਾਹਰੀ ਬ੍ਰੋਕਰ ਦੇ ਰੂਪ ਵਿੱਚ, ਸੰਦੇਸ਼ਾਂ ਲਈ ਇੱਕ BPMQueue ਅਤੇ ਸਿਗਨਲਾਂ (ਈਵੈਂਟਾਂ) ਲਈ ਇੱਕ BPMtopic ਵਿਸ਼ਾ ਦੇ ਰੂਪ ਵਿੱਚ ਪੇਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਸਾਰੇ ਸੰਦੇਸ਼ਾਂ ਨੂੰ ਇੱਕ ਕਤਾਰ ਵਿੱਚ ਪਾਉਣਾ ਆਪਣੇ ਆਪ ਵਿੱਚ ਇੱਕ ਸਮਝੌਤਾ ਹੈ। ਵਪਾਰਕ ਤਰਕ ਦੇ ਪੱਧਰ 'ਤੇ, ਤੁਸੀਂ ਹੁਣ ਸਿਸਟਮ ਢਾਂਚੇ ਵਿੱਚ ਬਦਲਾਅ ਕੀਤੇ ਬਿਨਾਂ ਜਿੰਨੀਆਂ ਵੀ ਨਵੀਆਂ ਸੁਨੇਹੇ ਕਿਸਮਾਂ ਨੂੰ ਪਸੰਦ ਕਰਦੇ ਹੋ, ਪੇਸ਼ ਕਰ ਸਕਦੇ ਹੋ। ਇਹ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਸਰਲੀਕਰਨ ਹੈ, ਪਰ ਇਸ ਵਿੱਚ ਕੁਝ ਜੋਖਮ ਹਨ, ਜੋ ਸਾਡੇ ਆਮ ਕੰਮਾਂ ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਸਾਡੇ ਲਈ ਇੰਨੇ ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ ਜਾਪਦੇ ਸਨ।

ਹਾਲਾਂਕਿ, ਇੱਥੇ ਇੱਕ ਸੂਖਮਤਾ ਹੈ: ਹਰੇਕ ਐਪਲੀਕੇਸ਼ਨ ਆਪਣੇ ਡੋਮੇਨ ਦੇ ਨਾਮ ਦੁਆਰਾ, ਪ੍ਰਵੇਸ਼ ਦੁਆਰ 'ਤੇ ਕਤਾਰ ਤੋਂ "ਇਸਦੇ" ਸੰਦੇਸ਼ਾਂ ਨੂੰ ਫਿਲਟਰ ਕਰਦੀ ਹੈ। ਡੋਮੇਨ ਨੂੰ ਸਿਗਨਲਾਂ ਵਿੱਚ ਵੀ ਨਿਸ਼ਚਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਜੇਕਰ ਤੁਹਾਨੂੰ ਸਿਗਨਲ ਦੀ "ਦ੍ਰਿਸ਼ਟੀ ਦੇ ਦਾਇਰੇ" ਨੂੰ ਇੱਕ ਸਿੰਗਲ ਐਪਲੀਕੇਸ਼ਨ ਤੱਕ ਸੀਮਿਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਇਸ ਨਾਲ ਬੱਸ ਥ੍ਰੁਪੁੱਟ ਵਿੱਚ ਵਾਧਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਪਰ ਵਪਾਰਕ ਤਰਕ ਨੂੰ ਹੁਣ ਡੋਮੇਨ ਨਾਮਾਂ ਨਾਲ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ: ਸੁਨੇਹਿਆਂ ਨੂੰ ਸੰਬੋਧਿਤ ਕਰਨ ਲਈ - ਲਾਜ਼ਮੀ, ਸਿਗਨਲਾਂ ਲਈ - ਫਾਇਦੇਮੰਦ।

ਏਕੀਕਰਣ ਬੱਸ ਭਰੋਸੇਯੋਗਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣਾ

ਭਰੋਸੇਯੋਗਤਾ ਵਿੱਚ ਕਈ ਬਿੰਦੂ ਹੁੰਦੇ ਹਨ:

• ਚੁਣਿਆ ਸੁਨੇਹਾ ਬ੍ਰੋਕਰ ਆਰਕੀਟੈਕਚਰ ਦਾ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਹਿੱਸਾ ਹੈ ਅਤੇ ਅਸਫਲਤਾ ਦਾ ਇੱਕ ਬਿੰਦੂ ਹੈ: ਇਹ ਕਾਫ਼ੀ ਨੁਕਸ-ਸਹਿਣਸ਼ੀਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਤੁਹਾਨੂੰ ਚੰਗੇ ਸਮਰਥਨ ਅਤੇ ਇੱਕ ਵੱਡੇ ਭਾਈਚਾਰੇ ਦੇ ਨਾਲ, ਸਿਰਫ ਸਮੇਂ-ਪਰੀਖਣ ਵਾਲੇ ਲਾਗੂਕਰਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ;
• ਸੁਨੇਹਾ ਬ੍ਰੋਕਰ ਦੀ ਉੱਚ ਉਪਲਬਧਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣਾ ਜ਼ਰੂਰੀ ਹੈ, ਜਿਸ ਲਈ ਇਸਨੂੰ ਏਕੀਕ੍ਰਿਤ ਐਪਲੀਕੇਸ਼ਨਾਂ ਤੋਂ ਭੌਤਿਕ ਤੌਰ 'ਤੇ ਵੱਖ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ (ਲਾਗੂ ਕਾਰੋਬਾਰੀ ਤਰਕ ਨਾਲ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੀ ਉੱਚ ਉਪਲਬਧਤਾ ਯਕੀਨੀ ਬਣਾਉਣਾ ਬਹੁਤ ਮੁਸ਼ਕਲ ਅਤੇ ਮਹਿੰਗਾ ਹੈ);
• ਬ੍ਰੋਕਰ "ਘੱਟੋ-ਘੱਟ ਇੱਕ ਵਾਰ" ਡਿਲੀਵਰੀ ਗਰੰਟੀ ਪ੍ਰਦਾਨ ਕਰਨ ਲਈ ਪਾਬੰਦ ਹੈ। ਏਕੀਕਰਣ ਬੱਸ ਦੇ ਭਰੋਸੇਯੋਗ ਸੰਚਾਲਨ ਲਈ ਇਹ ਇੱਕ ਲਾਜ਼ਮੀ ਲੋੜ ਹੈ। "ਬਿਲਕੁਲ ਇੱਕ ਵਾਰ" ਪੱਧਰ ਦੀ ਗਾਰੰਟੀ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਹੈ: ਵਪਾਰਕ ਪ੍ਰਕਿਰਿਆਵਾਂ, ਇੱਕ ਨਿਯਮ ਦੇ ਤੌਰ 'ਤੇ, ਸੁਨੇਹਿਆਂ ਜਾਂ ਸਮਾਗਮਾਂ ਦੇ ਵਾਰ-ਵਾਰ ਆਉਣ ਲਈ ਸੰਵੇਦਨਸ਼ੀਲ ਨਹੀਂ ਹੁੰਦੀਆਂ ਹਨ, ਅਤੇ ਵਿਸ਼ੇਸ਼ ਕਾਰਜਾਂ ਵਿੱਚ ਜਿੱਥੇ ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦਾ ਹੈ, ਕਾਰੋਬਾਰ ਵਿੱਚ ਵਾਧੂ ਜਾਂਚਾਂ ਨੂੰ ਜੋੜਨਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ। ਲਗਾਤਾਰ ਕਾਫ਼ੀ "ਮਹਿੰਗੀਆਂ" " ਗਰੰਟੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਨਾਲੋਂ ਤਰਕ;
• ਸੁਨੇਹੇ ਅਤੇ ਸਿਗਨਲ ਭੇਜਣਾ ਵਪਾਰਕ ਪ੍ਰਕਿਰਿਆਵਾਂ ਅਤੇ ਡੋਮੇਨ ਡੇਟਾ ਦੀ ਸਥਿਤੀ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਦੇ ਨਾਲ ਇੱਕ ਸਮੁੱਚੇ ਲੈਣ-ਦੇਣ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਤਰਜੀਹੀ ਵਿਕਲਪ ਪੈਟਰਨ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਹੋਵੇਗਾ ਟ੍ਰਾਂਜੈਕਸ਼ਨਲ ਆਉਟਬਾਕਸ, ਪਰ ਇਸ ਨੂੰ ਡੇਟਾਬੇਸ ਵਿੱਚ ਇੱਕ ਵਾਧੂ ਸਾਰਣੀ ਅਤੇ ਇੱਕ ਰੀਪੀਟਰ ਦੀ ਲੋੜ ਹੋਵੇਗੀ। ਜੇਈਈ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ, ਇਸਨੂੰ ਇੱਕ ਸਥਾਨਕ ਜੇਟੀਏ ਮੈਨੇਜਰ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸਰਲ ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਹੈ, ਪਰ ਚੁਣੇ ਹੋਏ ਬ੍ਰੋਕਰ ਨਾਲ ਕੁਨੈਕਸ਼ਨ ਕੰਮ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ XA;
• ਆਉਣ ਵਾਲੇ ਸੁਨੇਹਿਆਂ ਅਤੇ ਇਵੈਂਟਾਂ ਦੇ ਹੈਂਡਲਰਾਂ ਨੂੰ ਇੱਕ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਨਾਲ ਵੀ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਇੱਕ ਵਪਾਰਕ ਪ੍ਰਕਿਰਿਆ ਦੀ ਸਥਿਤੀ ਨੂੰ ਬਦਲਦਾ ਹੈ: ਜੇਕਰ ਅਜਿਹਾ ਲੈਣ-ਦੇਣ ਵਾਪਸ ਲਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਸੁਨੇਹੇ ਦੀ ਰਸੀਦ ਨੂੰ ਰੱਦ ਕਰ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ;
• ਸੁਨੇਹੇ ਜੋ ਗਲਤੀਆਂ ਦੇ ਕਾਰਨ ਡਿਲੀਵਰ ਨਹੀਂ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ ਇੱਕ ਵੱਖਰੀ ਸਟੋਰੇਜ ਵਿੱਚ ਸਟੋਰ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ ਡੀ.ਐਲ.ਕਿਊ. (ਡੈੱਡ ਲੈਟਰ ਕਤਾਰ)। ਇਸ ਮੰਤਵ ਲਈ, ਅਸੀਂ ਇੱਕ ਵੱਖਰਾ ਪਲੇਟਫਾਰਮ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਬਣਾਇਆ ਹੈ ਜੋ ਅਜਿਹੇ ਸੁਨੇਹਿਆਂ ਨੂੰ ਇਸਦੀ ਸਟੋਰੇਜ ਵਿੱਚ ਸਟੋਰ ਕਰਦਾ ਹੈ, ਉਹਨਾਂ ਨੂੰ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ (ਤੁਰੰਤ ਗਰੁੱਪਿੰਗ ਅਤੇ ਖੋਜ ਲਈ) ਦੁਆਰਾ ਸੂਚੀਬੱਧ ਕਰਦਾ ਹੈ, ਅਤੇ ਸੁਨੇਹਿਆਂ ਨੂੰ ਦੇਖਣ, ਮੰਜ਼ਿਲ ਪਤੇ 'ਤੇ ਮੁੜ ਭੇਜਣ ਅਤੇ ਮਿਟਾਉਣ ਲਈ ਇੱਕ API ਦਾ ਪਰਦਾਫਾਸ਼ ਕਰਦਾ ਹੈ। ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕ ਆਪਣੇ ਵੈੱਬ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਇਸ ਸੇਵਾ ਨਾਲ ਕੰਮ ਕਰ ਸਕਦੇ ਹਨ;
• ਬ੍ਰੋਕਰ ਸੈਟਿੰਗਾਂ ਵਿੱਚ, ਤੁਹਾਨੂੰ DLQ ਵਿੱਚ ਸੁਨੇਹਿਆਂ ਦੇ ਆਉਣ ਦੀ ਸੰਭਾਵਨਾ ਨੂੰ ਘਟਾਉਣ ਲਈ ਡਿਲੀਵਰੀ ਦੀਆਂ ਮੁੜ ਕੋਸ਼ਿਸ਼ਾਂ ਅਤੇ ਡਿਲੀਵਰੀ ਦੇ ਵਿਚਕਾਰ ਦੇਰੀ ਦੀ ਸੰਖਿਆ ਨੂੰ ਅਨੁਕੂਲ ਕਰਨ ਦੀ ਲੋੜ ਹੈ (ਅਨੁਕੂਲ ਮਾਪਦੰਡਾਂ ਦੀ ਗਣਨਾ ਕਰਨਾ ਲਗਭਗ ਅਸੰਭਵ ਹੈ, ਪਰ ਤੁਸੀਂ ਅਨੁਭਵੀ ਤੌਰ 'ਤੇ ਕੰਮ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਕਾਰਵਾਈ ਦੌਰਾਨ ਉਹਨਾਂ ਨੂੰ ਅਨੁਕੂਲ ਕਰ ਸਕਦੇ ਹੋ। );
• DLQ ਸਟੋਰ ਦੀ ਨਿਰੰਤਰ ਨਿਗਰਾਨੀ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀ ਨੂੰ ਸਿਸਟਮ ਪ੍ਰਬੰਧਕਾਂ ਨੂੰ ਸੁਚੇਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਜੋ ਜਦੋਂ ਅਣਡਿਲੀਵਰ ਕੀਤੇ ਸੰਦੇਸ਼ ਆਉਂਦੇ ਹਨ, ਤਾਂ ਉਹ ਜਿੰਨੀ ਜਲਦੀ ਹੋ ਸਕੇ ਜਵਾਬ ਦੇ ਸਕਣ। ਇਹ ਇੱਕ ਅਸਫਲਤਾ ਜਾਂ ਵਪਾਰਕ ਤਰਕ ਗਲਤੀ ਦੇ "ਪ੍ਰਭਾਵਿਤ ਖੇਤਰ" ਨੂੰ ਘਟਾ ਦੇਵੇਗਾ;
• ਏਕੀਕਰਣ ਬੱਸ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੀ ਅਸਥਾਈ ਗੈਰਹਾਜ਼ਰੀ ਲਈ ਅਸੰਵੇਦਨਸ਼ੀਲ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ: ਕਿਸੇ ਵਿਸ਼ੇ ਲਈ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਟਿਕਾਊ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਡੋਮੇਨ ਨਾਮ ਵਿਲੱਖਣ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਜੋ ਜਦੋਂ ਐਪਲੀਕੇਸ਼ਨ ਗੈਰਹਾਜ਼ਰ ਹੋਵੇ, ਕੋਈ ਹੋਰ ਇਸ ਦੇ ਸੁਨੇਹਿਆਂ 'ਤੇ ਕਾਰਵਾਈ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਾ ਕਰੇ। ਕਤਾਰ

ਕਾਰੋਬਾਰੀ ਤਰਕ ਦੀ ਥਰਿੱਡ ਸੁਰੱਖਿਆ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣਾ

ਇੱਕ ਕਾਰੋਬਾਰੀ ਪ੍ਰਕਿਰਿਆ ਦੀ ਇੱਕੋ ਜਿਹੀ ਉਦਾਹਰਣ ਇੱਕ ਵਾਰ ਵਿੱਚ ਕਈ ਸੁਨੇਹੇ ਅਤੇ ਇਵੈਂਟਸ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੀ ਹੈ, ਜਿਸਦੀ ਪ੍ਰੋਸੈਸਿੰਗ ਸਮਾਨਾਂਤਰ ਵਿੱਚ ਸ਼ੁਰੂ ਹੋਵੇਗੀ। ਉਸੇ ਸਮੇਂ, ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਡਿਵੈਲਪਰ ਲਈ, ਸਭ ਕੁਝ ਸਧਾਰਨ ਅਤੇ ਥਰਿੱਡ-ਸੁਰੱਖਿਅਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਕਿਸੇ ਪ੍ਰਕਿਰਿਆ ਦਾ ਵਪਾਰਕ ਤਰਕ ਹਰੇਕ ਬਾਹਰੀ ਘਟਨਾ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਦਾ ਹੈ ਜੋ ਉਸ ਕਾਰੋਬਾਰੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਵਿਅਕਤੀਗਤ ਤੌਰ 'ਤੇ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ। ਅਜਿਹੀਆਂ ਘਟਨਾਵਾਂ ਹੋ ਸਕਦੀਆਂ ਹਨ:

• ਕਾਰੋਬਾਰੀ ਪ੍ਰਕਿਰਿਆ ਦੀ ਸ਼ੁਰੂਆਤ ਕਰਨਾ;
• ਵਪਾਰਕ ਪ੍ਰਕਿਰਿਆ ਦੇ ਅੰਦਰ ਗਤੀਵਿਧੀ ਨਾਲ ਸਬੰਧਤ ਉਪਭੋਗਤਾ ਕਾਰਵਾਈ;
• ਇੱਕ ਸੁਨੇਹੇ ਜਾਂ ਸਿਗਨਲ ਦੀ ਰਸੀਦ ਜਿਸ ਲਈ ਇੱਕ ਵਪਾਰਕ ਪ੍ਰਕਿਰਿਆ ਦੀ ਉਦਾਹਰਣ ਲਈ ਗਾਹਕੀ ਕੀਤੀ ਗਈ ਹੈ;
• ਇੱਕ ਕਾਰੋਬਾਰੀ ਪ੍ਰਕਿਰਿਆ ਉਦਾਹਰਨ ਦੁਆਰਾ ਸੈੱਟ ਕੀਤੇ ਟਾਈਮਰ ਨੂੰ ਚਾਲੂ ਕਰਨਾ;
• API ਦੁਆਰਾ ਕਾਰਵਾਈ ਨੂੰ ਕੰਟਰੋਲ ਕਰੋ (ਉਦਾਹਰਨ ਲਈ, ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਰੁਕਾਵਟ)।

ਹਰੇਕ ਅਜਿਹੀ ਘਟਨਾ ਕਾਰੋਬਾਰੀ ਪ੍ਰਕਿਰਿਆ ਦੀ ਸਥਿਤੀ ਨੂੰ ਬਦਲ ਸਕਦੀ ਹੈ: ਕੁਝ ਗਤੀਵਿਧੀਆਂ ਖਤਮ ਹੋ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਹੋਰ ਸ਼ੁਰੂ ਹੋ ਸਕਦੀਆਂ ਹਨ, ਅਤੇ ਨਿਰੰਤਰ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੇ ਮੁੱਲ ਬਦਲ ਸਕਦੇ ਹਨ। ਕਿਸੇ ਵੀ ਗਤੀਵਿਧੀ ਨੂੰ ਬੰਦ ਕਰਨ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਹੇਠ ਲਿਖੀਆਂ ਗਤੀਵਿਧੀਆਂ ਵਿੱਚੋਂ ਇੱਕ ਜਾਂ ਵੱਧ ਸਰਗਰਮੀ ਹੋ ਸਕਦੀ ਹੈ। ਉਹ, ਬਦਲੇ ਵਿੱਚ, ਹੋਰ ਇਵੈਂਟਾਂ ਦੀ ਉਡੀਕ ਕਰਨਾ ਬੰਦ ਕਰ ਸਕਦੇ ਹਨ ਜਾਂ, ਜੇਕਰ ਉਹਨਾਂ ਨੂੰ ਕਿਸੇ ਵਾਧੂ ਡੇਟਾ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ, ਤਾਂ ਉਹ ਉਸੇ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਵਿੱਚ ਪੂਰਾ ਕਰ ਸਕਦੇ ਹਨ। ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਨੂੰ ਬੰਦ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਕਾਰੋਬਾਰੀ ਪ੍ਰਕਿਰਿਆ ਦੀ ਨਵੀਂ ਸਥਿਤੀ ਨੂੰ ਡੇਟਾਬੇਸ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜਿੱਥੇ ਇਹ ਅਗਲੀ ਬਾਹਰੀ ਘਟਨਾ ਹੋਣ ਦੀ ਉਡੀਕ ਕਰੇਗਾ।

ਜੇਕਰ ਤੁਸੀਂ ਅੱਪਡੇਟ ਲਈ ਚੁਣੋ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ ਤਾਂ ਇੱਕ ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਵਿੱਚ ਸਟੋਰ ਕੀਤਾ ਨਿਰੰਤਰ ਕਾਰੋਬਾਰੀ ਪ੍ਰਕਿਰਿਆ ਡੇਟਾ ਪ੍ਰੋਸੈਸਿੰਗ ਨੂੰ ਸਮਕਾਲੀ ਕਰਨ ਲਈ ਇੱਕ ਬਹੁਤ ਹੀ ਸੁਵਿਧਾਜਨਕ ਬਿੰਦੂ ਹੈ। ਜੇਕਰ ਇੱਕ ਲੈਣ-ਦੇਣ ਇਸ ਨੂੰ ਬਦਲਣ ਲਈ ਅਧਾਰ ਤੋਂ ਵਪਾਰਕ ਪ੍ਰਕਿਰਿਆ ਦੀ ਸਥਿਤੀ ਪ੍ਰਾਪਤ ਕਰਨ ਵਿੱਚ ਕਾਮਯਾਬ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਸਮਾਨਾਂਤਰ ਵਿੱਚ ਕੋਈ ਹੋਰ ਲੈਣ-ਦੇਣ ਇੱਕ ਹੋਰ ਤਬਦੀਲੀ ਲਈ ਉਹੀ ਸਥਿਤੀ ਪ੍ਰਾਪਤ ਕਰਨ ਦੇ ਯੋਗ ਨਹੀਂ ਹੋਵੇਗਾ, ਅਤੇ ਪਹਿਲੇ ਲੈਣ-ਦੇਣ ਦੇ ਪੂਰਾ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਦੂਜਾ ਪਹਿਲਾਂ ਤੋਂ ਬਦਲੀ ਹੋਈ ਸਥਿਤੀ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਗਾਰੰਟੀ ਦਿੱਤੀ ਗਈ ਹੈ।

DBMS ਸਾਈਡ 'ਤੇ ਨਿਰਾਸ਼ਾਵਾਦੀ ਤਾਲੇ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਅਸੀਂ ਸਾਰੀਆਂ ਜ਼ਰੂਰੀ ਲੋੜਾਂ ਪੂਰੀਆਂ ਕਰਦੇ ਹਾਂ ACID, ਅਤੇ ਚੱਲ ਰਹੇ ਉਦਾਹਰਨਾਂ ਦੀ ਗਿਣਤੀ ਨੂੰ ਵਧਾ ਕੇ ਬਿਜ਼ਨਸ ਤਰਕ ਨਾਲ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਸਕੇਲ ਕਰਨ ਦੀ ਯੋਗਤਾ ਨੂੰ ਵੀ ਬਰਕਰਾਰ ਰੱਖੋ।

ਹਾਲਾਂਕਿ, ਨਿਰਾਸ਼ਾਵਾਦੀ ਲਾਕ ਸਾਨੂੰ ਡੈੱਡਲਾਕ ਦੀ ਧਮਕੀ ਦਿੰਦੇ ਹਨ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਵਪਾਰਕ ਤਰਕ ਵਿੱਚ ਕੁਝ ਗੰਭੀਰ ਮਾਮਲਿਆਂ ਵਿੱਚ ਡੈੱਡਲਾਕ ਹੋਣ ਦੀ ਸਥਿਤੀ ਵਿੱਚ ਅਪਡੇਟ ਲਈ ਚੁਣੋ ਅਜੇ ਵੀ ਕੁਝ ਉਚਿਤ ਸਮਾਂ ਸਮਾਪਤੀ ਤੱਕ ਸੀਮਿਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਇੱਕ ਹੋਰ ਸਮੱਸਿਆ ਇੱਕ ਕਾਰੋਬਾਰੀ ਪ੍ਰਕਿਰਿਆ ਦੀ ਸ਼ੁਰੂਆਤ ਦਾ ਸਮਕਾਲੀਕਰਨ ਹੈ. ਜਦੋਂ ਕਿ ਵਪਾਰਕ ਪ੍ਰਕਿਰਿਆ ਦੀ ਕੋਈ ਉਦਾਹਰਣ ਨਹੀਂ ਹੈ, ਡੇਟਾਬੇਸ ਵਿੱਚ ਕੋਈ ਰਾਜ ਨਹੀਂ ਹੈ, ਇਸਲਈ ਵਰਣਿਤ ਢੰਗ ਕੰਮ ਨਹੀਂ ਕਰੇਗਾ। ਜੇਕਰ ਤੁਹਾਨੂੰ ਕਿਸੇ ਖਾਸ ਦਾਇਰੇ ਵਿੱਚ ਕਿਸੇ ਕਾਰੋਬਾਰੀ ਪ੍ਰਕਿਰਿਆ ਦੇ ਉਦਾਹਰਨ ਦੀ ਵਿਲੱਖਣਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਪ੍ਰਕਿਰਿਆ ਕਲਾਸ ਅਤੇ ਸੰਬੰਧਿਤ ਦਾਇਰੇ ਨਾਲ ਸੰਬੰਧਿਤ ਕਿਸੇ ਕਿਸਮ ਦੀ ਸਮਕਾਲੀ ਵਸਤੂ ਦੀ ਲੋੜ ਹੋਵੇਗੀ। ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ, ਅਸੀਂ ਇੱਕ ਵੱਖਰੀ ਲਾਕਿੰਗ ਵਿਧੀ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ ਜੋ ਸਾਨੂੰ ਇੱਕ ਬਾਹਰੀ ਸੇਵਾ ਦੁਆਰਾ URI ਫਾਰਮੈਟ ਵਿੱਚ ਇੱਕ ਕੁੰਜੀ ਦੁਆਰਾ ਨਿਰਧਾਰਿਤ ਇੱਕ ਮਨਮਾਨੇ ਸਰੋਤ 'ਤੇ ਇੱਕ ਲਾਕ ਲੈਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ।

ਸਾਡੀਆਂ ਉਦਾਹਰਣਾਂ ਵਿੱਚ, InitialPlayer ਕਾਰੋਬਾਰੀ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਇੱਕ ਘੋਸ਼ਣਾ ਸ਼ਾਮਲ ਹੈ

uniqueConstraint = UniqueConstraints.singleton

ਇਸ ਲਈ, ਲਾਗ ਵਿੱਚ ਸੰਬੰਧਿਤ ਕੁੰਜੀ ਦੇ ਲੌਕ ਨੂੰ ਲੈਣ ਅਤੇ ਜਾਰੀ ਕਰਨ ਬਾਰੇ ਸੁਨੇਹੇ ਸ਼ਾਮਲ ਹਨ। ਹੋਰ ਕਾਰੋਬਾਰੀ ਪ੍ਰਕਿਰਿਆਵਾਂ ਲਈ ਅਜਿਹੇ ਕੋਈ ਸੰਦੇਸ਼ ਨਹੀਂ ਹਨ: ਵਿਲੱਖਣ ਕੰਸਟ੍ਰੈਂਟ ਸੈੱਟ ਨਹੀਂ ਹੈ।

ਨਿਰੰਤਰ ਸਥਿਤੀ ਦੇ ਨਾਲ ਵਪਾਰਕ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ

ਕਦੇ-ਕਦਾਈਂ ਲਗਾਤਾਰ ਸਥਿਤੀ ਦਾ ਹੋਣਾ ਨਾ ਸਿਰਫ਼ ਮਦਦ ਕਰਦਾ ਹੈ, ਸਗੋਂ ਅਸਲ ਵਿੱਚ ਵਿਕਾਸ ਵਿੱਚ ਰੁਕਾਵਟ ਵੀ ਬਣਦਾ ਹੈ।
ਸਮੱਸਿਆਵਾਂ ਉਦੋਂ ਸ਼ੁਰੂ ਹੁੰਦੀਆਂ ਹਨ ਜਦੋਂ ਵਪਾਰਕ ਤਰਕ ਅਤੇ/ਜਾਂ ਕਾਰੋਬਾਰੀ ਪ੍ਰਕਿਰਿਆ ਮਾਡਲ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਹਰ ਅਜਿਹੀ ਤਬਦੀਲੀ ਵਪਾਰਕ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੀ ਪੁਰਾਣੀ ਸਥਿਤੀ ਦੇ ਅਨੁਕੂਲ ਨਹੀਂ ਹੈ। ਜੇਕਰ ਡੇਟਾਬੇਸ ਵਿੱਚ ਬਹੁਤ ਸਾਰੀਆਂ ਲਾਈਵ ਉਦਾਹਰਨਾਂ ਹਨ, ਤਾਂ ਅਸੰਗਤ ਤਬਦੀਲੀਆਂ ਕਰਨ ਨਾਲ ਬਹੁਤ ਮੁਸ਼ਕਲ ਹੋ ਸਕਦੀ ਹੈ, ਜਿਸਦਾ ਸਾਨੂੰ ਅਕਸਰ jBPM ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ।

ਤਬਦੀਲੀਆਂ ਦੀ ਡੂੰਘਾਈ 'ਤੇ ਨਿਰਭਰ ਕਰਦਿਆਂ, ਤੁਸੀਂ ਦੋ ਤਰੀਕਿਆਂ ਨਾਲ ਕੰਮ ਕਰ ਸਕਦੇ ਹੋ:

1. ਇੱਕ ਨਵੀਂ ਕਾਰੋਬਾਰੀ ਪ੍ਰਕਿਰਿਆ ਦੀ ਕਿਸਮ ਬਣਾਓ ਤਾਂ ਜੋ ਪੁਰਾਣੇ ਵਿੱਚ ਅਸੰਗਤ ਤਬਦੀਲੀਆਂ ਨਾ ਕੀਤੀਆਂ ਜਾ ਸਕਣ, ਅਤੇ ਨਵੀਆਂ ਉਦਾਹਰਣਾਂ ਨੂੰ ਲਾਂਚ ਕਰਨ ਵੇਲੇ ਪੁਰਾਣੀ ਦੀ ਬਜਾਏ ਇਸਦੀ ਵਰਤੋਂ ਕਰੋ। ਪੁਰਾਣੀਆਂ ਕਾਪੀਆਂ "ਪਹਿਲਾਂ ਵਾਂਗ" ਕੰਮ ਕਰਦੀਆਂ ਰਹਿਣਗੀਆਂ;
2. ਕਾਰੋਬਾਰੀ ਤਰਕ ਨੂੰ ਅੱਪਡੇਟ ਕਰਦੇ ਸਮੇਂ ਵਪਾਰਕ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੀ ਨਿਰੰਤਰ ਸਥਿਤੀ ਨੂੰ ਮਾਈਗਰੇਟ ਕਰੋ।

ਪਹਿਲਾ ਤਰੀਕਾ ਸੌਖਾ ਹੈ, ਪਰ ਇਸ ਦੀਆਂ ਸੀਮਾਵਾਂ ਅਤੇ ਨੁਕਸਾਨ ਹਨ, ਉਦਾਹਰਨ ਲਈ:

• ਬਹੁਤ ਸਾਰੇ ਕਾਰੋਬਾਰੀ ਪ੍ਰਕਿਰਿਆ ਦੇ ਮਾਡਲਾਂ ਵਿੱਚ ਵਪਾਰਕ ਤਰਕ ਦੀ ਨਕਲ, ਵਪਾਰਕ ਤਰਕ ਦੀ ਮਾਤਰਾ ਨੂੰ ਵਧਾਉਣਾ;
• ਅਕਸਰ ਨਵੇਂ ਵਪਾਰਕ ਤਰਕ ਲਈ ਇੱਕ ਤੁਰੰਤ ਤਬਦੀਲੀ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ (ਏਕੀਕਰਣ ਕਾਰਜਾਂ ਦੇ ਰੂਪ ਵਿੱਚ - ਲਗਭਗ ਹਮੇਸ਼ਾਂ);
• ਡਿਵੈਲਪਰ ਨੂੰ ਨਹੀਂ ਪਤਾ ਕਿ ਪੁਰਾਣੇ ਮਾਡਲਾਂ ਨੂੰ ਕਿਸ ਬਿੰਦੂ 'ਤੇ ਮਿਟਾਇਆ ਜਾ ਸਕਦਾ ਹੈ।

ਅਭਿਆਸ ਵਿੱਚ ਅਸੀਂ ਦੋਵੇਂ ਪਹੁੰਚਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ, ਪਰ ਆਪਣੀ ਜ਼ਿੰਦਗੀ ਨੂੰ ਆਸਾਨ ਬਣਾਉਣ ਲਈ ਕਈ ਫੈਸਲੇ ਲਏ ਹਨ:

• ਡੇਟਾਬੇਸ ਵਿੱਚ, ਇੱਕ ਕਾਰੋਬਾਰੀ ਪ੍ਰਕਿਰਿਆ ਦੀ ਨਿਰੰਤਰ ਸਥਿਤੀ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਪੜ੍ਹਨਯੋਗ ਅਤੇ ਆਸਾਨੀ ਨਾਲ ਸੰਸਾਧਿਤ ਰੂਪ ਵਿੱਚ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ: ਇੱਕ JSON ਫਾਰਮੈਟ ਸਤਰ ਵਿੱਚ। ਇਹ ਮਾਈਗ੍ਰੇਸ਼ਨ ਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਅੰਦਰ ਅਤੇ ਬਾਹਰੀ ਤੌਰ 'ਤੇ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। ਆਖਰੀ ਉਪਾਅ ਵਜੋਂ, ਤੁਸੀਂ ਇਸਨੂੰ ਹੱਥੀਂ ਠੀਕ ਕਰ ਸਕਦੇ ਹੋ (ਖਾਸ ਕਰਕੇ ਡੀਬੱਗਿੰਗ ਦੌਰਾਨ ਵਿਕਾਸ ਵਿੱਚ ਉਪਯੋਗੀ);
• ਏਕੀਕਰਣ ਕਾਰੋਬਾਰੀ ਤਰਕ ਕਾਰੋਬਾਰੀ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੇ ਨਾਵਾਂ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦਾ ਹੈ, ਤਾਂ ਜੋ ਕਿਸੇ ਵੀ ਸਮੇਂ ਭਾਗ ਲੈਣ ਵਾਲੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਵਿੱਚੋਂ ਇੱਕ ਦੇ ਲਾਗੂਕਰਨ ਨੂੰ ਇੱਕ ਨਵੇਂ ਨਾਮ ਨਾਲ ਬਦਲਿਆ ਜਾ ਸਕੇ (ਉਦਾਹਰਨ ਲਈ, "InitialPlayerV2")। ਬਾਈਡਿੰਗ ਸੁਨੇਹੇ ਅਤੇ ਸਿਗਨਲ ਨਾਮਾਂ ਰਾਹੀਂ ਹੁੰਦੀ ਹੈ;
• ਪ੍ਰਕਿਰਿਆ ਮਾਡਲ ਦਾ ਇੱਕ ਸੰਸਕਰਣ ਨੰਬਰ ਹੁੰਦਾ ਹੈ, ਜਿਸ ਨੂੰ ਅਸੀਂ ਵਧਾਉਂਦੇ ਹਾਂ ਜੇਕਰ ਅਸੀਂ ਇਸ ਮਾਡਲ ਵਿੱਚ ਅਸੰਗਤ ਤਬਦੀਲੀਆਂ ਕਰਦੇ ਹਾਂ, ਅਤੇ ਇਹ ਨੰਬਰ ਪ੍ਰਕਿਰਿਆ ਦੀ ਸਥਿਤੀ ਦੇ ਨਾਲ ਸੁਰੱਖਿਅਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ;
• ਪ੍ਰਕਿਰਿਆ ਦੀ ਨਿਰੰਤਰ ਸਥਿਤੀ ਨੂੰ ਡੇਟਾਬੇਸ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਸੁਵਿਧਾਜਨਕ ਆਬਜੈਕਟ ਮਾਡਲ ਵਿੱਚ ਪੜ੍ਹਿਆ ਜਾਂਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਮਾਈਗ੍ਰੇਸ਼ਨ ਪ੍ਰਕਿਰਿਆ ਕੰਮ ਕਰ ਸਕਦੀ ਹੈ ਜੇਕਰ ਮਾਡਲ ਸੰਸਕਰਣ ਨੰਬਰ ਬਦਲ ਗਿਆ ਹੈ;
• ਮਾਈਗ੍ਰੇਸ਼ਨ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਵਪਾਰਕ ਤਰਕ ਦੇ ਅੱਗੇ ਰੱਖਿਆ ਗਿਆ ਹੈ ਅਤੇ ਡੇਟਾਬੇਸ ਤੋਂ ਇਸਦੀ ਬਹਾਲੀ ਦੇ ਸਮੇਂ ਵਪਾਰਕ ਪ੍ਰਕਿਰਿਆ ਦੇ ਹਰੇਕ ਉਦਾਹਰਣ ਲਈ "ਆਲਸੀ" ਕਿਹਾ ਜਾਂਦਾ ਹੈ;
• ਜੇਕਰ ਤੁਹਾਨੂੰ ਸਾਰੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੀ ਸਥਿਤੀ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਅਤੇ ਸਮਕਾਲੀ ਰੂਪ ਵਿੱਚ ਮਾਈਗਰੇਟ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਵਧੇਰੇ ਕਲਾਸਿਕ ਡਾਟਾਬੇਸ ਮਾਈਗ੍ਰੇਸ਼ਨ ਹੱਲ ਵਰਤੇ ਜਾਂਦੇ ਹਨ, ਪਰ ਤੁਹਾਨੂੰ JSON ਨਾਲ ਕੰਮ ਕਰਨਾ ਪਵੇਗਾ।

ਕੀ ਤੁਹਾਨੂੰ ਕਾਰੋਬਾਰੀ ਪ੍ਰਕਿਰਿਆਵਾਂ ਲਈ ਕਿਸੇ ਹੋਰ ਢਾਂਚੇ ਦੀ ਲੋੜ ਹੈ?

ਲੇਖ ਵਿੱਚ ਵਰਣਿਤ ਹੱਲਾਂ ਨੇ ਸਾਨੂੰ ਆਪਣੇ ਜੀਵਨ ਨੂੰ ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ ਸਰਲ ਬਣਾਉਣ, ਐਪਲੀਕੇਸ਼ਨ ਡਿਵੈਲਪਮੈਂਟ ਪੱਧਰ 'ਤੇ ਹੱਲ ਕੀਤੇ ਗਏ ਮੁੱਦਿਆਂ ਦੀ ਸੀਮਾ ਦਾ ਵਿਸਥਾਰ ਕਰਨ, ਅਤੇ ਵਪਾਰਕ ਤਰਕ ਨੂੰ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਵਿੱਚ ਵੱਖ ਕਰਨ ਦੇ ਵਿਚਾਰ ਨੂੰ ਹੋਰ ਆਕਰਸ਼ਕ ਬਣਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੱਤੀ ਹੈ। ਇਸ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ, ਬਹੁਤ ਸਾਰਾ ਕੰਮ ਕੀਤਾ ਗਿਆ ਸੀ, ਕਾਰੋਬਾਰੀ ਪ੍ਰਕਿਰਿਆਵਾਂ ਲਈ ਇੱਕ ਬਹੁਤ ਹੀ "ਹਲਕਾ" ਢਾਂਚਾ ਬਣਾਇਆ ਗਿਆ ਸੀ, ਅਤੇ ਨਾਲ ਹੀ ਐਪਲੀਕੇਸ਼ਨ ਸਮੱਸਿਆਵਾਂ ਦੀ ਇੱਕ ਵਿਸ਼ਾਲ ਸ਼੍ਰੇਣੀ ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਪਛਾਣੀਆਂ ਗਈਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਸੇਵਾ ਦੇ ਹਿੱਸੇ. ਅਸੀਂ ਇਹਨਾਂ ਨਤੀਜਿਆਂ ਨੂੰ ਸਾਂਝਾ ਕਰਨ ਅਤੇ ਇੱਕ ਮੁਫਤ ਲਾਇਸੈਂਸ ਦੇ ਤਹਿਤ ਸਾਂਝੇ ਹਿੱਸਿਆਂ ਦੇ ਵਿਕਾਸ ਨੂੰ ਖੁੱਲ੍ਹੀ ਪਹੁੰਚ ਬਣਾਉਣ ਦੀ ਇੱਛਾ ਰੱਖਦੇ ਹਾਂ। ਇਹ ਕੁਝ ਜਤਨ ਅਤੇ ਵਾਰ ਦੀ ਲੋੜ ਹੋਵੇਗੀ. ਅਜਿਹੇ ਹੱਲਾਂ ਦੀ ਮੰਗ ਨੂੰ ਸਮਝਣਾ ਸਾਡੇ ਲਈ ਇੱਕ ਵਾਧੂ ਪ੍ਰੇਰਣਾ ਹੋ ਸਕਦਾ ਹੈ। ਪ੍ਰਸਤਾਵਿਤ ਲੇਖ ਵਿੱਚ, ਆਪਣੇ ਆਪ ਵਿੱਚ ਫਰੇਮਵਰਕ ਦੀਆਂ ਸਮਰੱਥਾਵਾਂ ਵੱਲ ਬਹੁਤ ਘੱਟ ਧਿਆਨ ਦਿੱਤਾ ਗਿਆ ਹੈ, ਪਰ ਉਹਨਾਂ ਵਿੱਚੋਂ ਕੁਝ ਪੇਸ਼ ਕੀਤੀਆਂ ਉਦਾਹਰਣਾਂ ਤੋਂ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ। ਜੇਕਰ ਅਸੀਂ ਆਪਣਾ ਢਾਂਚਾ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਇੱਕ ਵੱਖਰਾ ਲੇਖ ਇਸ ਨੂੰ ਸਮਰਪਿਤ ਕੀਤਾ ਜਾਵੇਗਾ। ਇਸ ਦੌਰਾਨ, ਜੇਕਰ ਤੁਸੀਂ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇ ਕੇ ਥੋੜਾ ਜਿਹਾ ਫੀਡਬੈਕ ਛੱਡਦੇ ਹੋ ਤਾਂ ਅਸੀਂ ਧੰਨਵਾਦੀ ਹੋਵਾਂਗੇ:

ਸਿਰਫ਼ ਰਜਿਸਟਰਡ ਉਪਭੋਗਤਾ ਹੀ ਸਰਵੇਖਣ ਵਿੱਚ ਹਿੱਸਾ ਲੈ ਸਕਦੇ ਹਨ। ਸਾਈਨ - ਇਨ, ਤੁਹਾਡਾ ਸੁਆਗਤ ਹੈ.

ਕੀ ਤੁਹਾਨੂੰ ਕਾਰੋਬਾਰੀ ਪ੍ਰਕਿਰਿਆਵਾਂ ਲਈ ਕਿਸੇ ਹੋਰ ਢਾਂਚੇ ਦੀ ਲੋੜ ਹੈ?

• 18,8%ਹਾਂ, ਮੈਂ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਅਜਿਹਾ ਕੁਝ ਲੱਭ ਰਿਹਾ ਹਾਂ

• 12,5%ਮੈਂ ਤੁਹਾਡੇ ਲਾਗੂ ਕਰਨ ਬਾਰੇ ਹੋਰ ਜਾਣਨ ਵਿੱਚ ਦਿਲਚਸਪੀ ਰੱਖਦਾ ਹਾਂ, ਇਹ ਲਾਭਦਾਇਕ ਹੋ ਸਕਦਾ ਹੈ2

• 6,2%ਅਸੀਂ ਮੌਜੂਦਾ ਫਰੇਮਵਰਕ ਵਿੱਚੋਂ ਇੱਕ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ, ਪਰ 1 ਨੂੰ ਬਦਲਣ ਬਾਰੇ ਸੋਚ ਰਹੇ ਹਾਂ

• 18,8%ਅਸੀਂ ਮੌਜੂਦਾ ਫਰੇਮਵਰਕ ਵਿੱਚੋਂ ਇੱਕ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ, ਸਭ ਕੁਝ ਠੀਕ ਹੈ3

• 18,8%ਅਸੀਂ ਬਿਨਾਂ ਕਿਸੇ ਫਰੇਮਵਰਕ 3 ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਦੇ ਹਾਂ

• 25,0%ਆਪਣਾ 4 ਲਿਖੋ

16 ਉਪਭੋਗਤਾਵਾਂ ਨੇ ਵੋਟ ਕੀਤਾ। 7 ਉਪਭੋਗਤਾ ਬਚੇ ਹੋਏ ਹਨ।

ਸਰੋਤ: www.habr.com