دانلود رایگان ترجمه مقاله Mobilitools ابزار قابل حمل مبتنی بر استانداردهای OMG

 مقاله انگلیسی رایگان

ترجمه فارسی رایگان 

بخشی از ترجمه فارسی:

چکیده:
یکی از کلیدهای موفقیت برای کاربردهای همراه و یا عوامل هوشمند در سیستم های با مقیاس بزرگ از قبیل اینترنت توانایی عامل های متفاوت(غیر یکسان) برای همکاری و ارتباط ، اشتراک اگر آنها همراه باشند. لازمه این امر پذیرش استانداردهایی برای سیستم توزیع شده اساسی برای پشتیبانی همکاری در مدیریت عامل انتقال عامل همراه و محلی سازی ، و انتقال ارتباط عامل می باشد. این مقاله Mobilitools ، و یک راه حل مبتنی بر استاندارد OMG برای این موضوع را معرفی می کند، و نشان می دهد که چطور پلات فرمهای عامل همراه می توانند از ترکیب سه جزء مستقل که به ترتیب عبارتند از : آدرس دهی همراه، ارتباط، لزوم فعالیتی.

۱- آیا به پلات فرم های عامل جاوای دیگری نیاز می باشد؟

۱-۱- یک مثال جدید برای سیستم های توزیع شده:
تکنیک های سنتی برای سیستم های توزیع شده مبتنی بر Client/Server ، که بنا به درخواست، و نمونه های ارزیابی راه دور که نتیجه نهایی در جابجایی کد و یا داده و یا کنترل چنانکه در [۱۴] توصیف شده است. اکنون عامل های قابل حمل همه چیز را در یک نمونه جدید آورده اند.
این نمونه بوسیله Telescript[15] تحت نام برنامه نویسی راه دور برای کاهش بار و تاخیر شبکه، و برای متناسب کردن قابلیت اتصال شبکه موقت است. چنانچه در مرجع [۹] تاکید شده است شانس کمی برای پیدا کردن “Killer application” در عامل های همراه وجود دارد اما نمونه خوب است برای هر کاربرد توزیع شده ی مجزا در یک سیستم باز پویا با مقیاس بزرگ که توانایی سازگاری از طریق توزیع مجدد پویای یک مجموعه از عامل های مشترک، کلیدی است برای مدیریت با تغییر میزبان ها و شرایط شبکه یا بهینه سازی اجرای سرویس های توزیع شده.

۲-۱- یک ترکیب پیچیده:
این نمونه شبه انسانی خوب، ممکن نیست برای استفاده عملی خیلی آسان باشد. علاوه بر موضوعات امنیتی که برای کاربردهای با مقیاس بزرگ روی اینترنت ضروری می باشند، شفافیت قابلیت اطمینان، مقیاس پذیری و همکاری با یکدیگر چالش های کلیدی دیگری هستند.
شـفافیـت : پلات فرم های عامل موبایل که روی زبانهای برنامه نویسی متمرکز ساخته می شوند، با تواناییهای ارتباطی راه دور بهبود می یابند و نهایتاً با ویژگی های قابلیت حمل کامل می شوند (مانند پلات فرم های مبتنی بر جاوا) این ویژگی نهایی افزوده شده، قابلیت حمل رفتارفریم ورک برنامه نویسی راعمیقاً تغییرمی دهد، برای نمونه بسیاری از بسته های JDK های مفید برای قابلیت حمل، و شفافیت موضوعات قابلیت حمل که برای هر نوع دسترسی به منابع از قبیل نخ ها و فایل ها و سوکت ها و غیره طراحی نشده اند.
این دلیلی است که چرا فریم ورکهای مبتنی بر جاوا شامل مدل های معین و ابزارهایی برای فعالیت عامل، ارتباط و قابلیت حمل و محدودیت های برنامه نویسی معین می باشند. برای مثال ایجاد نخ ها مطرود (یا ممنوع) شده است بوسیله Voyayer[19] و Grasshoper[17] ، بدلیل اینکه پلات فرم ها به مدیریت قوی فعالیت های عامل نیاز دارند. در بعضی از پلات فرم ها محدودیت های ناکافی یا نادیده گرفته شده اگر قابلیت حمل تا زمانی که یک عامل درگیر یک ارتباط است رخ دهد می تواند رفتار نامشخص را نتیجه بدهد. حقیقت امر این است که ارتباط نتایجی روی فعالیت عامل و قابلیت حمل نتایجی بروی هر دوی فعالیت و ارتباط دارد.
شفافیت کامل متشکل از قابلیت حمل قوی چنانکه در [۶] تعریف شد نه تنها حالت عامل بلکه همچنین حالت فعالیت آن و قیدهایش به منابعی از قبیل ارتـبـاطات مـداوم را نگه می دارد.
مقیاس پذیری : هر دوی مدل های فعالیت و ارتباط اهمیت زیادی برای مقیاس پذیری دارند. پلات فرم های مبتنی بر جاوا که ایجاد می کند (حداقل) یک نخ فعالیت بر عامل را، مثال هایی از غیر مقیاس پذیری هستند اگر شما تصور کنید صدها یا هزاران عاملی که نیاز به اشتراک در یک مکان را داشته باشند.
همچنین ابزارهای ارتباطی در مقیاس پذیری مشخص می شود نمایندگان برای اخذ مزایای نمونه برنامه نویسی راه دور به ارتباط محلی نیاز دارد چنانچه در[۱۳] توضیح داده شده ارتباط راه دور ممکن است در چندین روش با خصوصیات کم و بیش پیشرفته تحت شرایط پایدار قابل اعتماد، ضمانت تحویل و علیت پیاده سازی شود([۲],[۱۳]). متاسفانه این خصــوصـیات برجـسته عموماً مبتکی به الگوریتم های توزیع شدۀ معرفی کنندۀ محدودیت های مقیاس پذیری هستند.
همکاری با یکدیگر : آخرین از حیث ترتیب نه از حیث اهمیت، همچنین باید ملاحظه شود که خصوصیات معین عامل های موبایل مختصِ سیستم های با مقیاس بزرگ، پویا و توزیع شدۀ باز (یعنی اینترنت) می باشند. در این زمینه عامل های موبایل غیر یکسان نیاز به زبانهای ارتباطی سطح بالا برای فهم یکدیگر دارند، بعلاوه یک ساختار اجرایی توزیع شدۀ استاندارد شده وارتباطی برای همکاری بازبانهای دیگر ارتباطی FIPA[16] و نماینده های مبتنی بر KQML ، استانداردهای پدیدار شده ای برای فهم یکدیگر عامل ها،گفتگو و همکاری با یکدیگر هستند.اما ارتباطات سطح بالا همچنین نیاز به یک همکاری سطح بالا همچنین نیاز به یک همکاری سطح پایین روی سطح حامل ارتباطی دارد.متاسفانه هیچ ساختار ارتباطی استاندارد حقیقتاً برای حمل پیغام ها بین عامل های غیر یکسان بوجود نیامده است. نمایندگان موبایل همچنین نیاز به حرکت بسوی ساختار استاندارد سازی شده با یک (فریم ورک) مفهومی مشترک را دارند تا با یکدیگر کار کنند.
امروزه پلات فرم های عامل موبایل معمولاً با فریم ورک های یکپارچه شده معینی می ایند که آن را برای پشتیبانی، همکاری برای سخت می کند با وخود این تاًییدۀ CORBAی، voyagers وقرار داد MASIFی، Grasshoper دلگرم کننده تلاش های نمونه به سمت همکاری با یکدیگر هستند.

بخشی از مقاله انگلیسی:

Abstract 

One of the keys to success for applications of mobile and/or intelligent agents in large-scale systems such as Internet is the ability of heterogeneous agents to cooperate and negotiate, and meet if they are mobile. This requires the adoption of standards for the underlying distributed system to support interoperability in agent management, mobile agent transport and localization, and agent communication transport. This paper introduces MobiliTools, an OMG standardsbased solution to these issues, and show how mobile agent platforms can be built from the combination of three independent components, respectively addressing mobility, communication, and activity concerns. 1 Yet Another Java Mobile Agent Platform?

۱٫۱ A new paradigm for distributed systems

Classical techniques for distributed systems are based on client/server, code on demand, and remote evaluation paradigms, which finally result in moving code, and/or data, and/or control, as described in [14]. Now, mobile agents bring everything together into a new paradigm. This paradigm was introduced by Telescript [15] under the name of remote programming, to reduce network load and latency, and to fit temporary network connectivity. As underlined in [9], there is little chance to find a “killer application” of mobile agents, but the paradigm is nice for any distributed application spread in a large-scale dynamic open system, where adaptation capability, through dynamic re-distribution of a set of cooperating agents, is a key to coping with changing hosts and network conditions, or to optimize the execution of distributed services.

۱٫۲ A complex combination

This nice anthropomorphic paradigm may not be so easy to handle practically. Besides security issues, which are critical to large-scale applications on the Internet, transparency/reliability, scalability and interoperability are other key challenges.

Transparency. Typical mobile agent platforms are built on a centralized programming language, enhanced with remote communication capabilities, and finally completed with mobility features (e.g. Java-based platforms). This final add-on of mobility deeply changes the behaviour of the original programming framework. For instance, many useful JDK packages are not designed for mobility, and transparency to mobility issues arise for any access to resources such as threads, files, sockets…

This is the reason why Java-based frameworks include specific models and tools for agent activity, communication and mobility, and specify programming restrictions. For instance, creating threads is discouraged (or forbidden) by Voyager [19] and Grasshopper [17], because the platform needs to tightly manage the agent activity. In some platforms, insufficient or disregarded restrictions can result in unspecified behaviour if mobility occurs while an agent is involved in communication. As a matter of fact, communication has consequences on the agent activity, and mobility has consequences on both communication and activity. Full transparency would consist in having strong mobility as defined in [6], maintaining not only the agent state, but also the state of its activity and of its bindings to resources, including on-going communications. Scalability. Both activity and communication models are of great importance for scalability. Java-based platforms that create (at least) one thread of activity per agent are examples of non-scalability if you imagine hundreds or thousands of agents needing to meet in one place.

Communication tools are also determining in scalability. Agents need to communicate locally, to take advantage of the remote programming paradigm, but also remotely, as explained in [13]. Remote communication may be implemented in a number of ways, with more or less state-of-the-art properties in terms of persistence, reliability, guaranty of delivery and causality ([2], [13]). Unfortunately, these outstanding properties generally rely on distributed algorithms introducing scalability limitations. Interoperability. Last, but not least, it must also be considered that mobile agents’ specific properties are dedicated to large-scale, dynamic, open distributed systems (e.g. Internet). In such a context, heterogeneous mobile agents need a common high-level communication language to understand each other, as well as a standardised distributed execution and communication infrastructure to interoperate.