مقالات

آپدیت WSO2 API Manager 4.7 منتشر شد!(موشکافی تمامی تغییرات این بروزرسانی)

Posted by author-avatar
0
wso2-4.7-update

WSO2 API Manager 4.7 یک به‌روزرسانی ساده نیست، یک گسترش جدی در معماری API است

در نگاه اول ممکن است WSO2 API Manager 4.7 فقط یک نسخه جدید از همان محصول قبلی به نظر برسد؛ اما اگر از زاویه معماری و عملیات به آن نگاه کنیم، این نسخه عملاً فقط یک minor upgrade ساده نیست.

نسخه 4.7 بیشتر از آنکه صرفاً چند قابلیت جدید اضافه کرده باشد، مرزهای کنترلی API Manager را گسترده‌تر کرده است.

نکته مهم اینجاست که WSO2 در این نسخه تلاش کرده سرمایه‌گذاری فعلی سازمان‌ها روی API Manager را حفظ کند، اما هم‌زمان آن را به دنیای جدیدتری از Gatewayها، معماری‌های cloud-native، governance برای MCP و سیاست‌گذاری مدرن‌تر متصل کند.

اگر بخواهیم خلاصه بگوییم، WSO2 API Manager 4.7 بیشتر از آنکه فقط درباره «مدیریت API» باشد، درباره «گسترش reach کنترل‌پلین» در اکوسیستم API است.

WSO2 API Manager 4.7 چه چیزی را تغییر داده است؟

در این نسخه، مهم‌ترین اتفاق این است که کنترل‌پلین WSO2 API Manager حالا می‌تواند در کنار Gateway کلاسیک، یک Gateway جدیدتر را هم مدیریت کند؛ Gateway ی که روی Envoy Proxy و معماری Go-based ساخته شده است.

این یعنی محصول از مدل قدیمی‌تر و سنتی‌تر فاصله نگرفته، اما یک مسیر موازی برای سناریوهای مدرن‌تر باز کرده است.

مهم‌ترین محورهای نسخه 4.7 شامل این موارد است:

  • پشتیبانی از API Platform Gateway
  • ارتقای جدی Kubernetes Gateway و Immutable Gateway
  • اضافه شدن MCP Governance
  • پشتیبانی از AsyncAPI v3
  • پشتیبانی از کامپایل با JDK 21
  • بهبودهای مهم در API Key و OAuth

مهم‌ترین تفاوت WSO2 API Manager 4.7 با نسخه‌های قبلی

اگر بخواهیم از دید حرفه‌ای این نسخه را با قبل مقایسه کنیم، تفاوت اصلی فقط در افزودن چند feature نیست؛ تفاوت اصلی در نوع نگاه به Gateway و governance است.

  1. در نسخه‌های قبلی تمرکز بیشتر روی Gateway سنتی بود

تا قبل از این، WSO2 API Manager عمدتاً با همان Gateway شناخته می‌شد که قبلاً با نام Universal Gateway مطرح بود و حالا در نسخه 4.7 با نام Classic Gateway شناخته می‌شود.

این Gateway همچنان پابرجاست، حذف نشده، deprecate نشده و هنوز هم برای workload هایی که mediation سنگین دارند، انتخاب مهمی است.

اما تفاوت نسخه 4.7 این است که برای اولین بار، یک Gateway مدرن‌تر و cloud-native هم به شکل رسمی وارد بازی شده که توسط همان control plane قابل مدیریت است.

  1. نسخه 4.7 یک مدل دوگانه Gateway ایجاد می‌کند

در نسخه‌های قبلی، انتخاب شما عملاً بیشتر حول همان runtime کلاسیک می‌چرخید.

در 4.7، حالا می‌توانید از یک control plane مشترک، هم Classic Gateway و هم API Platform Gateway را مدیریت کنید.

این موضوع از نظر عملیاتی بسیار مهم است، چون سازمان مجبور نیست migration ناگهانی انجام دهد.

می‌تواند:

  • بعضی APIها را روی Gateway کلاسیک نگه دارد
  • بعضی workloadهای جدید را به Gateway مدرن منتقل کند
  • و مهاجرت را تدریجی و کنترل‌شده پیش ببرد

  1. نسخه 4.7 نگاه جدی‌تری به AI و MCP دارد

در نسخه 4.6 قابلیت‌های اولیه MCP معرفی شده بود، اما در 4.7 ماجرا بالغ‌تر شده و MCP Governance به آن اضافه شده است.

یعنی دیگر فقط بحث proxy کردن یا expose کردن ابزارها نیست؛ حالا می‌توان روی آن‌ها rule و governance مرکزی اعمال کرد.

این تفاوت مهمی است، چون نشان می‌دهد WSO2 فقط به «پشتیبانی از MCP» بسنده نکرده و به سمت «کنترل سازمانی MCP» حرکت کرده است.

API Platform Gateway در WSO2 API Manager 4.7 چیست؟

یکی از مهم‌ترین قابلیت‌های نسخه 4.7، پشتیبانی از API Platform Gateway است.

این Gateway جدید:

  • بر پایه Envoy Proxy ساخته شده
  • codebase آن مبتنی بر Go است
  • رویکرد آن policy-first است
  • و برای پروتکل‌های مدرن و بارهای cloud-native طراحی شده است

از نگاه تجربی، این تغییر فقط یک جایگزینی فنی نیست؛ بلکه نشانه‌ای از تغییر پارادایم در لایه اجرای API است.

چرا این Gateway مهم است؟

چون در معماری‌های جدید، مخصوصاً جایی که:

  • ترافیک بالا است
  • latency مهم است
  • APIها باید در Kubernetes یا محیط‌های GitOps-friendly اجرا شوند
  • و پروتکل‌های جدید مثل HTTP/2 و HTTP/3 اهمیت دارند

runtimeهای قدیمی‌تر همیشه بهترین گزینه نیستند.

API Platform Gateway دقیقاً برای این فضا ساخته شده است.

 

قابلیت‌های کلیدی API Platform Gateway

مهم‌ترین ویژگی‌های این Gateway عبارت‌اند از:

  • پشتیبانی از HTTP/2 و HTTP/3
  • موتور policy مبتنی بر Go
  • سازگاری بیشتر با rolloutهای مبتنی بر GitOps
  • طراحی مناسب‌تر برای deploymentهای cloud-native
  • امکان استفاده از policyهای آماده برای authentication، transformation، observability و AI guardrails

 

تفاوت Classic Gateway و API Platform Gateway چیست؟

این سؤال احتمالاً مهم‌ترین سؤال فنی برای هر تیمی است که می‌خواهد نسخه 4.7 را ارزیابی کند.

Classic Gateway

Gateway کلاسیک همان runtime مبتنی بر Synapse است که قبلاً با نام Universal Gateway شناخته می‌شد و حالا فقط نام آن تغییر کرده است.

ویژگی‌های آن:

  • مبتنی بر Java و Synapse
  • مناسب برای mediation-heavy workloads
  • مناسب برای سناریوهای protocol-mixed
  • همچنان fully supported
  • همچنان gateway پیش‌فرض در WSO2 API Manager

API Platform Gateway

در مقابل، Gateway جدید:

  • مبتنی بر Go و Envoy
  • مناسب برای throughput بالا
  • سازگارتر با محیط‌های cloud-native
  • مناسب برای HTTP/2 و HTTP/3
  • مطلوب‌تر برای معماری‌های policy-driven و GitOps

تجربه عملی: کدام بهتر است؟

اگر بخواهیم صادقانه بگوییم، اینجا «بهتر» مطلق وجود ندارد.

  • اگر workload شما mediation سنگین، dependency به flowهای قدیمی Synapse و تنوع پروتکل بالا دارد، Classic Gateway هنوز انتخاب منطقی‌تری است.
  • اگر API های جدید، cloud-native، پرترافیک و مدرن دارید، API Platform Gateway احتمالاً آینده‌دارتر و سبک‌تر است.

نکته مثبت 4.7 این است که شما را مجبور به انتخاب صفر و یکی نمی‌کند.

تغییر مهم نسخه 4.7: مدیریت هم‌زمان چند Gateway از یک Control Plane

یکی از ارزشمندترین تغییرات این نسخه همین است.

در بسیاری از سازمان‌ها، مشکل فقط «داشتن Gateway جدید» نیست؛ مشکل این است که هر تغییر معماری جدید، هزینه migration، بازطراحی و تغییر فرآیندهای عملیاتی دارد.

WSO2 API Manager 4.7 اینجا هوشمندانه عمل کرده:

به‌جای اینکه بگوید runtime قبلی را کنار بگذارید، control plane را گسترده‌تر کرده تا runtime جدید را هم کنترل کند.

از نگاه تجربی، این یعنی:

  • migration تدریجی ممکن می‌شود
  • ریسک تغییر پایین‌تر می‌آید
  • تیم‌ها می‌توانند workloadها را تفکیک کنند
  • و سازمان مجبور نیست یکباره همه چیز را بازنویسی کند

ارتقای Kubernetes Gateway و Immutable Gateway در نسخه 4.7

در این نسخه فقط API Platform Gateway جدید نشده؛ Kubernetes Gateway و Immutable Gateway هم ارتقای مهمی گرفته‌اند.

Kubernetes Gateway v2.0

Kubernetes Gateway v2.0 حالا به Envoy Gateway ارتقا یافته و با استاندارد Kubernetes Gateway API هم‌راستاتر شده است.

این تغییر از نظر معماری مهم است چون:

  • traffic management مدرن‌تر می‌شود
  • سازگاری با اکوسیستم Kubernetes بهتر می‌شود
  • extensibility افزایش پیدا می‌کند
  • و deployment در کلاسترهای cloud-native منطقی‌تر می‌شود

در مقایسه با نسخه‌های قبلی، این فقط یک upgrade فنی نیست؛ یک هم‌ترازی راهبردی با استانداردهای مدرن Kubernetes است.

Immutable Gateway v4.0

Immutable Gateway v4.0 هم حالا روی همان foundation مدرن مبتنی بر Envoy و Go ساخته شده و برای سناریوهایی مناسب است که:

  • air-gapped هستند
  • نیازهای رگولاتوری دارند
  • در edge deploy می‌شوند
  • یا APIها باید در زمان build داخل image قرار بگیرند

این نسخه نسبت به قبل یکپارچگی بیشتری با خانواده Gateway های جدید WSO2 دارد.

MCP Governance در WSO2 API Manager 4.7تفاوت مهم با 4.6

نسخه 4.6 اولین گام‌ها برای MCP را معرفی کرده بود.

در آن نسخه می‌شد:

  • MCP را proxy کرد
  • REST APIها را به‌عنوان MCP tool ارائه کرد
  • یا MCP serverهای موجود را پشت proxy مدیریت‌شده قرار داد

اما در 4.7 یک لایه خیلی مهم‌تر اضافه شده: MCP Governance

MCP Governance یعنی چه؟

یعنی حالا می‌توان برای MCP Proxyها ruleهای سازمانی تعریف کرد و این ruleها را به‌صورت مرکزی اعمال کرد؛ نه اینکه هر تیم جداگانه برای هر Proxy تنظیمات خودش را انجام دهد.

این governance می‌تواند شامل:

  • کنترل دسترسی
  • سیاست‌های امنیتی
  • rate limiting
  • policy enforcement
  • و کنترل یکپارچه روی traffic مربوط به tool callها باشد.

چرا این تفاوت مهم است؟

چون سازمانی که می‌خواهد AI agent ها یا MCP server ها را وارد اکوسیستم خود کند، به چیزی بیشتر از connectivity نیاز دارد.

نیاز اصلی، governance است.

از نگاه عملیاتی، تفاوت 4.6 و 4.7 دقیقاً همین‌جاست:

  • 4.6 بیشتر درباره enable کردن MCP بود
  • 4.7 درباره کنترل سازمانی MCP است

بهبودهای API Key و OAuth در WSO2 API Manager 4.7

این بخش شاید در ظاهر کمتر از Gateway جدید دیده شود، اما برای تیم‌هایی که در production و در مقیاس بالا با OAuth کار می‌کنند، یکی از مهم‌ترین بخش‌های release است.

مهم‌ترین بهبودها شامل این موارد است:

  • access tokenها به‌صورت پیش‌فرض دیگر در دیتابیس محصول persist نمی‌شوند
  • امکان تعیین حداکثر زمان انقضای global برای OAuth2 application access token فراهم شده
  • rotation برای secretها می‌تواند به‌صورت policy اجباری شود
  • نوع generic با عنوان Other برای key managerها اضافه شده تا بدون connector اختصاصی هم بتوان key manager جدید onboard کرد

تفاوت با نسخه‌های قدیمی‌تر چیست؟

در نسخه‌های قبلی، بعضی از این رفتارها یا وجود نداشت یا به این سطح از کنترل و policy نرسیده بود.

در 4.7 WSO2 نشان داده که به نیازهای production-grade در مدیریت token و secret توجه بیشتری کرده است.

از نگاه تجربه عملی، این بهبودها کمک می‌کنند:

  • امنیت بهتر شود
  • چرخه عمر credentialها بهتر کنترل شود
  • و انعطاف‌پذیری اتصال به key manager های متنوع بیشتر شود

پشتیبانی از AsyncAPI v3 در نسخه 4.7

یکی دیگر از تغییرات مهم، پشتیبانی از AsyncAPI 3.x.x است.

WSO2 از قبل هم از AsyncAPI پشتیبانی می‌کرد، اما در نسخه 4.7 این پشتیبانی با ارتقای parser مربوطه به سطح جدیدتری رسیده است.

چرا این موضوع مهم است؟

چون APIها دیگر فقط REST نیستند.

در معماری‌های مدرن، event-driven communication و asynchronous interfaceها اهمیت بیشتری پیدا کرده‌اند.

پشتیبانی از AsyncAPI v3 یعنی:

  • import
  • versioning
  • و deployment

برای APIهای async هم در همان workflow کلی قابل انجام است.

در مقایسه با نسخه‌های قبلی، این تغییر نشان می‌دهد محصول تلاش کرده فقط روی APIهای synchronous متمرکز نماند.

پشتیبانی از JDK 21 تغییری مهم اما زیرپوستی

WSO2 API Manager 4.7 کامپایل محصول را از JDK 11 به JDK 21 منتقل کرده است.

نکته مهم اینجاست که runtime از قبل هم از JDK 17 و JDK 21 پشتیبانی می‌کرد، اما حالا compile-time هم با نسخه جدیدتر هم‌راستا شده است.

این چه تفاوتی با قبل دارد؟

در نسخه‌های قبل، compile baseline قدیمی‌تر بود.

در 4.7 این موضوع به‌روزرسانی شده تا:

  • با dependencyهای جدیدتر هماهنگ‌تر باشد
  • از یک Java LTS مدرن‌تر استفاده شود
  • و maintenance horizon طولانی‌تری فراهم شود

این تغییر شاید برای مدیران کسب‌وکار خیلی visible نباشد، اما برای تیم‌های platform و operation مهم است.

تجربه عملی: آیا باید به WSO2 API Manager 4.7 مهاجرت کرد؟

اگر تجربه پروژه‌های واقعی را معیار قرار دهیم، پاسخ معمولاً این است:

بله، اما نه با نگاه صرفاً «نسخه جدید آمده، پس ارتقا بدهیم».

باید دید سازمان شما در کدام دسته قرار می‌گیرد.

اگر این شرایط را دارید، 4.7 ارزش زیادی دارد

  • می‌خواهید به‌تدریج به Gateway مدرن‌تر حرکت کنید
  • Kubernetes و cloud-native برایتان مهم شده
  • به HTTP/2 یا HTTP/3 نیاز دارید
  • روی AI Agentها یا MCP کار می‌کنید
  • در OAuth و token policy به کنترل دقیق‌تری نیاز دارید

اگر هنوز خیلی وابسته به runtime کلاسیک هستید

حتی در این حالت هم 4.7 جذاب است، چون:

  • Classic Gateway حذف نشده
  • deprecate نشده
  • و همچنان fully supported است

این یعنی ارتقا لزوماً شما را وارد migration اجباری نمی‌کند.

مزیت واقعی WSO2 API Manager 4.7 نسبت به نسخه‌های قبلی چیست؟

اگر بخواهیم همه چیز را در چند نکته جمع کنیم، مزیت واقعی 4.7 این‌هاست:

  • control plane گسترده‌تر شده
  • Gateway جدید بدون حذف Gateway قدیمی اضافه شده
  • Kubernetes و Immutable Gateway مدرن‌تر شده‌اند
  • MCP از سطح پشتیبانی اولیه به سطح governance رسیده
  • OAuth و API key برای production پخته‌تر شده‌اند
  • محصول برای workloadهای جدیدتر آماده‌تر شده است

یعنی 4.7 بیشتر از آنکه نسخه‌ای صرفاً feature-based باشد، نسخه‌ای transition-friendly است؛

نسخه‌ای که سازمان را از گذشته جدا نمی‌کند، اما برای آینده هم آماده‌تر می‌سازد.

جمع‌بندی

WSO2 API Manager 4.7 را نباید فقط یک minor release معمولی دید. این نسخه در عمل یک گسترش مهم در دامنه کنترل و معماری محصول ایجاد کرده است. اگر سازمانی به دنبال modernizing تدریجی معماری API خود باشد، بدون اینکه مجبور به migration ناگهانی شود، نسخه 4.7 یکی از منطقی‌ترین releaseهایی است که WSO2 در این مسیر ارائه داده است.

آپدیت‌ها و موارد اضافه‌شده در نسخه 4.7 نسبت به نسخه‌های قبلی:

  • معرفی API Platform Gateway (مبتنی بر Envoy Proxy و معماری Go)
  • امکان مدیریت هم‌زمان دوگانه Gateway (Classic Gateway و API Platform Gateway) از یک Control Plane مشترک
  • پشتیبانی از پروتکل‌های HTTP/2 و HTTP/3 در Gateway جدید
  • ارتقای Kubernetes Gateway به نسخه v2.0 (بر پایه Envoy Gateway و هم‌راستا با Kubernetes Gateway API)
  • ارتقای Immutable Gateway به نسخه v4.0 (بر پایه foundation مبتنی بر Envoy و Go)
  • اضافه شدن MCP Governance (حاکمیت و سیاست‌گذاری مرکزی برای MCP Proxyها)
  • ارتقای parser و پشتیبانی رسمی از AsyncAPI v3
  • انتقال baseline کامپایل محصول از JDK 11 به JDK 21
  • تغییر رفتار پیش‌فرض به‌صورت عدم persist شدن access tokenها در دیتابیس
  • اضافه شدن قابلیت تعیین حداکثر زمان انقضای global برای OAuth2 application access tokenها
  • اضافه شدن امکان اجباری کردن rotation برای secretها به‌صورت policy
  • اضافه شدن نوع generic (با عنوان Other) برای onboarding Key Managerهای جدید بدون نیاز به connector اختصاصی
بازگشت به مقالات
قبلی متد HTTP QUERY چیست؟

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *