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

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

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

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

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

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

 

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

یک راهنمای ساده برای اینکه بدانید کدام رویکرد برای سناریوی شما مناسب تر می باشد در زیر آورده شده است.

استفاده از Orchestration :

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

استفاده از Choreography :

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

منبع: www.bptrends.com

ترجمه: سهیل نیک فرجام


 

درباره رایورز

شرکت مهندسی نرم‌افزار رایورز در اوایل سال 1368 توسط جمعی‌از فعالین حرفه نرم‌افزار تأسیس گردید...

بیشتر بدانید

ارتباط با ما

  • تهران، خيابان ولی عصر، نرسيده به توانير، خيابان احتشام، شماره 5
  • 89326000

  • BPMS@rayvarz.com

خبرنامه پایگاه دانش BPM