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

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

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

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

اول اینکه سرویس (Service)  رویکردی مناسب برای اجرای عملیات فناوری اطلاعات است.

دوم اینکه معماری سرویس‌گرا (SOA) برای پیاده سازی راهکارهای مبتنی بر سرویس در سازمان است.

سوم اینکه BPM‌ یک رویکرد مناسب و چابک برای پیاده‌سازی فرآیندهای کسب و کار است که فرآیندها را مدیریت می‌کند.

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

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

بر این مبنا دو رویکرد اصلی 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   پشتیبانی می‌شود و  بیشتر در برنامه‌های کاربردی بین دو کسب و کار (B2B) کاربرد دارد. در برنامه‌های کاربردی B2B  (که چندن سازمان به‌یکدیگر متصل می‌شوند) مشخص کردن نحوه‌ی کارکرد ‌یک سیستم در سازمان دیگر کاری دشوار است زیرا نمی‌توان جریان کاری بین سازمان ها را بصورت کلی مدل کرد. در بسیاری از موارد‌ی که مجوز مرکزی برای انجام این کار وجود ندارد، این رویکرد بسیار جذاب است چون شما برای برقراری ارتباط با‌ یک سازمان کافی است ساختار پیغام ها را مشخص کنید. (Syntax، Semantics، Behavior)

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

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

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

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

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

استفاده از Orchestration :

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

استفاده از Choreography :

• زمانی که ابعاد فرآیند شما به حدی است که شامل تعداد زیادی اجزاء می‌شود.
• زمانی که بعضی فرآیندها بصورت شفاف تعریف نشده باشند (مانند B2B).
• زمانی که  فرآیندها باید به صورت سفارشی شده طراحی گردند.
• زمانی که فرآیندها بسیار پویا ‌یا هدف‌یاب هستند. 

ترجمه و گردآوری: تیم مدیریت محتوای رایورز