ساخت مدل جزء برای Wasm

مدل مؤلفه WebAssembly زمینه را برای یک سیستم مؤلفه شناسی زبان ایجاد می کند، سیستمی که به هر برنامه Wasm اجازه می دهد از مؤلفه های نوشته شده در هر زبان برنامه نویسی استفاده کند.

• چرا Wasm فراتر از مرورگر؟
• WASI: مرز Wasm سمت سرور
• مدل مؤلفه WebAssembly چیست؟
• ایجاد یک پایه فنی پایدار برای WASI و اجزا

چندین تلاش استانداردسازی جدید در فضای WebAssembly (معروف به Wasm) در حال انجام است، از جمله آنچه ما معتقدیم روش جدیدی برای نوشتن برنامه های نرم افزاری است. به عنوان راهی برای توصیف این مدل جدید و نشان دادن اینکه به طور کلی با استانداردهای WebAssembly به کجا می رویم، می خواهم به برخی از تاریخچه Wasm بپردازم.

طراحی WebAssembly در سال ۲۰۱۵ آغاز شد، سال‌ها قبل از اینکه در سال ۲۰۱۹ به طور رسمی به چهارمین زبان وب تبدیل شود. در حالی که بسیاری از فن‌آوران با Wasm به عنوان یک فناوری مرورگر آشنا هستند، Wasm خود به جاوا اسکریپت یا APIهای وب وابسته نیست.

>

پیش ساز Wasm، asm.js، در سال ۲۰۱۳ به شهرت رسید. زیر مجموعه ای از جاوا اسکریپت که با قابلیت بهینه سازی بسیار برای مرورگرها، asm.js همچنین می تواند به عنوان یک هدف کامپایل برای زبان هایی مانند C و C++ عمل کند. یکی از گفتگوهای مورد علاقه من، تولد و مرگ جاوا اسکریپت< /a>، توسط گری برنهارت، آینده ای تخیلی با الهام از asm.js را پوشش می دهد. اگر این سخنرانی را که گری در PyCon 2014 ارائه کرد، تماشا می‌کنید، نمی‌توانید شباهت‌های بین آینده‌ای را که در نهایت با پیش‌بینی‌های Wasm و گری هموار می‌کنیم، متوجه نشوید.

تکنولوژی چندین چیز را ثابت کرد. اول، نیاز و تمایل به آوردن زبان های دیگر به وب وجود دارد، اما توسعه دهندگان نمی خواستند در اینجا متوقف شوند. انواع برنامه‌هایی که پورت می‌شدند از نظر محاسباتی و گرافیکی، از ابزارهای تجسم داده‌ها (مانند اجزایی که در SAS روی آنها کار کردم)، تا بازی‌های ساخته شده با Unity و Unreal Engine (UE3 پورت شد در چهار روز).

به همین دلیل است که وقتی گروه انجمن W3C WebAssembly و مخزن طراحی WebAssembly در سال ۲۰۱۵ ایجاد شد، فروشندگان مرورگر مانند موزیلا، گوگل، مایکروسافت و اپل جزو اولین کسانی بودند که در این تلاش مشارکت داشتند و اولین کسانی بودند که یک فرصت ملموس را ببینید این طرح به زبانی با فرمت دودویی نیاز داشت که بتواند به عنوان یک هدف کامپایل قابل حمل استفاده شود، که برای اندازه بهینه شده باشد تا امکان دانلود سریع را فراهم کند، و دارای پشتیبانی از کامپایل جریانی باشد که به ماژول دانلود شده اجازه می دهد تا نمونه سازی فوری داشته باشد. مهم‌تر از همه، این ماژول‌ها باید محیط‌های اجرایی را تسهیل کنند، همانطور که هر کد دلخواه اجرا شده در مرورگرها باید.

چرا Wasm فراتر از مرورگر؟

بسیاری از چیزهایی که در استقرارهای سمت مرورگر آموخته شد، سرنخ‌هایی از راه‌های زیادی که Wasm می‌توانست پتانسیل خود را فراتر از مرورگر برآورده کند، به دست می‌دهد. «ابر» مجموعه‌ای ناهمگون از معماری‌های محاسباتی، سیستم‌های عامل و محدودیت‌های سیستم را در یک شبکه جهانی ماشین‌آلات تشکیل می‌دهد.

برخی از ویژگی‌های کلیدی Wasm را به‌عنوان یک هدف کامپایل قابل حمل در نظر بگیرید که به لطف فرمت باینری فشرده، سریع، جعبه‌شنی و به راحتی توزیع می‌شود. این ویژگی‌های Wasm آن را به واحد محاسباتی قابل توزیع کامل برای ابر تبدیل می‌کند. علاوه بر این، شرکت‌ها می‌خواهند برنامه‌های کاربردی برای محیط‌های مختلف بسازند، اما نمی‌خواهند هر بار مجبور به بازسازی شوند. Wasm این موانع را حذف می کند.

وقتی برای اولین بار با asm.js آشنا شدم، در جستجوی راه حلی برای نحوه انتقال برنامه Flash موجود خود به HTML5 بودم. این برنامه ActionScript/Flex یک نسخه بازنویسی شده از همتای جاوا خود بود، که درگاهی از نسخه‌های قبلی همان منطق تجاری نوشته شده به زبان C بود. اگر در شرکت‌های بزرگ کار نکرده‌اید، این داستان ممکن است به نظر شما عجیب و غریب باشد، اما می‌توانید این نوع انتقال را بین هر دوره از محاسبات در هر سازمانی پیدا کنید که به اندازه کافی خوش شانس است که از آزمون زمان جان سالم به در ببرد.

Wasm قابلیت حمل کامل را برای هر زمان اجرا سازگار با Wasm از جمله مرورگرها، زمان‌های اجرا که برای FaaS به‌منظور ساخته شده‌اند، یا زمان‌هایی که برای اجرا در معماری‌های کوچک برای اینترنت اشیا طراحی شده‌اند، امکان پذیر می‌سازد. در وب، ماژول‌های Wasm می‌توانند از کد «چسب» جاوا اسکریپت برای دسترسی به APIهای وب مانند WebGL، شبکه و دستگاه‌ها برای انجام کارهایی فراتر از محاسبات خالص استفاده کنند. در پایان روز، یک برنامه Wasm واقعاً فقط در مقادیر عددی. (یا به عبارت دیگر، یک ماژول Wasm مجموعه ای از i32 ها در یک برای انجام کارهای جالب، یک ماژول Wasm باید بتواند توابع را از زمان اجرا میزبان فراخوانی کند.

WASI: مرز Wasm سمت سرور

تقریباً همزمان با تبدیل WebAssembly 1.0 به یک استاندارد وب توصیه شده، یک زیرگروه جدید در گروه کاری W3C WebAssembly برای بررسی یک رابط سطح سیستم برای WebAssembly به نام WASI (واسط سیستم های WebAssembly). این گروه از آن زمان بر روی ایجاد مجموعه ای از رابط های استاندارد کار می کند.

WASI برای اینکه WebAssembly در همه جا به خوبی کار کند، نه فقط در مرورگر، وجود دارد، اما ویژگی اصلی تعیین کننده WASI مدل امنیتی مبتنی بر قابلیت آن است. امنیت مبتنی بر قابلیت از دهه ۱۹۶۰ وجود داشته است (دنیس و ون هورن، ۱۹۶۶< /a>)، اما دان گوهمان با ایجاد ایده‌هایی از Cloud ABI.

قابل درک است که این فناوری به زودی توجه شرکت های علاقه مند به اجرای Wasm در خارج از وب را به خود جلب کرد. شرکت‌هایی مانند Fastly، Intel، Red Hat و Mozilla این فرصت را دیدند تا Wasm را در فضای ابری، دستگاه‌ها و در لبه کار کنند. این شرکت‌ها اعضای مؤسس Bytecode Alliance (BA) بودند، یک سازمان غیرانتفاعی برای ایجاد پایه‌های نرم‌افزار ایمن برای Wasm. با استفاده از استانداردهایی مانند WASI. بسیاری از سازمان های دیگر به زودی به BA پیوستند، از جمله بازیگران اصلی در سراسر صنعت نرم افزار. BA اکنون بیش از ۳۰ عضو دارد و در حال رشد است!

در چند سال گذشته، ما پیشرفت زیادی در جهت ساخت ابزارهای لازم برای اجرای Wasm در برنامه‌های بومی ابری داشته‌ایم. جامعه چیزهای زیادی از این تجربیات اولیه آموخت که ما را بر آن داشت تا استاندارد جدیدی ایجاد کنیم که آن را مدل مؤلفه< می نامیم. /a>. مدل کامپوننت در سطح پایین تری نسبت به WASI قرار دارد. با WASI به خوبی کار می کند اما به WASI وابسته نیست.

این داستان نحوه شکل گیری مدل مؤلفه است. هر یک از پیشنهادهای قبلی اکنون در این استاندارد کلی اصلاح شده است. ما انتظار داریم که در اواخر سال جاری شاهد تکرار پایدار بعدی استانداردهای WASI و مدل مؤلفه باشیم.

استانداردهای WASI: اکنون کجا هستیم؟

لوک واگنر و بیلی هیز یک تور راهنما از تاریخچه Wasm، WASI و توسعه مدل جزء ارائه می دهند.

نقاط عطف واسم

اگر سفر WebAssembly را از سال ۲۰۱۹ دنبال کنید، می‌توانید ببینید که چگونه استانداردها متنوع شده‌اند، زیرا موارد استفاده زیاد شده است و کاربران شروع به انتخاب و انتخاب آنچه نیاز دارند و نیاز ندارند. WebAssembly از یک بلوک همه جا حاضر به مجموعه رو به رشدی از بلوک های ساختمانی کوچکتر تبدیل شده است که برای کار با یکدیگر در یک چارچوب انعطاف پذیر، یعنی مدل مؤلفه طراحی شده اند.

۲۰۱۹: هدف کامپایل خالص، افزودن رابط‌های اولیه که syscals را به میزبان متصل می‌کند. از بسیاری جهات، به نظر می رسید که ما به سمت یک نسخه WebAssembly از POSIX می رویم. ما توانستیم یک CLI واقعا ساده بنویسیم و آن را با Wasmtime روی دسکتاپ یا در یک عملکرد بدون سرور اجرا کنیم.

۲۰۲۰: APIهای WASI بر روی انواع چیزهایی که هر برنامه CLI ممکن است به آن نیاز داشته باشد، متمرکز هستند، مانند ساعت سیستم یا سیستم فایل. زمان اجرا Lucet Wasm Fastly با Wasmtime (یک پروژه کارشناسی) ادغام شد.

۲۰۲۱: البته، همه این عناصر همچنان در حال تکامل و بهبود هستند. در سال ۲۰۲۱، ما شروع به توسعه رابط‌های جدید WASI مخصوص موارد استفاده می‌کنیم، مانند wasi-nn برای شتاب سخت‌افزاری برای استنتاج. همچنین امسال سالی است که لوک واگنر شروع به تعریف مدل مؤلفه کرد.

۲۰۲۲: ما شروع به مشاهده APIهای سطح بالاتر جدیدی برای ساخت ماژول‌های Wasm در محیط‌های ابری می‌کنیم که در آن به قابلیت‌هایی مانند کار با فروشگاه ارزش کلیدی یا سرویس پیام‌رسانی میخانه/فرعی نیاز است. بالاخره بعد از کلی کار سوکت های WASI معرفی شدند.

۲۰۲۳: ما در حال کار روی نقاط عطف پایداری برای مدل مؤلفه و استانداردهای WASI هستیم.

مدل مؤلفه WebAssembly چیست؟

در مدل مؤلفه WebAssembly، توسعه‌دهندگان می‌توانند بخش‌هایی از برنامه خود را که به زبان‌های مختلف پیاده‌سازی شده‌اند، به‌عنوان گزاره‌های ارزشی متفاوت انتخاب و انتخاب کنند. همانطور که توسعه دهندگان شروع به ایجاد کتابخانه های مؤلفه Wasm می کنند، توسعه دهندگان دیگر می توانند آنها را به عنوان بزرگترین جعبه نرم افزار جهان “Lego” در نظر بگیرند.

در یک دایره کامل، ما معتقدیم که نوآوری جدید زمانی به وجود خواهد آمد که مدل مؤلفه شروع به تأثیرگذاری بر نحوه نوشتن برنامه های وب کند. این زمانی منطقی به نظر می رسد که وب یکی از آن محیط های خنک اما محدود با کاربران بسیار کم حوصله است – بستری برای آزمایش های تازه.

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

با سیستم آینده مؤلفه‌های Wasm برای وب، که در آن یک برنامه واحد ممکن است مؤلفه‌های انتخابی خود را به هر زبانی نوشته شود، یک برنامه فقط باید دقیقاً آنچه را که نیاز دارد دانلود کند و مانند هر ماژول ES دیگری با مؤلفه‌ها تعامل داشته باشد. یک واردات در این دنیا بهترین جزء به اوج می رسد. بهترین می تواند به معنای سریع ترین یا تمیزترین API باشد، اما مهمتر از همه ویژگی تعیین کننده آن زبان مبدأ نخواهد بود. باشد که بهترین مؤلفه برنده شود!

ایجاد یک پایه فنی پایدار برای WASI و اجزای آن

بخش بزرگی از واقعی ساختن استانداردهای WASI و مدل مؤلفه، نقشی است که BA در ایجاد یک چارچوب فنی قابل استفاده ایفا می کند: SDK ها، ابزارها و مؤلفه های اصلی. همه باید به شیوه ای منسجم و ایمن ساخته شوند و برای همه به عنوان نمونه هایی از بهترین عملکرد قابل دسترسی باشند.

به همین ترتیب، نقش کمیته راهبری فنی (TSC) BA در ارائه حاکمیت فنی و پشتیبانی برای هر پروژه BA حیاتی خواهد بود. ما در کنار افرادی که بهترین مجموعه استانداردهای ممکن را در گروه های کاری W3C WebAssembly و WASI طراحی می کنند، کار می کنیم، به این معنی که با آنها همکاری می کنیم تا مطمئن شویم همه چیز در عمل کار می کند. گروه‌های W3C WebAssembly و WASI بر نهایی کردن این استانداردها متمرکز شده‌اند و BA بر روی قابل مصرف کردن آنها در جامعه در سریع‌ترین زمان ممکن برای ایجاد یک حلقه بازخورد فعال متمرکز است.

یکی دیگر از بخش‌های مهم منشور BA، فعال کردن قابلیت همکاری زبان و محیط است. BA ابزارهایی را برای ایجاد پیوندهای زبانی برای بسیاری از زبان‌های مختلف فراهم می‌کند، اما دستیابی به نیروانای قابلیت همکاری زبان همچنین نیازمند ثبت و مدیران بسته در اکوسیستم‌های زبانی مختلف برای تعامل با مؤلفه‌های Wasm است. به همین دلیل است که ما در حال کار روی طراحی یک پروتکل رجیستری به نام warg به عنوان بخشی از SIG-Registries هستیم. . هدف این است که هر رجیستری که این پروتکل را پیاده‌سازی می‌کند فعال کند تا مؤلفه‌های Wasm را منتشر، مصرف، ذخیره و به اشتراک بگذارد.

شاید مهم‌ترین بخش از هر پشته نرم‌افزار Wasm، زمان اجرا Wasm باشد و BA میزبان دو است. Wasmtime که به زبان Rust نوشته شده است، اغلب بستر آزمایشی برای آزمایش پیشنهادات جدید WASI و WebAssembly است. WebAssembly Micro-Runtime (Wamr) که به زبان C نوشته شده است، از بسیاری از معماری ها از جمله معماری های کوچک پشتیبانی می کند. مانند ESP32. هر دوی این زمان‌های اجرا به‌عنوان پیاده‌سازی مرجع عالی یک زمان اجرا Wasm عمل می‌کنند. SDKها و ابزارهای ساخت ماژول Wasm با استانداردهای Wasm مطابقت دارند، بنابراین هر زمان اجرای Wasm مطابق با استانداردها (از جمله مواردی که توسط BA میزبانی نمی شوند) می توانند بر روی این پایه های نرم افزاری ایجاد شوند.

با توجه به تمام استانداردهای جدید و هیجان انگیزی که از طریق WASI و مدل اجزا و پیاده سازی های Bytecode Alliance در حال تکامل هستند، سال ۲۰۲۳ سال هیجان انگیزی برای Wasm است!

بیلی هیز مدیر Cosmonic و مدیر کمیته راهبری فنی اتحاد Bytecode است.

—

انجمن فناوری جدید مکانی را برای کاوش و بحث در مورد فناوری سازمانی نوظهور در عمق و وسعت بی سابقه ای فراهم می کند. انتخاب ذهنی است، بر اساس انتخاب ما از فناوری هایی که معتقدیم مهم هستند و برای خوانندگان InfoWorld بیشترین علاقه را دارند. InfoWorld وثیقه بازاریابی را برای انتشار نمی پذیرد و حق ویرایش تمام محتوای ارائه شده را برای خود محفوظ می دارد. همه سوالات را به newtechforum@infoworld.com ارسال کنید.