مفاهیم معماری توزیع شده را که هنگام ساختن یک سیستم پرداخت بزرگ یاد گرفتم. کیت ماتسودیرا: معماری وب مقیاس پذیر و سیستم های توزیع شده

n1.doc

11. معماری سیستم های توزیع شده

اهداف
هدف این فصل بررسی معماری سیستم های نرم افزاری توزیع شده است. پس از خواندن این فصل، باید:

• 
  مزایا و معایب اصلی سیستم های توزیع شده را بشناسید.
• 
  درک درستی از رویکردهای مختلف مورد استفاده در توسعه معماری مشتری/سرور داشته باشند.
• 
  درک تفاوت بین معماری مشتری/سرور و معماری اشیاء توزیع شده؛
• 
  مفهوم کارگزار درخواست شی و اصول پیاده سازی شده در استانداردهای CORBA را بشناسید.

در حال حاضر، تقریبا تمام سیستم های نرم افزاری بزرگ توزیع شده اند. سیستم توزیع شده سیستمی است که در آن پردازش اطلاعات بر بیش از یک مورد متمرکز است کامپیوتراما در چندین رایانه توزیع شده است. هنگام طراحی سیستم های توزیع شده، که شباهت زیادی با طراحی هر نرم افزار دیگری دارد، باید تعدادی از ویژگی های خاص را در نظر گرفت. برخی از این موارد قبلاً در مقدمه فصل 10 هنگام بحث در مورد معماری کلاینت/سرور ذکر شده است، و در اینجا با جزئیات بیشتر مورد بحث قرار می گیرند.

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

تمام سیستم های نرم افزاری مدرن را می توان به سه کلاس بزرگ تقسیم کرد.
1. سیستم‌های نرم‌افزاری کاربردی که برای اجرا فقط بر روی یک رایانه شخصی یا ایستگاه کاری طراحی شده‌اند. این شامل واژه پردازها، صفحات گسترده، سیستم های گرافیکی و غیره

2. سیستم های تعبیه شده که برای اجرا بر روی یک پردازنده یا روی یک گروه یکپارچه از پردازنده ها طراحی شده اند. اینها شامل سیستم های کنترل لوازم خانگی، لوازم مختلف و غیره است.

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

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

2. باز بودن.این توانایی گسترش سیستم با افزودن منابع جدید است. سیستم های توزیع شده هستند سیستم های باز، که سخت افزار و نرم افزار سازنده های مختلف به آن متصل است.

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

4. مقیاس پذیری.در اصل، همه سیستم های توزیع شده مقیاس پذیر هستند: برای اینکه یک سیستم نیازهای جدید را برآورده کند، می توان با افزودن منابع محاسباتی جدید، آن را افزایش داد. اما در عمل، رشد ممکن است محدود به شبکه ای باشد که رایانه های فردی را در سیستم به هم متصل می کند. اگر بسیاری از ماشین های جدید را متصل کنید، ممکن است پهنای باند شبکه کافی نباشد.

5. تحمل خطا.وجود رایانه های متعدد و امکان تکرار اطلاعات به این معنی است که سیستم های توزیع شده در برابر سخت افزارهای خاص مقاوم هستند و اشکالات نرم افزاری(به فصل 18 مراجعه کنید). اکثر سیستم های توزیع شده معمولاً می توانند حداقل عملکرد جزئی را در صورت بروز خطا حفظ کنند. خرابی کامل سیستم تنها در صورت بروز خطاهای شبکه رخ می دهد.

6. شفافیت.این خاصیت به این معنی است که به کاربران کامل داده می شود دسترسی شفافبه منابع و در عین حال اطلاعات مربوط به توزیع منابع در سیستم از آنها پنهان است. با این حال، در بسیاری از موارد، دانش خاص در مورد سازماندهی سیستم به کاربر کمک می کند تا از منابع بهتر استفاده کند.
البته سیستم های توزیع شده دارای معایبی هستند.

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

ایمنی.معمولاً از چندین سیستم می توان به سیستم دسترسی داشت ماشین های مختلف، پیام های موجود در شبکه را می توان مشاهده یا رهگیری کرد. بنابراین، حفظ امنیت در یک سیستم توزیع شده بسیار دشوارتر است.

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

غیر قابل پیش بینی بودنهمانطور که همه کاربران وب می دانند، پاسخ سیستم های توزیع شده به رویدادهای خاص غیرقابل پیش بینی است و بستگی به آن دارد بارگذاری کاملسیستم، سازماندهی آن و بار شبکه. از آنجایی که همه این پارامترها دائماً می توانند تغییر کنند، زمان صرف شده برای تکمیل درخواست کاربر می تواند در یک زمان به طور قابل توجهی متفاوت باشد.
در بحث در مورد مزایا و معایب سیستم های توزیع شده، این کتاب تعدادی از مسائل طراحی حیاتی را برای چنین سیستم هایی شناسایی می کند (جدول 11.1). این فصل بر روی معماری نرم افزار توزیع شده تمرکز دارد، همانطور که من معتقدم که در هنگام توسعه محصولات نرم افزاریاین لحظه مهم ترین است. در صورت علاقه مندی به موضوعات دیگر به کتاب های تخصصی سیستم های توزیع شده مراجعه نمایید.
جدول 11.1. مشکلات طراحی سیستم های توزیع شده

وظیفه توسعه دهندگان سیستم های توزیع شده طراحی نرم افزار یا سخت افزار برای ارائه تمام ویژگی های لازم یک سیستم توزیع شده است. و این مستلزم دانستن مزایا و معایب معماری های مختلف سیستم های توزیع شده است. دو نوع مرتبط از معماری سیستم های توزیع شده وجود دارد.
1. معماری کلاینت/سرور.در این مدل می توان سیستم را به صورت نمایش داد مجموعه ای از خدماتتوسط سرورها به مشتریان ارائه می شود. در چنین سیستم هایی، سرورها و کلاینت ها به طور قابل توجهی با یکدیگر تفاوت دارند.

2. معماری اشیاء توزیع شدهدر این حالت هیچ تفاوتی بین سرورها و کلاینت ها وجود ندارد و سیستم را می توان مجموعه ای از اشیاء تعاملی در نظر گرفت که مکان آنها واقعاً مهم نیست. هیچ تفاوتی بین ارائه دهنده خدمات و کاربران آنها وجود ندارد.
در یک سیستم توزیع شده، اجزای مختلف سیستم را می توان بر روی آن پیاده سازی کرد زبانهای مختلفبرنامه نویسی و اجرا بر روی انواع مختلف پردازنده ها. مدل های داده، نمایش اطلاعات و پروتکل های تعامل - همه اینها لزوماً در یک سیستم توزیع شده از یک نوع نیستند. بنابراین سیستم های توزیع شده نیاز به نرم افزاری دارند که بتواند این قسمت های ناهمگن را مدیریت کرده و تعامل و تبادل داده ها را بین آنها تضمین کند. میان افزارمتعلق به این دسته از نرم افزارها است. همانطور که بود، در وسط بین بخش های مختلف اجزای توزیع شده سیستم قرار دارد.

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

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

11.1. معماری چند پردازنده

ساده ترین سیستم توزیع شده سیستم چند پردازنده ای است. این شامل بسیاری از فرآیندهای مختلف است که ممکن است (اما لازم نیست) روی پردازنده های مختلف اجرا شود. این مدلاغلب در سیستم های بزرگ بلادرنگ استفاده می شود. همانطور که در فصل 13 خواهید آموخت، این سیستم ها اطلاعات را جمع آوری می کنند، بر اساس آن تصمیم می گیرند و سیگنال هایی را برای عاملی ارسال می کنند که محیط سیستم را تغییر می دهد. اصولاً کلیه فرآیندهای مربوط به جمع آوری اطلاعات، تصمیم گیری و کنترل مکانیسم اجرایی را می توان بر روی یک پردازنده واحد و تحت کنترل زمانبند وظیفه انجام داد. استفاده از چندین پردازنده عملکرد و انعطاف پذیری سیستم را بهبود می بخشد. توزیع فرآیندها بین پردازنده ها می تواند نادیده گرفته شود (ذاتی در سیستم های حیاتی) یا توسط مدیر فرآیند کنترل شود.

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

برنج. 11.1. سیستم کنترل ترافیک چند پردازنده ای
سیستم های نرم افزاری که چندین فرآیند را همزمان اجرا می کنند لزوماً توزیع نمی شوند. اگر بیش از یک پردازنده در سیستم وجود داشته باشد، اجرای توزیع فرآیند دشوار نیست. با این حال، هنگام ایجاد سیستم های نرم افزاری چند پردازنده، لازم نیست فقط از سیستم های توزیع شده شروع شود. طراحی این نوع سیستم ها اساساً از همان رویکرد طراحی سیستم های بلادرنگ که در فصل 13 بحث شد پیروی می کند.

11.2. معماری کلاینت/سرور

فصل 10 قبلاً به مفهوم مشتری/سرور پرداخته است. در معماری کلاینت/سرور، یک برنامه نرم افزاری به عنوان مجموعه ای از خدمات ارائه شده توسط سرورها و مجموعه ای از مشتریان با استفاده از آن خدمات مدل سازی می شود. مشتریان باید از سرورهای موجود (موجود) آگاه باشند، اگرچه ممکن است از وجود مشتریان دیگر آگاه نباشند. همانطور که در شکل دیده میشود. در شکل 11.2 که نموداری از معماری مشتری/سرور توزیع شده است، کلاینت ها و سرورها فرآیندهای متفاوتی را نشان می دهند.


برنج. 11.2. سیستم مشتری/سرور
لازم نیست سیستم یک رابطه یک به یک بین فرآیندها و پردازنده ها داشته باشد. روی انجیر شکل 11.3 معماری فیزیکی سیستم را نشان می دهد که از شش ماشین کلاینت و دو سرور تشکیل شده است. آنها فرآیندهای کلاینت و سرور نشان داده شده در شکل را اجرا می کنند. 11.2. به طور کلی، وقتی در مورد کلاینت‌ها و سرورها صحبت می‌کنم، منظورم فرآیندهای منطقی نیست ماشین های فیزیکیکه این فرآیندها روی آن اجرا می شوند.

معماری سیستم مشتری/سرور باید ساختار منطقی برنامه نرم افزاری در حال توسعه را منعکس کند. روی انجیر 11.4 نگاهی دیگر به یک برنامه نرم افزاری ساختار یافته در سه سطح ارائه می دهد. لایه ارائه اطلاعات و تعامل با کاربران را فراهم می کند. زمان اجرا برنامه منطق برنامه را پیاده سازی می کند. لایه مدیریت داده تمام عملیات پایگاه داده را انجام می دهد. در سیستم های متمرکز، هیچ تفکیک واضحی بین این سطوح وجود ندارد. با این حال، هنگام طراحی سیستم های توزیع شده، لازم است که این لایه ها از هم جدا شوند تا سپس هر لایه بر روی رایانه های مختلف قرار گیرد.

ساده ترین معماری سرویس گیرنده/سرور یک معماری دو لایه است که در آن یک برنامه کاربردی از یک سرور (یا بسیاری از سرورهای یکسان) و گروهی از مشتریان تشکیل شده است. دو نوع از چنین معماری وجود دارد (شکل 11.5).
1. مدل تین مشتری. در این مدل تمامی کارهای اپلیکیشن و مدیریت داده ها بر روی سرور انجام می شود. در دستگاه مشتری، فقط نرم افزار لایه ارائه اجرا می شود.

2. مدل مشتری چاقدر این مدل سرور فقط داده ها را مدیریت می کند. بر روی ماشین کلاینت، عملیات اپلیکیشن و تعامل با کاربر سیستم پیاده سازی می شود.


برنج. 11.3. کامپیوترهای روی یک شبکه کلاینت/سرور

برنج. 11.4. لایه های کاربردی نرم افزار
تین کلاینت معماری دو لایه ساده ترین راه برای انتقال سیستم های متمرکز موجود (به فصل 26 مراجعه کنید) به معماری کلاینت/سرور است. رابط کاربری در این سیستم ها به یک رایانه شخصی "حرکت" می کند و برنامه نرم افزاری خود عملکردهای یک سرور را انجام می دهد. تمام فرآیندهای برنامه را اجرا می کند و داده ها را مدیریت می کند. مدل تین کلاینت را می‌توان در جایی که کلاینت‌ها دستگاه‌های شبکه معمولی هستند پیاده‌سازی کرد کامپیوترهای شخصییا ایستگاه های کاری دستگاه های شبکه یک مرورگر اینترنت و یک رابط کاربری پیاده سازی شده در سیستم را اجرا می کنند.


برنج. 11.5. مدل های مشتری نازک و ضخیم
اشکال اصلی مدل تین کلاینت بار بالای سرور و شبکه است. تمام محاسبات بر روی سرور انجام می شود و این می تواند منجر به قابل توجهی شود ترافیک شبکهبین مشتری و سرور کامپیوترهای مدرن قدرت محاسباتی کافی دارند، اما عملاً در مدل تین کلاینت بانک از آن استفاده نمی شود.

در مقابل، مدل fat client از قدرت محاسباتی ماشین‌های محلی استفاده می‌کند: هم لایه اجرای برنامه و هم لایه ارائه بر روی کامپیوتر مشتری قرار می‌گیرند. سرور در اینجا اساساً یک سرور تراکنش است که تمام تراکنش های پایگاه داده را مدیریت می کند. نمونه ای از این نوع معماری سیستم های ATM است که در آن ATM مشتری و سرور کامپیوتر مرکزی است که پایگاه داده حساب های مشتری را نگهداری می کند.

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


برنج. 11.6. سیستم مشتری/سرور برای شبکه ATM
از آنجایی که اجرای یک برنامه نرم افزاری در یک مدل کلاینت ضخیم تر از مدل تین کلاینت سازماندهی شده است، مدیریت چنین سیستمی دشوارتر است. در اینجا، عملکردهای برنامه در بسیاری از ماشین های مختلف توزیع می شود. نیاز به جایگزینی برنامه منجر به نصب مجدد آن بر روی تمام رایانه های مشتری می شود که در صورت وجود صدها مشتری در سیستم گران است.

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

در یک مدل مشتری/سرور دو لایه، یک مشکل مهم قرار دادن سه لایه منطقی بر روی دو سیستم کامپیوتری - ارائه، اجرای برنامه و مدیریت داده ها است. بنابراین، اگر مدل تین کلاینت انتخاب شود، این مدل اغلب یا دارای مشکلات مقیاس پذیری و عملکرد است، یا در صورت استفاده از مدل کلاینت ضخیم، مشکلات مدیریت سیستم را دارد. برای جلوگیری از این مشکلات، یک رویکرد جایگزین باید اتخاذ شود - مدل سه لایه معماری مشتری/سرور (شکل 11.7). در این معماری، فرآیندهای جداگانه با لایه های ارائه، اجرای برنامه و مدیریت داده مطابقت دارند.


برنج. 11.7. معماری کلاینت/سرور سه لایه
معماری نرم افزار، ساخته شده بر روی یک مدل مشتری / سرور سه لایه، نیازی به سه ندارد سیستم های کامپیوتری. در همان رایانه سرور، می توانید اجرای برنامه و مدیریت داده ها را به عنوان سرورهای منطقی جداگانه اجرا کنید. در عین حال، در صورت افزایش نیازهای سیستم، تفکیک اجرای برنامه و مدیریت داده ها و اجرای آنها بر روی پردازنده های مختلف نسبتا آسان خواهد بود.

یک سیستم بانکی با استفاده از خدمات اینترنتی می تواند با استفاده از معماری مشتری/سرور سه لایه پیاده سازی شود. پایگاه داده صورتحساب (معمولاً در رایانه میزبان قرار دارد) خدمات مدیریت داده را ارائه می دهد، وب سرور از خدمات کاربردی مانند تسهیلات انتقال پول، تولید گزارش، پرداخت قبض و غیره پشتیبانی می کند و رایانه کاربر با مرورگر اینترنت مشتری است. همانطور که در شکل نشان داده شده است. 11.8، این سیستم مقیاس پذیر است زیرا اضافه کردن وب سرورهای جدید با افزایش تعداد مشتریان نسبتا آسان است.

استفاده از معماری سه لایه در این مثال، انتقال داده ها بین وب سرور و سرور پایگاه داده را بهینه کرده است. تعامل بین این سیستم ها نباید بر اساس استانداردهای اینترنت باشد، اما می توان از پروتکل های ارتباطی سطح پایین سریعتر استفاده کرد. به طور معمول، اطلاعات از پایگاه داده توسط میان افزار کارآمدی پردازش می شود که از پرس و جوهای پایگاه داده در زبان پشتیبانی می کند پرس و جوهای ساخت یافته SQL.

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


برنج. 11.8. معماری سیستم بانکی توزیع شده با استفاده ازاینترنت-خدمات
طراحان معماری های مشتری/سرور هنگام انتخاب مناسب ترین آنها باید فاکتورهای مختلفی را در نظر بگیرند. روی میز. 11.2 کاربردهای مختلف معماری کلاینت/سرور را فهرست می کند.
جدول 11.2. کاربرد انواع متفاوتمعماری مشتری/سرور

11.3. معماری اشیاء توزیع شده

در مدل کلاینت/سرور یک سیستم توزیع شده، تفاوت هایی بین کلاینت ها و سرورها وجود دارد. مشتری خدمات را فقط از سرور درخواست می کند، hq نه از سایر مشتریان. سرورها می توانند به عنوان مشتری عمل کنند و خدمات را از سرورهای دیگر درخواست کنند، اما نه از مشتریان. مشتریان باید از خدمات ارائه شده توسط سرورهای خاص و نحوه تعامل آن سرورها آگاه باشند. این مدل برای بسیاری از انواع برنامه ها عالی است، اما در عین حال توسعه دهندگان سیستم را که باید تصمیم بگیرند کجا خدمات ارائه کنند، محدود می کند. آنها همچنین باید از مقیاس پذیری پشتیبانی کنند و ابزارهایی را برای گنجاندن مشتریان در سرورهای توزیع شده توسعه دهند.

یک رویکرد کلی تر مورد استفاده در طراحی سیستم توزیع شده، محو کردن تمایز بین مشتری و سرور و طراحی معماری سیستم به عنوان یک معماری شی توزیع شده است. در این معماری (شکل 11.9)، اجزای اصلی سیستم اشیایی هستند که مجموعه ای از خدمات را از طریق رابط های خود ارائه می کنند. اشیاء دیگر این خدمات را بدون تمایز بین مشتری (کاربر سرویس) و سرور (ارائه دهنده خدمات) فراخوانی می کنند.


برنج. 11.9. معماری اشیاء توزیع شده
اشیاء می توانند در رایانه های مختلف در شبکه قرار داشته باشند و از طریق میان افزار تعامل داشته باشند. با قیاس با گذرگاه سیستم، که به شما امکان اتصال را می دهد دستگاه های مختلفو پشتیبانی از ارتباطات بین سخت افزار، میان افزار را می توان به عنوان یک گذرگاه نرم افزاری در نظر گرفت. مجموعه ای از خدمات را ارائه می دهد که به اشیا اجازه می دهد با یکدیگر تعامل داشته باشند، آنها را به سیستم اضافه یا حذف کنند. میان‌افزار، واسطه درخواست شی نامیده می‌شود. وظیفه آن ایجاد رابط بین اشیا است. کارگزاران درخواست شی در بخش 11.4 مورد بحث قرار گرفته اند.

مزایای اصلی مدل معماری شی توزیع شده در زیر ذکر شده است.
توسعه دهندگان سیستم ممکن است در تصمیم گیری در مورد مکان و نحوه ارائه خدمات کند باشند. اشیایی که خدمات ارائه می دهند می توانند در هر نقطه (گره) شبکه اجرا شوند. بنابراین، تفاوت بین مدل های ضخیم و نازک کلاینت بی ربط می شود، زیرا نیازی به برنامه ریزی برای قرار دادن اشیا از قبل برای اجرای برنامه نیست.

معماری سیستم کاملاً باز است که به شما امکان می دهد در صورت لزوم منابع جدیدی را به سیستم اضافه کنید. بخش بعدی اشاره می کند که استانداردهای گذرگاه نرم افزار به طور مداوم در حال تغییر هستند تا به اشیاء نوشته شده در زبان های برنامه نویسی مختلف اجازه تعامل و ارائه خدمات به یکدیگر را بدهد.

انعطاف پذیری و مقیاس پذیری سیستم. برای مقابله با بارهای سیستم، می توانید نمونه هایی از سیستم را با همان خدمات ایجاد کنید که توسط اشیاء مختلف یا نمونه های مختلف (کپی) از اشیاء ارائه می شود. هنگامی که بار افزایش می یابد، می توان اشیاء جدیدی را بدون وقفه در کار سایر اشیاء در سیستم به سیستم اضافه کرد.

پیکربندی مجدد پویا سیستم با استفاده از اشیاء در شبکه در صورت تقاضا امکان پذیر است. اشیاء ارائه دهنده خدمات می توانند به همان پردازنده ای مهاجرت کنند که اشیاء درخواست خدمات می کنند و در نتیجه عملکرد سیستم را بهبود می بخشد.
معماری شی توزیع شده را می توان به دو صورت در فرآیند طراحی سیستم مورد استفاده قرار داد.
1. در قالب یک مدل منطقی که به توسعه دهندگان امکان ساختار و برنامه ریزی سیستم را می دهد. در این مورد، عملکرد برنامه فقط در شرایط و ترکیبی از خدمات توضیح داده شده است. سپس، راه هایی برای ارائه خدمات با استفاده از چندین اشیاء توزیع شده توسعه می یابد. در این سطح، به عنوان یک قاعده، اشیاء ماژول بزرگ طراحی می شوند که خدماتی را ارائه می دهند که منعکس کننده ویژگی های یک منطقه کاربردی خاص است. به عنوان مثال، در یک برنامه حسابداری خرده فروشیشما می توانید اشیایی را شامل کنید که وضعیت موجودی را پیگیری می کند، تعاملات با مشتریان را ردیابی می کند، کالاها را طبقه بندی می کند و غیره.

2. به عنوان یک رویکرد انعطاف پذیر برای پیاده سازی سیستم های مشتری/سرور. در این مورد مدل منطقیسیستم ها یک مدل کلاینت/سرور است که در آن کلاینت ها و سرورها به عنوان اشیاء توزیع شده که از طریق یک گذرگاه نرم افزار تعامل دارند، پیاده سازی می شوند. با این رویکرد، به راحتی می توان سیستم را جایگزین کرد، به عنوان مثال، یک سیستم دو سطحی با یک سیستم چند سطحی. در این حالت، نه سرور و نه مشتری را نمی توان در یک شیء واحد پیاده سازی کرد، بلکه می تواند از بسیاری از آبجکت های کوچک تشکیل شده باشد که هر کدام سرویس خاصی را ارائه می دهند.
نمونه ای از سیستمی که برای معماری شی توزیع شده مناسب است، سیستمی برای پردازش داده های ذخیره شده در پایگاه های داده مختلف است (شکل 11.10). در این مثال، هر پایگاه داده را می توان به عنوان یک شی با رابطی در نظر گرفت که دسترسی فقط خواندنی به داده ها را فراهم می کند. هر یک از اشیاء یکپارچه ساز با انواع خاصی از وابستگی های داده با جمع آوری اطلاعات از پایگاه های داده برای ردیابی آن وابستگی ها سر و کار دارد.

اشیاء ویژوالایزر با اشیاء یکپارچه ساز تعامل می کنند تا داده ها را به صورت گرافیکی ارائه کنند یا گزارش هایی را روی داده های تجزیه و تحلیل شده تولید کنند. راه های ارائه اطلاعات گرافیکی در فصل 15 مورد بحث قرار گرفته است.


برنج. 11.10. معماری سیستم پردازش داده های توزیع شده
برای این نوع برنامه، یک معماری شی توزیع شده به سه دلیل مناسب تر از معماری مشتری/سرور است.
1. در این سیستم ها (برخلاف، برای مثال، سیستم ATM) هیچ ارائه دهنده خدماتی وجود ندارد که تمام خدمات مدیریت داده بر روی آن متمرکز شود.

2. شما می توانید تعداد پایگاه های داده موجود را بدون ایجاد وقفه در سیستم افزایش دهید، زیرا هر پایگاه داده فقط یک شی است. این اشیا از یک رابط ساده پشتیبانی می کنند که دسترسی به داده ها را کنترل می کند. پایگاه داده های موجود را می توان بر روی ماشین های مختلف قرار داد.

3. با افزودن اشیاء یکپارچه ساز جدید، می توانید انواع جدیدی از وابستگی ها را بین داده ها ردیابی کنید.
نقطه ضعف اصلی معماری های شی توزیع شده این است که طراحی آنها نسبت به سیستم های کلاینت/سرور دشوارتر است. به نظر می رسد که سیستم های مشتری/سرور رویکرد طبیعی تری برای ساختن سیستم های توزیع شده ارائه می دهند. این نشان دهنده رابطه بین افرادی است که در آن برخی افراد از خدمات افراد دیگری که در ارائه خدمات خاص تخصص دارند استفاده می کنند. توسعه یک سیستم مطابق با معماری اشیاء توزیع شده بسیار دشوارتر است، زیرا صنعت نرم افزار هنوز تجربه کافی در طراحی و توسعه اشیاء در مقیاس بزرگ را جمع آوری نکرده است.

11.4. CORBA

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

که در در حال حاضردو استاندارد میان افزار اصلی برای پشتیبانی از محاسبات شی توزیع شده وجود دارد.
1. CORBA (معماری کارگزار درخواست شی مشترک - معماری کارگزاران درخواست برای اشیاء مشترک). این مجموعه ای از استانداردهای میان افزاری است که توسط OMG (گروه مدیریت اشیا) توسعه یافته است. OMG کنسرسیومی متشکل از تولیدکنندگان نرم افزار و سخت افزار، از جمله شرکت هایی مانند Sun، Hewlett-Packard و IBM است. استانداردهای CORBA یک رویکرد مشترک مستقل از ماشین را برای محاسبه اشیاء توزیع شده تعریف می کنند. توسط تولید کنندگان مختلفبسیاری از پیاده سازی های این استاندارد توسعه یافته است. استانداردهای CORBA توسط عامل پشتیبانی می شود سیستم یونیکسو سیستم عامل های مایکروسافت.

2. DCOM (Distributed Component Object Model - یک مدل شی از اجزای توزیع شده). DCOM استانداردی است که توسط مایکروسافت توسعه و پیاده سازی شده و در سیستم عامل های آن ادغام شده است. این مدل از محاسبات توزیع شده نسبت به CORBA تطبیق پذیری کمتری دارد و امکانات محدودتری برای تعاملات شبکه ارائه می دهد. DCOM در حال حاضر محدود به سیستم عامل های مایکروسافت است.
در اینجا تصمیم گرفتم به فناوری CORBA توجه کنم، زیرا همه کاره تر است. علاوه بر این، من معتقدم که احتمال دارد CORBA، DCOM و سایر فناوری‌ها، مانند RMI (Remote Method Invocation - فراخوانی روش از راه دور، فناوری ساخت برنامه‌های کاربردی توزیع‌شده در زبان جاوا)، به تدریج با یکدیگر همگرا شوند و این همگرایی بر اساس استانداردهای CORBA خواهد بود. بنابراین نیازی به استاندارد دیگری نیست. استانداردهای مختلف تنها مانعی در توسعه بیشتر خواهند بود.

استانداردهای CORBA توسط گروه OMG تعریف شده است که بیش از 500 شرکت را گرد هم می آورد که از توسعه شی گرا پشتیبانی می کنند. نقش OMG ایجاد استانداردهایی برای توسعه شی گرا است، نه ارائه پیاده سازی خاصی از آن استانداردها. این استانداردها به صورت رایگان در وب سایت OMG در دسترس هستند. این گروه نه تنها به استانداردهای CORBA توجه دارد، بلکه طیف گسترده ای از استانداردهای دیگر، از جمله زبان مدل سازی UML را نیز تعریف می کند.

نمایش برنامه های کاربردی توزیع شده در CORBA در شکل نشان داده شده است. 11.11. این یک نمودار ساده از معماری مدیریت شی است که از مقاله گرفته شده است. انتظار می رود یک برنامه کاربردی توزیع شده از اجزای زیر تشکیل شود.
1. اشیاء کاربردی که برای این محصول نرم افزاری ایجاد و توسعه یافته اند.

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

3. خدمات اصلی CORBA که از خدمات محاسباتی توزیع شده اولیه مانند دایرکتوری ها، مدیریت امنیت و غیره پشتیبانی می کند.

4. ابزارهای افقی CORBA، مانند رابط های کاربری، ابزارهای مدیریت سیستم و غیره. با ابزارهای افقی که در بسیاری از کاربردها مشترک است.


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

2. یک کارگزار درخواست شی (ORB) که درخواست ها را برای خدمات شیء مدیریت می کند. ORB اشیایی را که خدمات ارائه می دهند، تخصیص می دهد، آنها را برای دریافت درخواست ها آماده می کند، درخواست را به سرویس ارسال می کند و نتایج را به شی ای که درخواست را ارائه می دهد، برمی گرداند.

3. مجموعه ای از خدمات شی که خدمات اصلی هستند و در بسیاری از برنامه های کاربردی توزیع شده مورد نیاز هستند. به عنوان مثال می توان به خدمات دایرکتوری، خدمات تراکنش و خدمات نگهداری موقت شی اشاره کرد.

4. تجمیع اجزای مشترکبر پایه خدمات اصلی ساخته شده است. آنها می توانند هم عمودی باشند و هم ویژگی های یک منطقه خاص را منعکس کنند و هم اجزای جهانی افقی که در بسیاری از آنها استفاده می شود نرم افزارهای کاربردی. این مؤلفه ها در فصل 14 مورد بحث قرار می گیرند.
در مدل CORBA، یک شیء مانند یک شیء معمولی، ویژگی ها و خدمات را در بر می گیرد. با این حال، اشیاء CORBA هنوز باید شامل تعریف واسط های مختلفی باشد که توصیف می کنند ویژگی های جهانیو عملیات شی رابط های شی CORBA در استاندارد تعریف شده است زبان جهانیتوضیحات رابط های IDL اگر یک شی خدمات ارائه شده توسط اشیاء دیگر را درخواست کند، از طریق رابط IDL به آن خدمات دسترسی پیدا می کند. اشیاء CORBA دارای یک شناسه منحصر به فرد به نام مرجع شیء تعاملی (IOR) هستند. هنگامی که یک نهاد درخواست هایی را به سرویس ارائه شده توسط نهاد دیگری ارسال می کند، از شناسه IOR استفاده می شود.

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

روی انجیر شکل 11-12 نشان می دهد که چگونه اشیاء ol و o2 از طریق واسطه درخواست شی با هم ارتباط برقرار می کنند. تماس گیرنده (ol) با یک IDL خرد مرتبط است که رابط شیئی را که سرویس را ارائه می دهد، تعریف می کند. سازنده شی ol، هنگام درخواست سرویس، فراخوانی ها را به قسمتی از اجرای شیء خود تزریق می کند. IDL یک برنامه افزودنی از C++ است، بنابراین اگر به زبان های C++، C یا جاوا برنامه نویسی می کنید، دسترسی به خرد آسان است. ترجمه توضیحات رابط یک شی به IDL برای زبان های دیگر مانند Ada یا COBOL نیز امکان پذیر است. اما در این موارد به پشتیبانی ابزاری مناسب نیاز است.

برنج. 11.12. ارتباط شیء از طریق کارگزار درخواست شی
شیئی که سرویس را ارائه می دهد با یک اسکلت IDL مرتبط است که رابط را به اجرای سرویس متصل می کند. به عبارت دیگر، هنگامی که یک سرویس از طریق یک رابط فراخوانی می شود، چارچوب IDL بدون توجه به زبانی که در پیاده سازی استفاده شده است، تماس را به سرویس ترجمه می کند. پس از تکمیل یک روش یا روش، اسکلت نتایج را به IDL ترجمه می کند تا در دسترس تماس گیرنده باشد. اگر یک شی به طور همزمان خدماتی را به اشیاء دیگر ارائه دهد یا از خدماتی استفاده کند که در جای دیگر ارائه شده است، به هر دو اسکلت IDL و خرد IDL نیاز دارد. مورد دوم برای تمام اشیاء مورد استفاده ضروری است.

یک واسطه درخواست شی معمولاً نه به عنوان فرآیندهای جداگانه، بلکه به عنوان یک چارچوب (به فصل 14 مراجعه کنید) که با اجرای شی مرتبط است، پیاده سازی می شود. بنابراین، در یک سیستم توزیع‌شده، هر کامپیوتری که اشیاء را اجرا می‌کند، باید واسطه درخواست شی مخصوص به خود را داشته باشد که همه تماس‌های شی محلی را مدیریت می‌کند. اما اگر درخواستی به سرویسی ارائه شود که توسط یک نهاد راه دور ارائه می شود، تعامل بین کارگزاری لازم است.

این وضعیت در شکل نشان داده شده است. 11.13. در این مثال، اگر شی ol یا o2 درخواست هایی را به خدمات ارائه شده توسط اشیاء o3 یا o4 ارسال می کند، در این صورت تعامل کارگزاران مرتبط با این اشیاء ضروری است. استانداردهای CORBA از ارتباط کارگزار به کارگزار پشتیبانی می کند، که به کارگزاران اجازه می دهد به توضیحات رابط IDL دسترسی داشته باشند و استاندارد پروتکل بین ORB عمومی (GIOP) OMG را برای ارتباطات کارگزار ارائه می دهد. این پروتکل پیام‌های استانداردی را تعریف می‌کند که کارگزاران می‌توانند هنگام برقراری تماس با شی از راه دور و ارسال اطلاعات تبادل کنند. این پروتکل همراه با پروتکل اینترنت سطح پایین TCP/IP، به کارگزاران اجازه می دهد تا از طریق اینترنت با یکدیگر ارتباط برقرار کنند.

اولین گونه های CORBA در دهه 1980 توسعه یافتند. نسخه های اولیه CORBA فقط در مورد حمایت از اشیاء توزیع شده بود. با این حال، با گذشت زمان، استانداردها تکامل یافته، پیشرفته تر شدند. استانداردهای CORBA مانند مکانیسم هایی برای برقراری ارتباط با اشیاء توزیع شده، اکنون برخی را تعریف می کنند خدمات استاندارد، که می تواند برای پشتیبانی از برنامه های شی گرا استفاده شود.


برنج. 11.13. تعامل بین کارگزاران درخواست شی
خدمات CORBA ابزارهایی هستند که در بسیاری از سیستم های توزیع شده مورد نیاز هستند. این استانداردها تقریباً 15 سرویس (خدمات) مشترک را تعریف می کنند. در اینجا به برخی از آنها اشاره می کنیم.
1. یک سرویس نامگذاری که به اشیا اجازه می دهد اشیاء دیگر را در شبکه پیدا کنند و به آنها ارجاع دهند. سرویس نام یک سرویس دایرکتوری است که نام هایی را به اشیا اختصاص می دهد. اشیاء می توانند از این سرویس برای جستجوی IOR اشیاء دیگر در صورت نیاز استفاده کنند.

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

3. یک سرویس تراکنش که از تراکنش های اولیه و بازگشت در صورت بروز خطا یا شکست پشتیبانی می کند. این سرویس یک امکان تحمل خطا است (به فصل 18 مراجعه کنید) که در صورت بروز خطا در حین عملیات به روز رسانی، بازیابی را فراهم می کند. اگر اقدامات برای به روز رسانی یک شی منجر به خطا یا خرابی سیستم شود، شی داده شدههمیشه می توانید به حالت قبل از شروع به روز رسانی برگردید.
اعتقاد بر این است که استانداردهای CORBA باید شامل تعاریف واسط برای طیف وسیعی از مؤلفه‌ها باشد که می‌توانند در ساخت برنامه‌های توزیع شده مورد استفاده قرار گیرند. این اجزا می توانند عمودی یا افقی باشند. اجزای عمودی به طور خاص برای برنامه های کاربردی خاص. همانطور که قبلاً اشاره شد، توسعه تعاریف برای این مؤلفه ها شامل متخصصان بسیاری از زمینه های مختلف فعالیت می شود. اجزای افقی عمومی هستند، مانند اجزای UI.

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

سیستم های توزیع شده دارای ویژگی های زیر هستند: استفاده از منابع، باز بودن، همزمانی، مقیاس پذیری، تحمل خطا و شفافیت.

سیستم های مشتری/سرور توزیع شده اند. چنین سیستم هایی به عنوان مجموعه ای از خدمات ارائه شده توسط سرور به فرآیندهای مشتری مدل سازی می شوند.

در سیستم کلاینت/سرور، رابط کاربری در سمت کلاینت قرار دارد و مدیریت داده ها همیشه بر روی یک سرور اشتراکی نگهداری می شود. توابع برنامه را می توان بر روی یک کامپیوتر مشتری یا روی سرور پیاده سازی کرد.

در معماری اشیاء توزیع شده، هیچ تمایزی بین کلاینت و سرور وجود ندارد. اشیا خدمات اولیه ای را ارائه می دهند که سایر اشیاء می توانند آنها را فراخوانی کنند. همین رویکرد را می توان در پیاده سازی سیستم های مشتری/سرور استفاده کرد.

سیستم های اشیاء توزیع شده باید دارای میان افزار طراحی شده باشند تا تعاملات بین اشیاء را مدیریت کند و اشیا را از سیستم اضافه یا حذف کند. از نظر مفهومی، میان افزار را می توان به عنوان یک گذرگاه نرم افزاری در نظر گرفت که اشیا به آن متصل می شوند.

استانداردهای CORBA مجموعه ای از استانداردها برای میان افزار است که از معماری شی توزیع شده پشتیبانی می کند. اینها شامل مدل شی، کارگزار درخواست شی و تعاریف سرویس مشترک است. در حال حاضر چندین پیاده سازی از استانداردهای CORBA وجود دارد.
تمرینات
11.1. توضیح دهید که چرا سیستم های توزیع شده همیشه مقیاس پذیرتر از سیستم های متمرکز هستند. محدودیت احتمالی مقیاس پذیری سیستم نرم افزار چقدر است؟

11.2. تفاوت اصلی بین مدل های ضخیم و نازک کلاینت در توسعه کلاینت/سرور چیست؟ توضیح دهید چرا استفاده از جاوا به عنوان زبان پیاده سازی، تفاوت های بین این مدل ها را هموار می کند؟

11.3. بر اساس مدل کاربردی نشان داده شده در شکل. در شکل 11.4، مشکلات بالقوه ای را که ممکن است هنگام تبدیل یک سیستم مراقبت بهداشتی مرکزی دهه 1980 به یک سیستم مشتری/سرور ایجاد شود، در نظر بگیرید.

11.4. سیستم های توزیع شده بر اساس مدل مشتری/سرور از دهه 1980 توسعه یافته اند، اما اخیراً چنین سیستم هایی مبتنی بر اشیاء توزیع شده پیاده سازی شده اند. سه دلیل برای این اتفاق بیاورید.

11.5. توضیح دهید که چرا استفاده از اشیاء توزیع شده در ارتباط با یک کارگزار درخواست شی، پیاده سازی سیستم های مشتری/سرور مقیاس پذیر را آسان تر می کند. پاسخ خود را با یک مثال توضیح دهید.

11.6. چگونه از IDL برای پشتیبانی از ارتباط بین اشیاء پیاده سازی شده در زبان های برنامه نویسی مختلف استفاده می شود؟ توضیح دهید که چرا این رویکرد می تواند در صورت وجود تفاوت های فاحش بین زبان های مورد استفاده برای پیاده سازی اشیاء، مشکلات عملکردی ایجاد کند.

11.7. یک کارگزار درخواست شی چه امکانات اساسی باید ارائه دهد؟

11.8. می توان نشان داد که توسعه استانداردهای CORBA برای اجزای افقی و عمودی رقابت را محدود می کند. اگر آنها قبلا ایجاد و اقتباس شده باشند، این مانع از توسعه مؤلفه های بهتر توسط شرکت های کوچکتر می شود. در مورد نقش استانداردسازی در حفظ یا محدود کردن رقابت در بازار نرم افزار بحث کنید.

(مواد از سایت http://se.math.spbu.ru)

معرفی.

در حال حاضر، تقریبا تمام سیستم های نرم افزاری بزرگ توزیع شده اند. سیستم توزیع شده- سیستمی که در آن پردازش اطلاعات روی یک کامپیوتر متمرکز نیست، بلکه بین چندین کامپیوتر توزیع می شود. هنگام طراحی سیستم های توزیع شده، که اشتراکات زیادی با طراحی نرم افزار به طور کلی دارد، برخی ویژگی های خاص هنوز باید در نظر گرفته شود.

شش ویژگی اصلی سیستم های توزیع شده وجود دارد.

1. به اشتراک گذاری منابع سیستم های توزیع شده امکان به اشتراک گذاری منابع سخت افزاری (هارد دیسک، چاپگرها) و نرم افزاری (فایل ها، کامپایلرها) را فراهم می کنند.
2. باز بودن.این توانایی گسترش سیستم با افزودن منابع جدید است.
3. موازی سازی.در سیستم های توزیع شده، چندین فرآیند می توانند به طور همزمان بر روی رایانه های مختلف در شبکه اجرا شوند. این فرآیندها می توانند در حین اجرا با هم تعامل داشته باشند.
4. مقیاس پذیری . زیر مقیاس پذیریتوانایی اضافه کردن خواص و روش های جدید درک شده است.
5. تحمل خطا. وجود چندین کامپیوتر امکان تکرار اطلاعات و مقاومت در برابر برخی از خطاهای سخت افزاری و نرم افزاری را فراهم می کند. سیستم های توزیع شده می توانند عملکرد جزئی را در صورت بروز خطا حفظ کنند. خرابی کامل سیستم فقط با خطاهای شبکه رخ می دهد.
6. شفافیت.به کاربران دسترسی کامل به منابع موجود در سیستم داده می شود، در عین حال اطلاعات مربوط به توزیع منابع در سیستم از آنها پنهان می شود.

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

1. پیچیدگی. درک و ارزیابی خصوصیات سیستم های توزیع شده به طور کلی بسیار دشوارتر است، طراحی، آزمایش و نگهداری آنها دشوارتر است. همچنین عملکرد سیستم به سرعت شبکه بستگی دارد و نه تک تک پردازنده ها. تخصیص مجدد منابع می تواند به طور قابل توجهی سرعت سیستم را تغییر دهد.
2. ایمنی. معمولاً می توان به سیستم از چندین ماشین مختلف دسترسی داشت، پیام های موجود در شبکه را می توان مشاهده و رهگیری کرد. بنابراین، حفظ امنیت در یک سیستم توزیع شده بسیار دشوارتر است.
3. قابلیت کنترل. این سیستم ممکن است از انواع مختلفی از رایانه ها تشکیل شده باشد که نسخه های مختلف سیستم عامل را می توان روی آنها نصب کرد. خطاهای یک ماشین می تواند به روش های غیرقابل پیش بینی در ماشین های دیگر منتشر شود.
4. غیر قابل پیش بینی بودن . واکنش سیستم های توزیع شده به برخی رویدادها غیرقابل پیش بینی است و به بار کامل سیستم، سازماندهی آن و بار شبکه بستگی دارد. از آنجایی که این پارامترها می توانند به طور مداوم تغییر کنند، بنابراین، زمان پاسخ به درخواست ممکن است به طور قابل توجهی با زمان متفاوت باشد.

از این کاستی ها، می توانید متوجه شوید که هنگام طراحی سیستم های توزیع شده، تعدادی از مشکلات به وجود می آید که توسعه دهندگان باید آنها را در نظر بگیرند.

1. شناسایی منابع . منابع در سیستم های توزیع شده در رایانه های مختلف قرار دارند، بنابراین سیستم نامگذاری منابع باید به گونه ای طراحی شود که کاربران بتوانند به راحتی منابع مورد نیاز خود را باز کرده و به آنها مراجعه کنند. یک مثال سیستم URL (Uniform Resource Locator) است که نام صفحات وب را مشخص می کند.
2. ارتباط. کارایی جهانی اینترنت و اجرای کارآمد پروتکل‌های TCP/IP در اینترنت برای اکثر سیستم‌های توزیع‌شده، کارآمدترین راه برای برقراری ارتباط بین رایانه‌ها را نشان می‌دهد. با این حال، در برخی موارد که عملکرد یا قابلیت اطمینان خاصی مورد نیاز است، ممکن است از ابزارهای تخصصی استفاده شود.
3. کیفیت خدمات سیستم . این تنظیم عملکرد، سلامت و قابلیت اطمینان را منعکس می کند. کیفیت خدمات تحت تأثیر عوامل متعددی قرار می گیرد: توزیع فرآیندها، منابع، سخت افزار و سازگاری سیستم.
4. معماری نرم افزار . معماری نرم افزار توزیع توابع سیستم به اجزای سیستم و همچنین توزیع این اجزاء به پردازنده ها را توصیف می کند. هنگامی که صحبت از حفظ کیفیت بالای خدمات سیستم می شود، انتخاب معماری مناسب بسیار مهم است.

وظیفه توسعه دهندگان سیستم های توزیع شده طراحی نرم افزار و سخت افزار برای ارائه تمام ویژگی های لازم یک سیستم توزیع شده است. و این مستلزم دانستن مزایا و معایب معماری های مختلف سیستم های توزیع شده است. سه نوع معماری سیستم های توزیع شده وجود دارد.

1. معماری کلاینت/سرور . در این مدل، سیستم را می توان مجموعه ای از خدمات ارائه شده توسط سرورها به مشتریان در نظر گرفت. در چنین سیستم هایی، سرورها و کلاینت ها به طور قابل توجهی با یکدیگر تفاوت دارند.
2. معماری سه لایه . در این مدل، سرور نه به طور مستقیم، بلکه از طریق یک سرور منطق تجاری به مشتریان خدمات ارائه می دهد.

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

1. معماری اشیاء توزیع شده . در این حالت هیچ تفاوتی بین سرورها و کلاینت ها وجود ندارد و سیستم را می توان مجموعه ای از اشیاء تعاملی در نظر گرفت که مکان آنها واقعاً مهم نیست. هیچ تفاوتی بین ارائه دهنده خدمات و کاربران آنها وجود ندارد.

این معماری امروزه بسیار مورد استفاده قرار می گیرد و همچنین نامیده می شود معماری های وب سرویسوب سرویس برنامه ای است که از طریق اینترنت قابل دسترسی است و خدماتی را ارائه می دهد که شکل آنها به ارائه دهنده (از فرمت داده جهانی - XML ​​استفاده می شود) و پلت فرم عملیات بستگی ندارد. که در زمان داده شدهسه فناوری مختلف وجود دارد که از مفهوم توزیع شده پشتیبانی می کنند سیستم های شی. اینها فناوری های EJB، CORBA و DCOM هستند.

ابتدا چند کلمه در مورد اینکه XML به طور کلی چیست. XML یک قالب داده عمومی است که برای ارائه خدمات وب استفاده می شود. خدمات وب بر اساس استانداردها و پروتکل های باز است: SOAP، UDDI و WSDL.

1. صابون( پروتکل دسترسی به اشیاء ساده که توسط W3C توسعه یافته است، قالبی را برای درخواست ها به سرویس های وب تعریف می کند. پیام‌های بین یک وب سرویس و کاربر آن در پاکت‌های به اصطلاح SOAP (پاکت‌های SOAP، گاهی اوقات به آنها پاکت XML نیز گفته می‌شود) بسته‌بندی می‌شوند. خود پیام می تواند شامل یک درخواست برای انجام برخی عمل یا یک پاسخ باشد - نتیجه انجام این عمل.
2. WSDL (زبان شرح خدمات وب).رابط وب سرویس در اسناد WSDL توضیح داده شده است (و WSDL زیرمجموعه ای از XML است). قبل از استقرار یک سرویس، توسعه دهنده توضیحات آن را در WSDL می نویسد، آدرس سرویس وب، پروتکل های پشتیبانی شده، لیست عملیات مجاز، فرمت های درخواست و پاسخ را مشخص می کند.
3. UDDI (توصیف جهانی، کشف و ادغام) -پروتکل جستجوی خدمات وب در اینترنت ( http://www.uddi.org/). نشان دهنده یک ثبت کسب و کار است که ارائه دهندگان خدمات وب خدمات را ثبت می کنند و توسعه دهندگان آن را پیدا می کنند خدمات لازمدر برنامه های خود قرار دهید.

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

اگر هدف وب سرویس ها تسهیل ارتباط بین برنامه ها باشد، وب معنایی برای حل موارد بسیار بیشتر طراحی شده است مشکل دشوار- استفاده از مکانیسم های فراداده برای افزایش کارایی ارزش اطلاعاتی که در وب یافت می شوند. شما می توانید این کار را با کنار گذاشتن رویکرد سند گرا به نفع شی گرا انجام دهید.

کتابشناسی - فهرست کتب

1. سامرویلI. مهندسی نرم افزار.
2. Dranica A. Java vs. NET. - "کامپیوتررا"، شماره 516.
3. منابع اینترنتی

بر اساس محاسبات چند خط لوله قابل تنظیم مجدد محیط های L-Net

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

این راه‌حل‌ها استفاده کارآمد از منابع پایه‌های اضافی، فنی و نرم‌افزاری را فراهم نمی‌کنند، که هم بر تحمل خطا و هم مقیاس‌پذیری چنین راه‌حل‌هایی تأثیر منفی می‌گذارد. اگر معماری شبکه نقض شود، امکان پیکربندی مجدد پویا فرآیندهای پردازش اطلاعات و انتقال جریان داده (هم کنترل و هم اطلاعات) وجود ندارد. استفاده از میکروکنترلرهای خاص، استفاده از DCS / SCADA توسعه و پشتیبانی سیستم ها، گسترش عملکرد آنها را پیچیده می کند.

معماری سیستم کنترل توزیع شده

معماری معمولی تعمیم یافته یک سیستم کنترل توزیع شده (DCS) شامل سه سطح مرتبط سلسله مراتبی است: سطح اپراتور، سطح کنترل و سطح ورودی-خروجی (نگاه کنید به شکل 1).

وظیفه اصلی سطح اپراتور ارائه یک رابط انسان و ماشین (HMI) برای فعال کردن پیکربندی و کنترل کل سیستم است. سطح کنترل مسئول دریافت و پردازش داده ها از حسگرها، انتقال داده ها به سطح اپراتور و ایجاد اقدامات کنترلی برای محرک ها است. سطح ورودی-خروجی نشان دهنده حسگرها و محرک هایی است که مستقیماً به شی کنترل متصل هستند.

وظیفه نرم افزار، در چارچوب معماری تعمیم یافته DCS، اطمینان از عملکرد سطح اپراتور و ارتباط آن با سطح کنترل سیستم است. بنابراین، سطح اساسی در طراحی نرم افزار و حل مسائل مربوط به تعامل آن با سخت افزار، سطح اپراتور است. نرم افزار باید از منابع سخت افزاری موجود سیستم بیشترین استفاده را ببرد و در عین حال تا حد امکان مستقل از معماری سخت افزار داخلی باشد.

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

الزامات DCS

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

مروری بر معماری های DCS

برای بررسی معماری های DCS، Siemens SIMATIC PCS 7 DCS به عنوان یکی از محبوب ترین ها در بازار و RTS S3 به عنوان DCS پیاده سازی شده بر اساس QNX RTOS انتخاب شدند.

زیمنس SIMATIC PCS 7

معماری سیستم تمام خصوصیات معماری DCS تعمیم یافته را دارد. رایانه های مبتنی بر معماری پردازنده x86 با سیستم عامل ویندوز و بسته WinCC زیمنس که HMI را ارائه می دهند به عنوان ایستگاه های اپراتور عمل می کنند. سرورهایی با پایگاه داده وجود دارد. ایستگاه های اپراتور، ایستگاه های مهندسی و سرورها توسط یک شبکه محلی مبتنی بر اترنت به هم متصل می شوند. سطح اپراتور به سطح مدیریت شبکه اترنت صنعتی اضافی متصل است. در سطح کنترل قابل برنامه ریزی هستند کنترل کننده های منطقی(PLC) با امکان افزونگی به دلیل تکراری بودن عملکرد. امکان اتصال به سیستم ها و شبکه های خارجی و سازماندهی وجود دارد دسترسی از راه دوربه سیستم

RTS S3

این معماری به طور مشابه از سطوح ساختار DCS تعمیم یافته تشکیل شده است. ایستگاه های اپراتور بر اساس پلت فرم سخت افزاری مشابه SIMATIC DCS هستند، اما می توانند تحت هر دو سیستم عامل ویندوز و لینوکس اجرا شوند. ایستگاه های مهندسی با اتاق اپراتور ترکیب می شوند. این سیستم یک محیط توسعه برنامه یکپارچه را فراهم می کند. یک شبکه اترنت با استفاده از پشته پروتکل TCP/IP، گره های درون لایه حامل و خود لایه حامل را به صفحه کنترل متصل می کند. در سطح کنترل، کامپیوترهای صنعتی در حال اجرا سیستم عامل QNX با پایگاه داده خود و امکان افزونگی با کپی کردن عملکرد گره وجود دارد.

معایب سیستم های توصیف شده

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

ویژگی ها و ویژگی های عملکردی سیستم L-Net

هنگام توسعه سیستم L-Net، وظیفه ایجاد یک سیستم کنترلی بود که دارای ویژگی های زیر باشد:

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

برای ساختن یک سیستم با ویژگی هایی که در بالا توضیح داده شد، یک سیستم عامل مورد نیاز است که در درجه اول برای ایجاد سیستم های کنترل و سیستم های تعبیه شده در نظر گرفته شده است. تجزیه و تحلیل سیستم عامل های موجود نشان داد که مناسب ترین سیستم عاملیک سیستم عامل QNX 6 (نوترینو) است که دارای قابلیت تخصیص منابع و شبکه بسیار کارآمد است. وسیع قابلیت های شبکهارائه شده توسط پروتکل شبکه Qnet. این مشکل قابلیت اطمینان و تعادل بار دینامیکی کانال های ارتباطی را حل می کند، اما مشکل تحمل خطای سیستم را به طور کلی حل نمی کند. در نتیجه، یک سیستم کنترل نوآورانه بر اساس یک محیط محاسباتی چند خط لوله توزیع شده، قابل تنظیم مجدد توسعه یافت. سیستم توسعه‌یافته دارای معماری نظیر به نظیر است که شامل سه بلوک منطقی است: یک بلوک ورودی-خروجی، یک بلوک از سوئیچ‌ها. همه منظورهو یک بلوک از محیط محاسباتی قابل تنظیم مجدد (RCS) (شکل 2 را ببینید).

مزایای اصلی این معماری عبارتند از:

• نوع همتا
• عدم تمرکز
• مقیاس پذیری
• توزیع فضایی

ویژگی های کاربردی این معماری:

• لوله گذاری داده ها
• افزونگی سخت افزاری
• توزیع بار
• پیکربندی مجدد در حین پرواز

در سطح اول معماری، یک بلوک ورودی-خروجی (I/O) وجود دارد که شامل: گره های I/O، سوئیچ گره I/O، رابط I/O، حسگرها و محرک ها می باشد. بلوک مسئول مکانیسم های اساسی برای ایجاد اقدامات کنترلی بر اساس داده های حسگرهای محلی و داده های دریافتی از سطوح دیگر سیستم کنترل است. وظایف محول شده بین گره های I/O سالم بر اساس عملکرد نسبی فعلی آنها یا به صورت دستی توسط اپراتور توزیع می شود. حسگرها و محرک ها از طریق یک گذرگاه به تمام گره های ورودی/خروجی در بلوک متصل می شوند، که به هر گره اجازه می دهد هر سنسوری را بازجویی کند یا بر هر محرکی تأثیر بگذارد. سوئیچ گره ورودی/خروجی ارتباط بین تمام گره های ورودی/خروجی را برای تبادل داده بین آنها و سایر سطوح معماری سیستم برای به دست آوردن داده های کنترل و اطلاعات فراهم می کند. با قابلیت های سخت افزاری مناسب، گره ها به طور مستقیم با یکدیگر و با گره ها و سوئیچ ها در سطوح دیگر سیستم ارتباط برقرار می کنند که باعث کاهش زمان پاسخگویی در شبکه می شود. اتصال مستقیم بین گره ها و حجم کاری مشخصی از گره ها در حالت فعلی عملکرد بلوک I / O امکان سازماندهی محاسبات خط لوله لازم برای عملکرد این بلوک را بدون استفاده از توان محاسباتی خارجی سیستم کنترل در بلوک فراهم می کند. RSS)، که استفاده موثر از منابع رایگان ارائه شده برای گره های بلوک ورودی/خروجی افزونگی را در زمان خرابی ممکن می سازد.

بلوک سوئیچ هدف عمومی، واقع در سطح دوم معماری، خطوط ارتباطی بین بلوک های ورودی / خروجی و RCS و سیستم های خارجی را سازماندهی می کند. هر سوئیچ می تواند گره ها و سوئیچ های مختلف را در کل سیستم کنترل به هم متصل کند. تعداد خطوط ارتباطی با قابلیت های سخت افزاری گره ها و سوئیچ های موجود در بلوک ها تعیین می شود. از آنجایی که شبکه Qnet توزیع پویا جریان های داده را امکان پذیر می کند، مقیاس بندی این بلوک انجام می شود اتصال سادهدستگاه های جدید است و نیازی به پیکربندی ندارد و اگر یکی از سوئیچ ها از کار بیفتد، انتقال داده بین گره ها قطع نمی شود اگر سوییچ دیگر اتصال مشابهی را بین گره ها ایجاد کند یا آنها مستقیماً متصل شوند. در عین حال، لازم است از پهنای باند کافی شبکه مورد نیاز برای پشتیبان گیری از یک سوئیچ ناموفق مراقبت شود.

بلوک شبکه کامپیوتری قابل تنظیم مجدد (RCN) که در سطح سوم معماری قرار دارد، سیستم کنترل توان محاسباتی بالایی را برای حل مشکلات پیچیده پردازش اطلاعات، تصمیم گیری، تشخیص و غیره فراهم می کند. بلوک مسئول اولیه سازی کل سیستم کنترل است: بررسی عملکرد سوئیچ ها و گره ها، یکپارچگی شبکه، ساخت نمودارهای شبکه کل سیستم، تنظیم پارامترهای شروع برای عملکرد بلوک های I / O. گره های این بلوک هم داده های خود و هم داده های بلوک های I/O را بایگانی می کنند. هر گره از این بلوک می تواند نقش یک ماشین اپراتور را ایفا کند که برای نظارت بر عملکرد سیستم طراحی شده است و برنامه های کاری این گره و تمام گره های سیستم را تنظیم می کند و در صورت درخواست پیکربندی مجدد را انجام می دهد.

توزیع بار

یکی از وظایف اصلی سیستم L-Net توزیع بار محاسباتی بر روی گره های شبکه است. راه حل این مشکل بر اساس ساخت خطوط لوله محاسباتی است. برای ایجاد یک خط لوله محاسباتی، یک نمودار وظیفه از ابتدا ساخته شده است - طرحی برای تبادل جریان های داده از منبع به گیرنده. حسگرها به عنوان منبع و عملگرها به عنوان گیرنده عمل می کنند. خط لوله محاسباتی خود نقشه‌برداری از نمودار وظیفه (نگاه کنید به شکل 3) بر روی نمودار شبکه کامپیوتری (نگاه کنید به شکل 4) است، با در نظر گرفتن الزامات وظیفه برای منابع محاسباتی سیستم و وضعیت فعلی آن.

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

تحمل خطا

مشکل اصلی عملکرد چنین سیستمی، اختلال کامل در عملکرد خطوط لوله محاسباتی در صورت خرابی هر گره این خط لوله یا در صورت اختلال در انتقال داده بین آنها است. ابزار اصلی پروتکل Qnet به بازیابی پیوندهای بین گره ها در صورت قطع جزئی آنها به دلیل خطوط پشتیبان ارائه شده توسط معماری، می رسد. سیستم L-Net مشکل بازیابی عملکرد را در صورت خرابی کامل میزبان سیستم محاسباتی با پیکربندی مجدد پویا خط لوله محاسباتی حل می کند. استفاده از منابع کاری برای جایگزینی یک بلوک بد این سیستم سه سناریو بازیابی (پیکربندی مجدد) را ارائه می دهد که از نظر زمان پاسخ به شکست، زمان بازیابی و منابع سخت افزاری استفاده شده متفاوت است: در صورت شکست، با آمادگی غیرفعال، با آمادگی فعال.

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

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

نتیجه

سیستم L-Net توسعه یافته، در مقابل آنالوگ های موجودشامل استفاده از طیف گسترده ای از ویژگی های سخت افزاری گره های DCS با سازگاری کامل نرم افزاری آنها می شود. هنگام اجرای گره ها تحت کنترل یک سیستم عامل (QNX Neutrino)، می توان آنها را بر روی معماری های مختلف پردازنده (x86، ARM، MIPS و غیره) با مجموعه های متنوعی از رابط ها و تجهیزات جانبی ساخت. پیاده سازی گره ها در قالب رایانه های شخصی رومیزی، رایانه های شخصی صنعتی، رایانه های شخصی پوشیدنی و رایانه های تک بردی امکان پذیر است. تمام اجزای مجموعه نرم افزاری DCS توسعه یافته را می توان بر روی هر یک از گره های آن با سیستم عامل QNX اجرا کرد، در حالی که امکان استفاده از گره ها با سیستم عامل متفاوت وجود دارد. این رویکرد استفاده از هر گره را برای حل مشکلات هم سطح اپراتور و هم در سطح کنترل ممکن می سازد. بنابراین، یک سیستم انعطاف پذیر از تعامل بین همتایان بدون سلسله مراتب سفت و سخت از سطوح ذاتی در معماری تعمیم یافته DCS و سیستم هایی که از این معماری به عنوان پایه استفاده می کنند وجود دارد. شبکه های همتا به همتا فرآیند استقرار، عملیات، مقیاس بندی و اشکال زدایی سیستم را ساده می کند.

برای تحقق پتانسیل محاسباتی سخت افزار اضافی در سیستم توسعه یافته، الگوریتم های پیکربندی پویا و پیکربندی مجدد بر اساس پروتکل و نرم افزار شبکه Qnet پیشنهاد شده است. شبکه های L-Net. الگوریتم پیکربندی پویا مبتنی بر توزیع بار محاسباتی در تمام گره‌ها با خط لوله کردن و موازی کردن وظایف و متعادل کردن پویا بار در کانال‌های انتقال داده بین گره‌ها است. الگوریتم پیکربندی مجدد سیستم، بسته به سخت افزار موجود، اولویت ها و وظایف محول شده به سیستم، وجود سه سناریو برای بازیابی عملکرد در صورت خرابی را فرض می کند: در صورت شکست، با آمادگی غیرفعال (تخصیص منابع) و با آمادگی فعال (استفاده از منابع). . الگوریتم‌های پیکربندی پویا و پیکربندی مجدد به شما امکان می‌دهند با توجه به ذخایر سخت‌افزاری موجود در سیستم، عملکرد و قابلیت اطمینان را افزایش دهید.

مزیت مهم سیستم حداکثر شفافیت فناوری های سخت افزاری و نرم افزاری به کار رفته در آن است که امکان ساده سازی جدی تعمیر و نگهداری فنی سیستم و توسعه ماژول های جدید را برای آن فراهم می کند.

نتیجه

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

1. http://kazanets.narod.ru/DCSIntro.htm.
2. http://kazanets.narod.ru/PCS7Overview.htm.
3. http://www.rts.ua/rus/news/678/0/409.
4. Zyl S. QNX Momentics: Application Basics. - سنت پترزبورگ: BHV-Petersburg، 2005.
5. Krten R. مقدمه ای بر نوترینو QNX. راهنمای توسعه برنامه های کاربردی بلادرنگ. - سنت پترزبورگ: BHV-Petersburg، 2011.

کلید واژه ها:سیستم کنترل توزیع شده، پشتیبانی اطلاعاتسیستم های کنترل، سیستم های قابل تنظیم مجدد توزیع شده.

معماری یک سیستم کنترل توزیع شده بر اساس محیط محاسباتی چند خط لوله قابل تنظیم مجدد L-Net

سرگئی یو. پوتومسکی، استادیار دانشگاه تحقیقات ملی "مدرسه عالی اقتصاد".

نیکیتا A. Poloyko، دانشجوی سال پنجم دانشگاه ملی تحقیقات "مدرسه عالی اقتصاد". دستیار مطالعه برنامه نویس زمینه آموزشی: "کنترل و انفورماتیک در سیستم های فنی".

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

کلید واژه ها:سیستم کنترل توزیع شده، پشتیبانی از نرم افزار سیستم، قابل تنظیم مجدد توزیع شده.

در تماس با

سیستم های چند کامپیوتری ناهمگن

بیشترین تعداد سیستم های توزیع شده موجود در حال حاضر بر اساس طرح سیستم های چند رایانه ای ناهمگن ساخته شده است. این بدان معنی است که رایانه هایی که بخشی از این سیستم هستند می توانند بسیار متنوع باشند، به عنوان مثال، از نظر نوع پردازنده، اندازه حافظه و عملکرد کانال I/O. در عمل، نقش برخی از این کامپیوترها را می توان توسط سیستم های موازی با کارایی بالا، به عنوان مثال، چند پردازنده یا چند کامپیوتر همگن انجام داد.

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

نمونه ای از ناهمگونی ایجاد سیستم های چند کامپیوتری بزرگ با استفاده از شبکه های موجودو کانال ها بنابراین، برای مثال، وجود سیستم‌های توزیع‌شده دانشگاهی، متشکل از شبکه‌های محلی دانشکده‌های مختلف، که توسط کانال‌های پرسرعت به هم متصل شده‌اند، چیز غیرعادی نیست. که در سیستم های جهانیایستگاه های مختلف به نوبه خود می توانند توسط شبکه های عمومی متصل شوند، مانند خدمات شبکه ارائه شده توسط اپراتورهای تجاری، مانند SMDSیا رله فریم.

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

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

اولین و اساسی ترین معماری توزیع شده، «مشتری-سرور» است که در آن یکی از طرفین (مشتری) با ارسال درخواستی به طرف دیگر (سرور) مبادله داده ها را آغاز می کند. سرور درخواست را پردازش می کند و در صورت لزوم، پاسخی را برای مشتری ارسال می کند (شکل 2.7).

برنج. 2.7. مدل تعامل مشتری و سرور

تعامل در مدل کلاینت-سرور می تواند همزمان باشد، زمانی که کلاینت منتظر می ماند تا سرور پردازش درخواست خود را کامل کند، یا ناهمزمان، که در آن کلاینت درخواستی را به سرور ارسال می کند و بدون منتظر ماندن برای پاسخ سرور به اجرای آن ادامه می دهد. مدل کلاینت و سرور می تواند به عنوان مبنایی برای توصیف تعاملات مختلف استفاده شود. تعامل اجزای نرم افزار را در نظر بگیرید که یک سیستم توزیع شده را تشکیل می دهد.

برنج. 2.8. اعمال لایه های منطقی

برخی را در نظر بگیرید نرم افزار معمولی، که مطابق با مفاهیم مدرن، می تواند به سطوح منطقی زیر تقسیم شود (شکل 2.8): رابط کاربر (UI)، منطق برنامه (LP) و دسترسی به داده (DD) کار با پایگاه داده (DB). کاربر سیستم از طریق رابط کاربری با آن تعامل دارد، پایگاه داده داده های توصیفی را ذخیره می کند موضوعبرنامه، و لایه منطق برنامه تمام الگوریتم های مربوط به حوزه موضوعی را پیاده سازی می کند.

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

برنج. 2.9. معماری دو لایه

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

توسعه معماری مشتری-سرور است معماری سه لایه، که در آن رابط کاربری، منطق برنامه و دسترسی به داده ها به اجزای مستقل سیستم که می توانند بر روی رایانه های مستقل اجرا شوند، جدا می شوند (شکل 2.10).

برنج. 2.10. معماری سه لایه

درخواست کاربر در چنین سیستم هایی به طور متوالی توسط بخش مشتری سیستم، سرور منطق برنامه و سرور پایگاه داده پردازش می شود. با این حال، یک سیستم توزیع شده معمولاً به عنوان سیستم هایی با معماری پیچیده تر از یک سیستم سه لایه درک می شود.

برنج. 2.11. سیستم خرده فروشی توزیع شده

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

نمونه دیگری از سیستم های توزیع شده شبکه ها هستند تبادل مستقیم داده بین مشتریان (شبکه های همتا به همتا). اگر مثال قبلی دارای معماری "درخت" بود، شبکه های تبادل مستقیم به روش پیچیده تری سازماندهی شده اند، شکل 2.12. چنین سیستم هایی در حال حاضر احتمالاً یکی از بزرگترین سیستم های توزیع شده موجود هستند که میلیون ها کامپیوتر را به هم متصل می کنند.

برنج. 2.12. سیستم تبادل مستقیم داده بین مشتریان

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

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

به عنوان مبنایی برای توصیف تعامل دو موجودیت، در نظر بگیرید مدل کلیتعامل مشتری و سرور، که در آن یکی از طرفین (مشتری) با ارسال درخواست به طرف دیگر (سرور) مبادله داده را آغاز می کند. سرور درخواست را پردازش می کند و در صورت لزوم، پاسخی را برای مشتری ارسال می کند (شکل 1.1).

برنج. 1.1.

تعامل در مدل کلاینت-سرور می تواند همزمان باشد، زمانی که کلاینت منتظر می ماند تا سرور پردازش درخواست خود را کامل کند، یا ناهمزمان، که در آن کلاینت درخواستی را به سرور ارسال می کند و بدون منتظر ماندن برای پاسخ سرور به اجرای آن ادامه می دهد. مدل کلاینت و سرور می تواند به عنوان مبنایی برای توصیف تعاملات مختلف استفاده شود. برای این دوره، تعامل اجزای نرم افزار که یک سیستم توزیع شده را تشکیل می دهد، مهم است.

برخی از کاربردهای معمولی را در نظر بگیرید که مطابق با ایده های مدرن، می توان آنها را به سطوح منطقی زیر تقسیم کرد (شکل 1.2): رابط کاربری(IP)، منطق برنامه (LP) و دسترسی به داده (DD) کار با پایگاه داده (DB). کاربر سیستم از طریق رابط کاربری با آن تعامل دارد، پایگاه داده داده هایی را که حوزه موضوع برنامه را توصیف می کند ذخیره می کند و لایه منطق برنامه تمام الگوریتم های مربوط به موضوع.

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

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

توسعه معماری مشتری-سرور یک معماری سه لایه است که در آن رابط کاربری، منطق برنامه و دسترسی به داده ها به اجزای مستقل سیستم که می توانند بر روی رایانه های مستقل اجرا شوند، جدا می شوند (شکل 1.4).

درخواست کاربر در چنین سیستم هایی به طور متوالی توسط بخش مشتری سیستم، سرور منطق برنامه و سرور پایگاه داده پردازش می شود. با این حال، یک سیستم توزیع شده معمولاً به عنوان سیستم هایی با معماری پیچیده تر از یک سیستم سه لایه درک می شود.