در ادامه مباحث مربوط به میکروسرویس و soa بارها به سیاست و اصول سازمانی اشاره کردیم (در کتاب طراحی میکروسرویس با جنگو یک بخش مهم از کتاب که نظر خود من رو بشدت جلب کرده بود بارها و بارها به این موضوع اشاره کرده بود) و گفتیم بخش مهمی از طراحی به سبک این معماری‌های نوین بشدت وابسته به این مسئله می‌باشد

در این پست پست‌های با تگ soa# راجب این موضوع حرف میزنیم و مثالهایی برای اون خواهیم گفت تا دیدگاهمون نسبت بهش بازتر بشه و شناخت دقیقتری ازش داشته باشیم

مسئله بر سر حاکمیت soa در سازمان هست
حاکمیت SOA به مجموعه ای از اصول و روش‌ها میگیم که این اطمینان رو حاصل کنه برامون که معماری سرویس گرا (SOA) به طور موثر و کارآمد و مطابق با نیازهای سازمان اداره و بکار گرفته میشود، که شامل تعیین فرآیندها،روابط،کنترل مکانیسم‌ها و اعمال سیاست‌ها میشود

مبحث سیاست‌ها توسط ذینفعان سازمان مشخص میشه و بر کل امور سازمانی اجبار بر اجرای اون خواهد شد و توسعه دهندگان اجازه خروج ازین چهارچوب رو ندارن این سیاست‌ها برای همگان چه توسعه دهندگان و چه مدیران و ادمین‌ها و تحلیل گران کاملا قابل فهم و درک هستش

علاوه بر قابلیت فهم و شفافیت یکی از مسائل قابل اهمیت در دسترس بودن سندنگاره این سیاست‌ها برای همگان هستش، بسته به بزرگی سازمان شما میتواند یک داکیومنت شیر شده روی سیستم‌ها باشد یا یک صفحه وب درون سازمانی و یا یک صفحه ویکی‌پدیا مخصوص شما و در صورت لزوم هم میتوانید از یک ابزار تجاری استفاده کنید

سیاست‌های سازمانی برای حاکمیت soa به چند بخش مختلف تقسیم میشود که برای هر کدام چند مثال جهت درک بیشتر خواهیم گفت، سیاست‌ها رو میتوان در دو بخش پایه و دسته بندی شده بررسی کنیم


1-سیاست‌های پایه

1-1 سیاست پایه زمان طراحی (design-time policies):

۱-سرویس‌های بدون تکرار:
در یک بخش، بسیاری از عملکردها بین خدمات تکراری است.  رسمی کردن این مورد در یک خط‌مشی و بررسی این خط‌مشی قبل از شروع کار بر روی یک سرویس جدید، می‌تواند باعث صرفه‌جویی در کارهای تکراری شود

۲-استانداردسازی فناوری:
این سیاست چیزی شبیه به این است که: "همه خدمات ارائه شده به عموم مردم، به عنوان مثال، از طریق اینترنت، باید از الگوی REST پیروی کنند.خدماتی که منحصراً برای اهداف B2B ارائه می شوند باید از معماری WS-* استفاده کنند." این یک سیاست اساسی است، اما سیاستی است که مانع از آن می‌شود که طراحان پروژه‌ها آنچه را که فکر می‌کنند بهترین است بدون نگاه کردن به شمای بزرگ‌تر انجام دهند.


۳-تایید محتوای پیام:
این سیاست می تواند به شما در ایجاد یک چشم اندازی یکسان از سرویس کمک کند.  وقتی عمیق‌تر به این خط‌مشی نگاه می‌کنیم، احتمالاً باید نوع اعتبارسنجی مورد نیاز را نیز تعریف کنیم، به عنوان مثال، این می تواند به این معنی باشد که تمام قالب های پیام این سرویس باید XML همراه با یک شماتیک باشد.  یا اینکه تمام پیام های JSON ارسال شده می توانند با استفاده از شماتیک JSON تأیید شوند.

1-2 سیاست‌های پایه زمان اجرا (runtime policies):

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

۲-صداکردن (تماس) سرویس‌ها باید در یک کانال امن صورت گیرد:
یکی دیگر از سیاست‌های اساسی برای شروع میتواند این مورد باشد، اگر قرار است ارتباط سرویس‌ها در یک بستر امن صورت گیرد این میتواند یک مورد مناسب باشد، برای مثال جهت اجرای این سیاست ارتباطات میتوانند توسط Apache اجرا کنید

۳-سرویس باید خود توصیفگر باشد:
هنگام استقرار یک سرویس باید خود توصیفگر باشد، شما نباید برای تعامل با یک سرویس و نحوه ارتباط با آن نیاز به یک کتاب بزرگ راهنمایی جهت خوندن اون باشید

ما سیاست‌های پایه خودمون رو مشخص کردیم حال به سراغ سیاست‌های دسته‌بندی میریم و اونهارو بررسی میکنیم


#microservoce
#soa

@code_crafters