Orchestration در مقایسه با Choreography

 

پیشنهاد میشود که پیش از مطالعه این مقاله، مروری بر مفهوم معماری سرویس گرا (SOA) داشته باشید.

در این مطلب می خواهیم به دو موضوع Orchestration و Choreography بپردازیم. هدف، بیان برتری یکی نسبت به دیگری نیست، بلکه بحث بر روی تفاوت بین BPEL و WS-CDL است و درک این مطلب که چرا اینقدر در این رابطه استاندارد وجود دارد؟ (قطعاً سؤال بسیار خوب و قابل تأملی است)

به طور معمول گفته می‌شود که BPELجهت سازماندهی یک فرآیند یا ترکیب چند سرویس به کار می رود و این در حالی است که WS-CDL برای هماهنگی ارتباط میان فرآیندهاست. با وجود اینکه این تعاریف درست است، لیکن -به طور شفاف- تفاوت این دو را بیان نمی‌کند. برای بیان بهتر این تفاوت، خلاصه ای از مقاله آقای John Tibbetts به نام ” Orchestration در برابر Choreography ” از کنسرسیوم معماری سازمانی Cutter در ادامه آورده شده است:

پیش از اینکه بحث را شروع کنیم، می‌بایست در رابطه با چند مسئله به توافق برسیم:

۱- سرویس (Service)، رویکرد مناسبی برای اجرای عملیات فناوری اطلاعات است.
۲- معماری سرویس گرا (SOA) برای پیاده‌سازی راهکارهای مبتنی بر سرویس در سازمان است.
۳- BPM رویکرد مناسب و چابکی برای پیاده سازی فرآیندهای کسب‌وکار است که فرآیندهای قابل مدل‌سازی سازمان را مدیریت می‌کند.
۴- BPM و SOA از یک سری قابلیت‌ها و فرآیندهای مرتبط با یکدیگر پشتیبانی می‌نمایند.

چنانچه هر یک از موارد بالا را قبول ندارید و یا برای شما گنگ است، پیشنهاد می‌کنیم که مطالب موجود در پایگاه دانش BPM رایورز را مطالعه نمایید.

یک رویکرد مهندسی اینگونه است که مسائل بزرگ را به مسائل کوچک‌تر و قابل مدیریت تبدیل نماید. این مسئله در رابطه با سرویس‌ها هم رخ می‌دهد. لیکن سؤالی که مطرح می‌شود این است که چگونه سرویس‌های کوچک را با یکدیگر تلفیق کنیم تا سرویسی بزرگ‌تر پدید آید؟

بر این مبنا، دو رویکرد اصلی Orchestration و Choreography وجود دارد.

Orchestration المان اصلی و مرکزی است که تمامی اجزاء یک فرآیند را کنترل می‌نماید؛ مانند یک گروه موسیقی که یک رهبر، یکپارچگی اعضای گروه را مدیریت می‌کند.

Choreography به‌گونه ای است که هر المان به صورت خود مختار وظایف خود را کنترل می‌نماید؛ مانند یک گروه رقص که هر فرد نقش خود را در تیم می‌داند و قدم‌هایش را با صدای موسیقی هماهنگ می‌سازد. ممکن است Choreography نیز از یک مرکز کنترل استفاده کند، لیکن -در کل- سازمان به نسبت موقعیت می‌تواند از هر دو رویکرد استفاده کند.

Orchestration

Orchestration متداول‌ترین رویکرد جهت استفاده در فرآیندهای کسب‌وکار و نیز ترکیب سرویس است. در رویکرد Orchestration سلسله مراتبی از مراحل فرآیند، شرایط و قوانین تعریف می‌نمایید. سپس، با کنترل کننده مرکزی فرآیند را اجرایی می‌سازید. در معماری سرویس‌گرا، این مراحل توسط اجرای سرویس به صورت ترتیبی مشخص صورت می‌گیرد. ترتیب‌های اجرا می‌توانند با تکنیک‌های متفاوتی انجام شوند. اغلب برای ترکیب ساده سرویس، از Orchestration درون کد، استفاده می‌نمایند؛ مانند Java و C#. لیکن در مدل‌های پیچیده‌تر Orchestration، معمولاً از ابزاری استفاده می‌کنید تا مدل بصری از ترتیب سرویس ایجاد نموده و سپس کدی -که این ترتیب را اجرا می‌کند- توسط ابزار تولید می‌شود. در رویکرد BPM این روش بیشتر به کار می‌رود.
امروزه برای تعریف ترتیب های سرویس بصورت بصری از استاندارد BPMN و برای کدی که بتواند این ترتیب را اجرا کند از استاندارد BPEL بهره گرفته می شود. تقریباً تمامی زیرساخت های SOA برای اجرا از زبان BPEL پشتیبانی می کنند و اخیراً بسیاری از محصولات BPM نیز این زبان را پشتیبانی می کنند. از طرفی زبان BPEL نیز با زبان XML توصیف شده و می‌تواند کاملاً بر اساس معماری سرویس‌گرا طراحی گردد. BPEL از زبان WSDL نیز در دو سطح استفاده نماید: ۱-سرویس‌هایی که درون فرآیند باید تعریف شوند ۲-خود فرآیند ها توسط این زبان توصیف می‌شوند.

به طور خلاصه Orchestration :

– بخش مرکزی تعریف می‌نماید تا تمامی جنبه‌های یک فرآیند را کنترل کند.
– تعریف جریان کارها را به صورت گرافیکی پشتیبانی می‌نماید.
– به سادگی می‌تواند به معماری SOA نگاشت شود.
– در ابتدا بسیار ساده تعریف شده، لیکن زمانی که فرآیندها بیشتر و پیچیده‌تر می‌شوند، تعریف آنها دشوار می‌گردد.

تا حدودی، به علت محبوبیت Orchestration پی بردیم، لیکن باید توجه داشت که این رویکرد، همه انواع فرآیندها را پوشش نمی‌دهد.

Choreography :

Choreography رویکردی متفاوت است که برای سناریوهای شامل فرآیندهای پیچیده، سیستم‌های مبتنی بر رخداد و مبتنی بر عامل مناسب است. در رویکرد Choreography قوانینی وضع می‌شوند که رفتار هر بخش از فرآیند را -به صورت جداگانه- مشخص می‌سازد. در این رویکرد، رفتار کلی فرآیند از طریق برقراری ارتباط میان زیر بخش‌های آن حاصل می‌گردد، هر بخش به صورت خودمختار تنها طبق قوانین خود عمل می‎نماید. دو رویکرد اصلی برای پیاده‌سازی وجود دارد: مبتنی بر پیام(Message Component) و مبتنی بر اجزاء کاری (Work Component).

در رویکرد مبتنی بر پیام، تمرکز بر پیام‌هایی است که میان بخش‌های فرآیند جابه‌جا می‌شود. با این رویکرد، پیام‌هایی که به صورت قراردادی میان بخش‌های فرآیند جابه‌جا می‌شوند را با تمام جزئیات می‌توانید تعریف کنید. این مکانیزم با استاندارد (WS-CDL)Web Services Choreography Description Language پشتیبانی شده و بیشتر در برنامه‌های کاربردی بین دو کسب و کار (B۲B) کاربرد دارد. در برنامه های کاربردی B۲B ( که چندین سازمان به یکدیگر متصل می‌گردند) مشخص نمودن نحوه کارکرد یک سیستم در سازمان دیگر کاری دشوار است؛ چرا که نمی‌توان جریان کاری میان سازمان‌ها را به صورت کلی مدل کرد (در بسیاری از موارد، مجوزی مرکزی برای انجام این کار وجود ندارد) این رویکرد بسیار جذاب است؛ چرا که جهت برقراری ارتباط با یک سازمان کافی است تا ساختار پیام‌ها را مشخص نمایید . ( Syntax، Semantics و Behavior).

رویکرد دوم برای پیاده‌سازی، تنظیم اجزاء کاری فرآیند است. در این رویکرد، رفتار هر جزء کاری را تعریف نموده و زمانی که هر نمونه از فرآیند اجرا می‌گردد، هر جزء رفتار مرتبط با آن نمونه فرآیند را پیاده می‌سازد. به عنوان مثال، می‌توانید قوانین ذیل را برای اجزاء کاری فرآیند پیاده‌سازی نمایید: چه کارهایی باید انجام شود تا یک جزء کاری به پایان برسد، چه اشخاصی می‌توانند به سیستم دسترسی داشته باشند و …

به طور خلاصه Choreography :

– رفتار کلی فرآیند، از بخش‌های درون آن نشأت می‌گیرد (رویکرد پایین به بالا) و نیازی به دید یکپارچه –به صورت کلی- از فرآیندها نیست.
– فرآیندهای پیچیده به کارهای کوچک‌تر با دستورالعمل مجزا تقسیم شده و هر بخش، دستورالعمل خود را کنترل می‌کند.
– قابل نگاشت به سیستم‌های مبتنی بر عامل و رخداد است.
– معمولاً راه‌اندازی آنها ساده نیست، لیکن برای تبدیل به فرآیندهای پیچیده‌تر، راحت‌تر هستند.
– می‌توان از فرآیند، شمای گرافیکی تهیه نمود. مثال: مدل جریان عملگرها

مقایسه دو رویکرد

راهنمای ساده‌ای در ادامه تهیه گردیده تا بدانید کدام رویکرد برای سناریوی شما مناسب‌تر خواهد بود.

بکارگیری Orchestration

– زمانی که می‌خواهید محصول آماده تهیه کنید (رویکرد اکثر محصولات امروزی، چنین است)
– برای ترکیب چند سرویس مناسب است
– زمانی که تراکنش‌های اشتباه (یا ناموفق) را بتوان به سادگی به حالت اولیه بازگرداند (در چند حوزه تغییرات اعمال نمی‌گردد)
-برای فرآیندهای به نسبت ثابت، مناسب است
-زمانی که مدل گرافیکی از فرآیند و گردش کار، لازم باشد

بکارگیری Choreography

– زمانی که ابعاد فرآیند به حدی است که شامل تعداد زیادی اجزاء می‌باشد
– زمانی که برخی از فرآیندها به صورت شفاف تعریف نشده باشند (مانند B۲B)
– زمانی که فرآیندها باید به صورت سفارشی شده طراحی گردند
– زمانی که فرآیندها بسیار پویا یا هدف‌یاب هستند

منبع: پایگاه دانش BPM رایورز

 

منبع : ایتنا