دانلود رایگان ترجمه مقاله تحمل خطا در سیستم مدیریت توزیع (آی تریپل ای ۲۰۰۳)

مبتدی (مناسب برای درک مفهوم کلی مطلب) 

۲٫ معماری DTMS و اجزا آن
شکل ۲ معماری سیستم را با استفاده از نمودار اشیا (زبان مدل‌سازی UML) نشان می‌دهد.
تصویر نشان می‌دهد که چگونه اجزا از یکدیگر به صورت محلی و یا از راه دور استفاده می‌کنند. یک سایت شامل اجزائ زیر است: Transaction، Model، Persistence، Topology، Replication و Database. جزء Client متعلق به سایت نیست. مشتری می‌تواند متصل به یک سایت دلخواه باشد. لطفا توجه داشته باشید که ارتباطات از راه دور بین اجزای از نوع یکسان برقرار است (به عنوان مثال. Replication محلی و Replication از راه دور). همانطور که در سمت راست نشان داده می‌شود، اجزاء Model و Transaction متعلق به جنبه‌ی توزیع هستند، جزء Persistence به جنبه تداوم و Topology و Replication به جنبه تکرار از معماری برمی‌گردد.
مدل. مولفه Model شامل مدل VCS است. این مدل
• پیچیده است، به عنوان مثال شامل بسیاری از کلاس‌ها، حالات کوچک شی و چند حالت شی در هر کلاس است.
• نیاز به اعتبارسنجی پیچیده دارد، به عنوان مثال بسیاری از محدودیت‌های الگوریتم که شامل بسیاری از حالات شی است.
• نیاز به عملیات پیچیده خواندن مربوط به بسیاری از اشیا، به‌عنوان مثال جمع‌آوری اطلاعات برای پیکربندی VCS.
هر مدل شی دارای یک سیستم گسترده ID منحصر به فرد است. هر کلاس دارای یک کارخانه در ارتباط است، که می‌تواند با نام کلاس (مانند سرویس نامگذاری) تخصیص یابد. کارخانه اشیاء را ایجاد و حذف می‌کند. کارخانه محدودیت اشیا را تایید می‌کند.
اشیاء و کارخانه‌ها در اجزاء Transaction ثبت‌نام می‌کنند. اشیاء حالت سریال شی خود را در Persistence ذخیره می‌کنند. توپولوژی جستجوهای کارخانه برای سایت واکنش‌گرا فعلی و مقداردهی اولیه بر این اساس بااستفاده از مدل راه دور و یا تداوم محلی است. کارخانه‌ها منابع شی سازگار (IORها، اشاره بهCORBA) ارائه می‌دهند که اشاره به شی محلی و یا از راه دور مرتبط با ID یا پرس‌وجو دیگر دارد. کارخانه‌ها IORها را در اشیاء از راه دور و با برقراری ارتباط از راه دور با کارخانه به دست می‌آورند. مشتریان می‌توانند IORها را برای هر شیء در کارخانه به دست آوردند.
رفتار تراکنشی و پشتکار برای همه مدل‌های اشیاء الزامی است. بنابراین، تمام مدل‌های اشیاء متدهای validate()، commit()، rollback() و store() را پیاده‌سازی می‌کنند.
مشتری. جزء سرویس‌گیرنده فراخوانی در اشیاء را به‌صورت مدل محلی و یا از راه دور انجام می‌دهد، که در آن موقعیت فیزیکی مدل شئ برای مشتری شفاف است. تعداد دلخواهی از اجزای مشتری می‌توانند به صورت همزمان در مدل کار کنند. جزء مشتری و اتمام تراکنش‌ها در Transaction شروع می‌شود.
توپولوژی. جزء Topology یک لیست از همه سایت‌ها و در دسترس بودن آنها و اطلاعاتی در مورد سایت حاضر برای یک شی خاص است. که توسط Model و Transaction مورد نیاز است. بنابراین، Topology به دیگر اجزاء می‌گوید که در کدام سایت‌ها باید دنبال یک شی باشد.
تراکنش. جزء Transaction، مسئول تراکنش همزمان سریال است. commit()، rollback() و validate() را بر روی اشیاء در Model متعادل می‌کند، همچنین تراکنش را در persistence و مختصات تراکنش توزیع‌شده را از راه دور کنترل می‌کند (فاز ۲ commit[3]).
در حال حاضر، کوچکترین واحد دانه دانه‌شدگی کل یک سایت است. از آنجا که انتظار نمی رود نوشتن تراکنش‌ها طول بکشد اعتبارسنجی شامل بسیاری از حالات شی از کلاس‌های مختلف است، که کافی است. ما بین تراکنش نوشتن و خواندن تمایز قایل می‌شویم.
ماندگاری. اجزاء Persistence حالات شی را با استفاده از جزء Replication بازیابی می‌کند. علاوه‌براین، روشی برای دسترسی به حالات شی در راه تراکنش‌ها، که از Transactionاستفاده می‌کنند فراهم می‌کند. Persistence بین حالات شی که به خانه در سایت‌های محلی اختصاص داده می‌شود و حالات شی که به خانه در یک سایت از راه دور اطلاق می‌شود تفاوتی قائل نیست، اما همیشه به ادامه و بازیابی اجزاء Persistence محلی اصرار دارد. کارخانه‌ها همیشه Persistence محلی خود را برای بازیابی حالات شی همچنان ادامه می‌دهند. یک شی همچنان به ارائه شناسه خود ادامه می‌دهد.
پایگاه داده. جزء پایگاه‌داده اساسا برای ذخیره‎‌سازی ثابت کپسوله شده است و توابع اولیه‌ای برای ادامه و بازیابی داده‌ها فراهم می‌کند. همچنین ممکن است پایگاه داده محلی را در محفظه‌ای برای دسترسی بالا نگه دارد.
تکرار. جزء Replication در قلب معماری قرار دارد و الگوریتم تکرار را پیاده‌سازی می‌کند. که پروتکل تکرار را براساس Replication سایت‌های دیگر برای انتشار حالات شی، جهت ساخت حالات شی و محاسبه آمادگی شی انجام می‌دهد. و از جزء Database برای ادامه اطلاعات به صورت محلی استفاده می‌کند و روشی برای دسترسی به حالت شی ذخیره شده فراهم می‌کند.

۳٫ مطالب فراگرفته شده
ما مهم‌ترین مطالب را با تمرکز بر روی جنبه‌های مفهومی به جای جزئیات پیاده‌سازی و یا یافته‌ها در مورد محصولات COTS و ابزار ارائه می‌دهیم.
معناشناسی روش‌ها در مقابل خواندن/نوشتن: مقدار قابل توجهی نظریه در مورد موضوع روش بهره‌برداری معناشناسی به‌منظور افزایش در دسترس بودن برخی از روش‌ها وجود دارد (به‌عنوان مثال [۸]، که در آن “روابط تقاطع” جریان اطلاعات را میان توابع فراخوانی می‌کند). در عمل، ما قادر به استفاده از هر روش طبقه‌بندی نسبت به روش خواندن و روش نوشتن، به ویژه با توجه به موارد استفاده مشترک نیستیم. به غیر از افزایش قابل توجه پیچیدگی اجرا (یک روش تکرار در نظر بگیرید، که در مورد روش معناشناسی هر نوع شی و محاسبه در دسترس بودن اشیاء می‌داند) سیستمی غیر قابل درک از نقطه نظر کاربران ارائه می‌دهد.
نگاشت هویت شی به مرجع شی: به‌دست آوردن مرجع شی (به‌عنوان مثال محل یک شی) با توجه به شناسه شیء (به‌عنوان مثال نام شی) همیشه از نگرانی برخوردار است اگر اشیاء خارج از فرآیند یا حتی از راه دور باشند (در مقایسه با سرویس نامگذاری CORBA [1] و یا نامگذاری جاوا و رابط راهنما [۲]). بنابراین چنین سرویس نامگذاری نیاز به تداوم اساسی دارد، اگر اشیاء در مکان‌های مختلف با توجه به سناریوی تخریب خاص زندگی کنند این موضوع پیچیده می‌شود. از یک طرف، اطلاعات سرویس نامگذاری در مورد ارجاع اشیاء حفظ می‌شود (که در آن یک مرجع محل اسیا را تعیین می‌کند)، از سوی دیگر، جزء تکرار تصمیم می‌گیرد که اگر تخریب رخ دهد اشیاء نمونه کجا قرار گیرند. بدین ترتیب، نگاشت شناسه به مرجع بسیار وابسته به مکانیسم‌های زیر بنایی برای ارائه تحمل‌پذیری خطا است. علاوه‌براین، سرویس نامگذاری با خرابی امن باید در هر سایت و در هر زمان دردسترس باشد، چراکه سرویس نامگذاری باید خودش تحمل‌پذیری خطای بالایی داشته باشد.
در این مطالعه، یک شناسه شی با استفاده از دو مرحله ارائه می‌کنیم. در ابتدا، جزء توپولوژی برای سرویس نامگذاری حاضر پرس‌وجو می‌کند (کارخانه‌ها در DTMs)، که می‌تواند بسته به سناریوی تخریب به صورت از راه دور یا محلی باشد. در مرحله دوم، در نهایت شناسه شی حل و فصل می‌شود.