بخشی از ترجمه فارسی:
مقدمه
ازمیان افزار JavaSymphony جهت ایجاد سیستم توزیع شده استفاده
میشود . این ابزار یکی از کاراترین میان افزار های طراحی شده جهت ساخت
سیستم های توزیع شده است که برنامه نویس را از پرداختن به بسیاری از
جزئیات برنامه نویسی بی نیاز می کند.
در بخش2 به معرفی JavaSymphony
پرداخته, امکانات و توانایی هایی که این ابزار جهت ساخت سیستم های توزیع
شده و موازی در اختیار برنامه نویس قرار می دهد را معرفی کرده, نحوه
استفاده از JavaSymphony برای برنامه نویسی و ساخت سیستم های توزیع شده به
زبان جاوا, خصوصیات کلاس ها و توابع مختلف این ابزار و ویژگی های آنها
بیان می شود. در بخش3 امکانات پیشرفته تر JavaSymphony که در نسخه های
بعدی آن به منظور افزایش کارایی برنامه های ساخته شده توسط این ابزار به
آن اضافه شده (مانند تکنیک های همگام سازی پروسه ها, ایجاد اشیا چند نخی,
بسط معماری مجازی, تبدیل پویا اشیا و… ) را بررسی خواهیم کرد. در بخش 4
نحوه نصب, راه اندازی و استفاده از JavaSymphony درکامپیوتر های مختلف
شبکه برای ایجاد یک زیر ساخت ارتباطی و تعریف معماری فیزیکی سیستم توزیع
شده را بررسی خواهیم کرد.2. مفاهیم اصلی JavaSymphony
اغلب سیستمهای
توزیع شده یا موازی که به وسیله جاوا پیاده سازی می شوند نیازمند پرداختن
برنامه نویس به کارهای جزئی بسیار و خسته کننده هستندکه احتمالا منجر به
اشتباه برنامه نویس نیز می شوند. JavaSymphony یک ابزار برنامه نویسی جهت
پیاده سازی سیستم های توزیع شده و موازی است که دامنه وسیعی از سیستم های
همگن از سیستم هایی با خوشه های کوچک تا سیستم های محاسباتی وسیع را
پشتیبانی می کند. این ابزار تماما به زبان جاوا نوشته شده وبا تمام
ماشینهای مجازی جاوا (JVM) سازگاری دارد. می توان گفت در مقایسه با دیگر
ابزارهای موجود، JavaSymphony امکانات بهتر و قابل انعطاف تری را برای
مکان یابی اشیاء و بارگذاری متعادل در اختیار برنامه نویس قرار می دهد.
JavaSymphony در واقع یک کتابخانه از کلاس های جاوا است که به برنامه نویس
امکان کنترل Locality موازی سازی و بارگذاری متعادل را در سطح بالایی می
دهد, و برنامه نویس را از پرداختن به مسائل جزئی مانند ایجاد و استفاده از
Remot-Proxy ها, برنامه نویسی نخ ها, برنامه نویسی سوکت ها و پردازش خطا
ها بی نیاز می کند. به کمک این ابزار یک معماری مجازی، ازگره های محاسباتی
(کامپیوتر های شبکه ) تعریف می شود. برنامه نویس می تواند با تعریف
معماری مجازی دلخواه خود، سلسله مراتبی ازگره های محاسباتی فیزیکی برای
سیستم توزیع شده خود بسازد. اشیاء برنامه می توانند به صورت پویا در هر
کدام از مؤلفه های این معماری مجازی مستقرشده یا بین آنها حرکت کنند. مجمو
عه ای ازگره های سطح بالا جهت کنترل پارامترهای مختلف نرم افزاری و سخت
افزاری سیستم در دسترس است . اشیاء می توانند توسط فراخوانی متدهای یکدیگر
به سه روش سنکرون، آسنکرون و یک طرفه با یکدیگر ارتباط برقرار کنند.
بارگذاری کلاسهای برنامه به صورت دلخواه در گره های مختلف محاسباتی نیز می
تواند موجب کاهش حافظه مورد نیاز در کل سیستم توزیع شده شود. بعلاوه می
توان اشیاء را به طور دائم در حافظه های جانبی ذخیره, نگهداری و بازیابی
کرد.
اغلب پروژهای تحقیقاتی که یک زیر ساخت نرم افزاری برای برنامه های
توزیع شده وموازی ارائه می کنند معمولا مانع از کنترل مکان استقرار اشیاء
توسط برنامه نویس می شوند. با توجه به اینکه معمولا برنامه نویس اطلاعات
بیشتروکامل تری در مورد ساختار سیستم توزیع شده و نحوه توزیع شده گی مطلوب
اشیاء بر روی شبکه را دارد از این رو اکثر سیستم های توزیع شده که توزیع
اشیاء درگره های محاسباتی و حرکت بین آنها را به صورت اتوماتیک انجام می
دهند موجب کاهش کارایی سیستم توزیع شده خواهند شد. زیرا که از اطلاعات مهمی
که برنامه نویس در مورد سیستم توزیع شده دارد استفاده نمی کنند و در
نتیجه ممکن است ارتباط بین اشیاء توزیع شده در شبکه با یکدیگر زیاد شده و
کارایی کل سیستم بسیار پایین بیاید.
2. 1. ویژگی های Java Symphony
JavaSymphony یکی از ابزارهای ساخت
سیستمهای توزیع شده و موازی است که یک زیر ساخت مناسب جهت ساخت برنامه های
توزیع شده و موازی ارائه می کند. همانطورکه گفته شد این ابزار توسط زبان
جاوا پیاده سازی شده وبه صورت کتابخانه ای از کلاسهای جاوا (.class)
موجوداست که می توان از این کلاس ها در هر برنامه نوشته شده به زبان جاوا
استفاده کرد. برخی از خصوصیات مهم این ابزار عبارتند از:
• امکان
تعریف یک معماری مجازی توزیع شده: برنامه نویس می تواند یک معماری مجازی
برای سیستم توزیع شده خود تعریف کرده و به این ترتیب سلسله مراتبی از گره
های محاسباتی فیزیکی را برای برنامه خود تشکیل دهد. معماری مجازی از مولفه
های زیر تشکیل می شود: گره های محاسباتی، خوشه ها که مجموعه ای ازگره های
محاسباتی هستند، سایت هاکه مجموعه ای از خوشه ها هستند و دامنه ها که
مجموعه ای از سایتها هستند. در هنگام تعریف یک معماری مجازی می توان با
استفاده از امکانات تعریف شرایط برای گره های محاسباتی، فقط از منابع
محاسباتی مناسب یا دلخواه در شبکه، جهت ساخت سیستم توزیع شده استفاده کرد.
(بعنوان مثال استفاده از کامپیوترهای بیکار در شبکه) معماری های مجازی
چندگانه نیز قابل تعریف هستند که می توانند مولفه های خود را به اشتراک
بگذارند.
• دسترسی به پارامترهای سیستم : JavaSymphony مجموعه ای از
API های سطح بالا برای کنترل بسیاری از پارامترهای سیستم ارائه می کند از
جمله می توان به پارامترهای CPU Load (میزان کار بارگزاری شده به CPU )،
idle Times (درصد بیکاری)، میزان حافظه در دسترس، تعداد پروسه ها و نخهای
موجود در سیستم, تاخیر شبکه و پهنای شبکه اشاره کرد. این پارامترها می
توانند از سیستم زمان اجرای JavaSymphony یا JRS درخواست شده و برای کنترل
استقرار اشیاء در مولفه های مختلف معماری توزیع شده, حرکت اشیاء بین
مولفه ها و بارگذاری متعادل استفاده شوند.
• استقرار اشیاء در مولفه
های محاسباتی بصورت اتوماتیک وکنترل شونده از طرف کاربر: برنامه نویس می
تواند ایجاد و استقرار یک شی در یکی از مولفه های معماری مجازی را کنترل
کند. استقرار یک شی در یک مولفه می تواند با توجه به مکان اشیا دیگر که با
این شی در ارتباط خواهندبود, صورت گیرد. بعنوان مثال ممکن است مجموعه ای
از اشیاء که با یکدیگر ارتباط زیادی دارند برروی مولفه هایی از معماری
مجازی که نزدیک یکدیگر هستند مستقر شوند. اگر برنامه نویس دقیقا” محل یک
شی را جهت اجراء در آن مکان مشخص نکند JRS بصورت اتوماتیک در مورد محل
قرارگیری شی در بین گره های محاسباتی فیزیکی تصمیم گیری خواهد کرد.
•
حرکت اشیاء بین مولفه های محاسباتی بصورت اتوماتیک و قابل کنترل از طرف
کاربر:JavaSymphony از حرکت اشیاء بین گره های محاسباتی بصورت اتوماتیک و
یا تحت کنترل کاربر پشتیبانی می کند.
• فراخوانی سنکرون, آسنکرون و یک
طرفه متدها: همانطورکه می دانیم تمامی فراخوانی روالهای دور در جاوا بصورت
سنکرون انجام می گیرد. علاوه بر این مکانیزم، JavaSymphony دو روش دیگر
برای فراخوانی متدهای دور را در اختیار برنامه نویس قرار می دهد: 1-
فراخوانی آسنکرون که در این روش یک Handle که برای بررسی آماده بودن نتیجه
در آینده استفاده خواهد شد, بعنوان نتیجه فراخوانی روال برگشت داده می
شود. 2- فراخوانی یک طرفه : که دراین روش طرف فراخوانی کننده متد، منتظر
دریافت هیچ نتیجه ای از فراخوانی متد نمانده، بلکه متد دو را فراخوانی
کرده و بدون اینکه بداند اجرای آن کی به اتمام خواهد رسید کارهای خود را
دنبال می کند.
• بارگذاری کلاسهای دور بصورت دلخواه : به
کمکJavaSymphony بجای آنکه لازم باشد تمام فایلهای حاوی کلاس های برنامه
توزیع شده در تمامی گره های محاسباتی ذخیره شوند، این فایل ها می توانند
در زمان نیاز در یک گره به آن گره بارگزاری شده و استفاده شوند. این
خصوصیت می تواند باعث کاهش کل حافظه مورد نیاز برنامه توزیع شده شود.
بعلاوه JavaSymphony از اشیاء مانا نیز پشتیبانی می کند. یعنی به برنامه
نویس اجازه میدهد اشیاء برنامه را در حافظه های جانبی ذخیره کرده و بازیابی
کند. این ابزار نیازی به هیچ گونه تغییردر زبان جاوا یا JVM یا کامپایلر
جاوا نداشته و بصورت کتابخانه ای از Class ها پیاده سازی شده و قابل
استفاده است. JavaSymphony براساس سیستم های مبتنی برAgent ساخته شده و
فعلا در حال ارزیابی است.
2. 2. معماری مجازی توزیع شده گی پویا (Dynamic Virtual Distributed Architectures)
JavaSymphony از مکان یابی, بارگذاری متعادل و حرکت اشیاء بین گره های
محاسباتی به صورت اتوماتیک پشتیبانی می کند (بدون اینکه برنامه نویس دخالتی
داشته باشد) اما تجربه نشان داده که سیستمهای تمام اتوماتیک فعلی معمولا
نمی توانند اطلاعات کافی (به اندازه برنامه نویس) در مورد ساختار سیستم
توزیع شده, بدست آورندو در نتیجه کارایی ضعیفی را به دنبال دارند.
از
این رو درJavaSymphony یک حالت نیمه اتوماتیک برای پیاده سازی و پیکربندی
سیستم توزیع شده ارائه شده است. به این صورت که بسیاری از کارهای جزیی و
خسته کننده و مسائل سطح پایین برای پیاده سازی سیستمهای توزیع شده (مانند
ایجاد و استفاده از پروکسی ها ، برنامه نویسی سوکتها و…) توسط
JavaSymphony انجام می شود اما تصمیم گیری های مهم و استراتژیک در مورد
ساختار سیستم توزیع توسط برنامه نویس صورت می گیرد. برنامه نویس جهت تعریف
ساختار سیستم توزیع شده کارهای زیر را انجام می دهد:
• تعریف یک
معماری مجازی توزیع شده با مشخص کردن گره های محاسباتی، خوشه ها، سایتها
ودامنه ها: این معماری برای اجرای برنامه کاربردی بصورت توزیع شده برروی
شبکه استفاده خواهد شد. برنامه نویس میتواند برخی شرایط سیستمی برای گره
های محاسباتی تعریف کند تا تنها کامپیوترهایی در شبکه که حائز آن شرایط
هستند (چه نرم افزای و چه سخت افزاری) بعنوان منابع محاسباتی فیزیکی برای
معماری تعریف شده, استفاده شوند.
• استقرار داده ها و اشیاء با توجه به
ارتباط آنها با داده های دیگربر روی گره ها : بعنوان مثال اشیایی که
ارتباط زیادی با هم دارند ممکن است برروی گره های محاسباتی نزدیک به هم و
یا حتی برروی یک گره بارگذاری شوند.
• استقرار اشیاء یا داده ها برروی
گره های محاسباتی با توجه به شرایط سیستمی آنها : بعنوان مثال استقرار
اشیا در گره هایی با کمترین میزان کاری یا بالاترین حافظه در دسترس.
•
بارگذاری کدهای مورد نیاز (کد کلاسها) در گره های محاسباتی هنگام نیاز به
آنها: با استفاده از این ویژگی نیازی به ذخیره سازی کد تمام کلاسهای
برنامه توزیع شده در تمام گره های محاسباتی نبوده و میتوان کد هر کلاس را
هنگام نیاز به آن در یک گره خاص به آن بارگذاری کرد.
JavaSymphony
مفهومی بنام Dynamic Virtual distributed architectures (که از این به بعد
معماری مجازی می نامیم) ارائه می کند, که به برنامه نویس امکان تعریف
ساختار شبکه ای از منابع محاسباتی را می دهد. پس از تعریف این ساختار می
توان اشیاء مختلف موجود در برنامه را در مولفه های تشکیل دهنده این معماری
مستقر کند یا اشیاء موجود درگره های محاسباتی را به گره های دیگر حرکت
دهد. همچنین می تواند بین تعداد اشیاء بارگذاری شده در گره های مختلف
موازنه ایجاد کند ونیز کدهای لازم را هنگام نیاز به آنها درهر یک ازگره ها
بارگذاری کند. هر معماری مجازی در حقیقت دامنه ای است که به سایتها، خوشه
ها وگره هایی تقسیم شده است. (شکل 1) در پایین ترین سطح گره هایا گره های
محاسباتی قرار دارند که در حقیقت معادل یک منبع محاسباتی فیزیکی مانند PC
یا WorkStation میباشند. گره های مختلف می توانند با یکدیگر ترکیب شده و
تشکیل یک خوشه را دهند که در حقیقت معادل یک شبکه محلی از چند PC یا
WorkStation است سطح بعدی را سایت ها تشکیل می دهند که مجموعه ای از خوشه
های متصل به هم مثلا به وسیله یک WAN یا LAN میباشند. در بالاترین سطح
سایتها می تواننند با یکدیگر ترکیب شده و تشکیل یک دامنه (domain) را دهند
که در حقیقت یک شبکه محاسباتی بزرگ و توزیع شده است. توجه داشته با شید
که هرگره متعلق به یک سه تایی یکتای (خوشه- سایت – دامنه) می باشد بطور
مشابه هر خوشه یه یک دو تایی یکتای (سایت -دامنه) وهرسایت به یک دامنه خاص
تعلق دارد.
شکل 1 . معماری مجازی
معماری مجازی می تواند به صورت پویا ایجاد شده
یا تغییر داده شود هرمؤلفه ازیک معماری مجازی( گره ، سایت ، خوشه ،
دامنه) توسط مدیری که قابل رویت برای برنامه نویس نبوده و به عنوان بخشی
ازJRS پیاده سازی شده، کنترل می شود.
2. 3. مدل برنامه نویسی Java Symphony
در حالت کلی هربرنامه کاربردی
که از JavaSymphony استفاده می کند باید ابتدا خود رادر سیستم زمان اجرای
JavaSymphony یا(JRS) ثبت یا Register کند. پس از آن می تواند معماری
مجازی خود را تعریف کند. اشیاء می توانند هم در گره های محاسباتی محلی و
هم درگره های دیگر به صورت دور ایجاد شده وبین گره های شبکه حرکت کنند.
برای ارتباط بین اشیاء موجود در سیستم توزیع شده نیز JavaSymphony از سه
مدل فراخوانی متدهای دورپشتیبانی می کند ( سنکرون، آسنکرون و یک طرفه). در
نهایت برنامه کاربردی قبل از اتمام, خود را از وضعیت ثبت شده در JRS خارج
می کند((unregister این کار باعث آزاد شدن منابع JRS و حافظه تخصیص یافته
به برنامه خواهد شد.
بخشی از مقاله انگلیسی:
I. Documentation for the API
programmer 1.) The Network Agent How to find a virtual architecture in a
physical architecture? Look at the following physical architecture
like created in the Shell: To create an easier to understand tree you
have to remember that a node with level 3 can have children with level 2
and with level 3. So a node with level 3 is also a node with level 2
and a node with level 1. The following picture will show the example
above: This representation of the tree is better to understand which
virtual architectures can be found in the physically. A virtual
architecture is a tree structure with working nodes only at the leafs.
Look at the following example of a virtual architecture: This virtual
architecture can be found in the physical architecture above, but there
are more different solutions and without knowing the constraints of
the nodes in the physical architecture the following solutions are
possible: V1 = N1; V2 = N2; V3 = N3 V1 = N4; V2 = N5; V3 = N2 V1 =
N5; V2 = N1; V3 = N4 … there are many solutions but the following
solutions are not possible: V1 = N2; V2 = N3; V3 = N5 … The order
of the nodes of the physical architecture is not important to find a
virtual architecture. Only the structure to be found is important to
exist in the physical architecture. The level of the root elements of
the two architectures have not to be the same. The level of the
physical architecture has to be higher or equal to the level of the
virtual architecture. Remember the following virtual architecture can
be found in the physical architecture above to: Solutions are: V1 =
N2; V2 = N3; V3 = N5 V1 = N3; V2 = N5; V3 = N2 … 2.) The
JavaSymphony Shell JavaSymphony Shell is part of the JavaSymphony
system. JS Shell is a graphical user interface designed to support the
creation of a physical architecture consisting of connected JS Network
Agents. This physical architecture is used by JS Applications to create
virtual architectures and run distributed programs on them. If a JS
application demands a virtual architecture, it will be mapped to a
physical architecture that fulfils the needs of the application (see
documentation for network agents for information how this is done). A
physical architecture consists of nodes (Network Agents, NA’s). Nodes
can be grouped under a cluster; clusters can be grouped under a site
and so on (where clusters and sites are normal nodes that additionally
have a cluster manager or a site manager. For being expansible, we
decided to use level numbers instead of names for the hierarchy, so a
node has level one, a cluster level two, a site level three and so on.
The maximum level is nine. The following diagram shows a node of level
three (a site) with three nodes of level two (clusters), that also have
some nodes of level one under them. Remember that there are still
eight network agents in this system (every higher level node has still
the functionality of a normal node). Starting the JS Shell You can
start the JS Shell by executing the batch file run_shell.bat in the
programs main directory. This will start up the GUI and enable you to
create a physical architecture. If you have already created a physical
architecture and stored it in a file (see “Save Configuration”), you
can use the JS Shell program to generate this stored architecture
without starting the GUI by appending filename as a program argument:
run_shell [filename] This will generate the architecture stored in the
file, showing all information and errors as console output. The program
will stop after generation. The Main Window The main window is divided
into two parts. On the right side there is a list of available NA’s
that can be added to a physical architecture on the left side. A NA is
defined by the computer name (or IP) on witch the NA is running and the
port on which the NA is listening ([computer_name]:[port]). At
start-up, the default list stored in a file (serverlist.ini) will be
loaded and displayed in the list window as well as the configuration
stored in the file config.txt will be displayed as a tree in the left
part. Of course you can load and store other lists and configuration
files (see “Load Configuration”, “Load NA-List”). The List The list
displays all NA’s that are currently available (marked with a green
tick) as well as some other computers, where no NA is currently running
on the specified port (marked with a red cross). NA’s, that are not
marked could not be reached yet, they will be marked in a few seconds.
You can add NA’s to the list, remove NA’s from the list and load and
store lists of NA’s (see “Load NA-List). You can add an NA to the
physical architecture on the left side by dragging and dropping it on
the desired position in the architecture tree. The Tree The Tree window
allows you to design a physical architecture consisting of NA’s. You
can drag and drop NA’s in the tree around as well as remove them from
the tree by dragging them to the list window. You can also load and
store configurations to a file. If the design of your physical
architecture is finished, you can create the physical architecture my
selecting “Make Configuration” from the menu. Each NA in the tree will
be contacted and the physical architecture will be created. The tree in
the picture above displays two independent virtual architectures, one
with root NA “agnes.par.univie.ac.at” and one with
“daphne.par.univie.ac.at”. The node named “Systemroots” is just a dummy
tree node and not a real NA. The first one is a NA of level three
(agnes) consisting of two NA’s of level two (amanda, claire). The first
one (amanda) consists of two NA’s of level one (becky, brooke), the
second consists of three NA’s (darlene, dolly, edwin). The root of the
second system is a NA of level five (daphne) consisting of one NA of
level four (cybill) and another one of level 2 (lisa), and so on.
