نمایش نتایج: از شماره 1 تا 8 , از مجموع 8

موضوع: چالش های برنامه های توزيع شده

  1. #1
    کاربرسایت PARS آواتار ها
    تاریخ عضویت
    ۸۷-۰۲-۲۵
    نوشته ها
    666
    سپاس ها
    0
    سپاس شده 0 در 0 پست

    چالش های برنامه های توزيع شده

    همزمان با رشد وب ، عموميت يافتن استفاده از کامپيوترهای شخصی و پيشرفتهای مهم در زمينه دستيابی به شيکه های با سرعت بالا ، پردازش های توزيعشده بشدت مورد توجه قرار گرفته است . در اين نوع پردازش ها ، همواره میبايست بر دو اصل مهم تاکيد و راهکارهای مناسب را دنبال کرد. اولين مسئلهتوجه به معماری مبتنی بر Component ( عنصر) برای توليد نرم افزار و دومينمسئله نحوه تبين ارتباط بين عناصر ذيربط و تشکيل دهنده يک نرم افزا ر درمحيط هائی با پردازش های توزيع شده است . همانگونه که قبلا" اشاره گرديد،برنامه های مبتنی بر وب که خود نمونه ای از پردازش های توزيع شده می باشنداز مدل N-Tier پيروی می کنند. کليد طلائی طراحی اين نوع نرم افزارها ،توانائی نوشتن عناصر ( اجزاء) بگونه ای است كه از يكطرف امكان بكارگيریآنها بسادگی در لايه ها و حتی چندين برنامه فراهم شده و از طرف ديگر امكانارتباط اين عناصر با يكديگر صرفنظر از زبان برنامه نويسی استفاده شده وساير موارد ذيربط ، فراهم گردد. ما مي بايست جعبه های سياهی را طراحي كنيمكه صرفنظر از ماهيت درون هر يك ، قادر به استفاده از توان آنها در بخش يابخش های از يك و يا چندين نرم افزار باشيم .
    سير تکامل پردازش های توزيع شده
    از گذشته تا کنون دو مدل اساسی در پردازش های توزيع شده مورد توجه قرارگرفته است . RPC(Remote Procedure Call) و Client Server . ارتباطا تمبتنی بر RPC ، نسبت به Client Server دارای قدمت بيشتری بوده و بعنوانشاه كليد برنامه هاي توزيع شده در محيط يونيكس مطرح بوده است . يونيكيسيكی از اولين سيستم های عامل در زمينه استفاده كامل از امكانات ارتباطيپروتكل TCP/IP است . پروتكل فوق بهمراه استانداردهای مربوطه آن بعنوانستون فقرات شبكه هاي مبتني بر يونيكس مطرح بوده است . مثلا؛ استانداردDNS(Domain Name System) جهت همترازی آدرس يك كامپيوتر و نام آن ،FTP(File Transfer Protocol)، امكاني جهت تبادل فايل ها و پروتكل TelNet ،ارائه دهنده تسهيلات لازم جهت دستابی به ترمينال ها . اگر امروز ما دردنيائی زندگی مي كنيم كه پروتكل TCP/IP محور اساسي گفتمان در شبكه هایكامپيوتری است ، بيش از بيست سال قبل يونيكيس چنين وضعيتی را دارا بودهاست . برنامه نويسان تحت يونيكيس بخوبی از توانائي های آن برای نوشتنبرنامه های توزيع شده استفاده كرده اند. برنامه نويسان فوق از ارتباطاتمبتني بر Socket جهت نيل به اهداف خود استفاده مي كردند. بر اساس رويكردفوق ، اگر برنامه ای قصد ارتباط با برنامه ديگری را داشت ، بر اساس آدرسTCP/IP و يك شماره پورت ، يك لينك با آن برنامه ايجاد مي كرد.اين رويكردتا مدت ها بعنوان يك راه حل مناسب جهت طراحی و اجرای برنامه های توزيع شدهحضوری موفق در عرصه برنامه های توزيع شده داشت .پس از مدت زمانی رويكردفوق با دو چالش جدی مواجه گرديد : 1 – برنامه نويسان مجبور بودند كه نام ويا آدرس سرويس دهنده و شماره پورت مورد نياز جهت برقراری ارتباط را درSource برنامه ها مستقيما" مشخص نمايند . 2 – برنامه نويسان گوناگون ميتوانستند از پورت های يكسان برای برنامه های متفاوت استفاده نمايند .بديهیاست در چنين حالتی Conflict ( تعارض ) بين شماره پورت ها امری اجتنابناپذير بود. بمنظور برخورد با دو چالش فوق ، كميته يونيكيس مفهوم ارتباطاتمبتنی بر RPC را مطرح كرد. بر اساس رويكرد فوق برنامه ای با نامPortmapper بر روی هر سرويس دهنده اجرا و بين برنامه های اجرائی بر رویسيستم ها ی متفاوت ، حكميت خواهد كرد. بر اين اساس هر برنامه بجای تلاشجهت ايجاد يك ارتباط با يك پورت خاص بر روي يك سيستم ، درخواست خود رابرای Portmapper ارسال و وی مسئول ايجاد اطلاعات لازم جهت برقراری ارتباطخواهد بود. راه حل فوق با اينكه مسئله ارتباطات بين پردازه های توزيع شدهرا بگونه ای حل كرده بود ، ولي در رابطه با فورمت داده های مبادله شده بينبرنامه ها سكوت اختيار كرده بود.در اين راستا تكنولوژی ديگری با نامXDR(eXternal Data Representation)، روشی را جهت تشريح داده های يك برنامهبرای برنامه ديگر تعريف نمود. مي توان گفت كه XDR پيش كسوت XML است . RPCيك روش نسبتا" ساده ، انعطاف پذير برای پردازش های توزيع شده را ارائهكرد. شايد اين سوال مطرح شود كه چرا تكنولوژی فوق نتوانست تسلط و چيرگیخود را بر روی پردازش های مبتنی بر Client/Server ادامه و مستمر نمايد؟

    مدل ارتباطي RPC تسلط مقتدر خود را در دنيای يونيكس بخوبي ادامه داد وليبا پيدايش و نياز به ارتباطات مبتني بر Client Server ( PC-to-server ) بايك مانع جدی مواجه گرديد. مشكل اساسی پروتكل هائی بوند كه در اغلب سيستمهای Client Server استفاده مي گرديد.پروتكل TCP/IP استاندارد تمامیتوليدكنندگان نبود و هر توليدكننده پروتكل های اختصاصي خود را داشت مثلا؛شركت ناول از IPX و شركت ماكروسافت از NetBEUI استفاده می كردند.چونپروتكل TCP/IP بعنوان استاندارد در دنياي سرويس دهندگان مبتني بر PC ،هنوز مطرح نشده بود و ارتباطات مبتنی بر RPC گزينه ای مناسب در اين زمينهنبودند، چراكه ستون فقرات تكنولوژی فوق بر پروتكل TCP/IP استوار بود.بنابراين در مقطعي با رشد شديد روش های ارتباطي نظير ODBC براي دستيابي بهبانك های اطلاعاتي ، صف بندی پيامها برای تبادل همزمان ، IPC و … مواجهشديم . پس از اينكه پروتكل TCP/IP به ميدان Client Server قدم گذاشت ،مجددا" ارتباطات مبتنی بر RPC مورد توجه قرار گرفت . در اين راستاتكنولوژيهای ارتباطی متفاوتی نظير : OLE ، Com ، Dcom ، Corba ، J2EE،Java Enterprise ، Tuxedo و… مطرح گرديدنند. تمامی تكنولوژيهای فوقبدنبال ارائه تسهيلات ، انعطاف پذيری و اعتماد سازی بيشتر در برنامه هایتوزيع شده بودند. مطلب فوق شايد مهمترين دليل رويكرد شركت های عظيم نرمافزاري جهت ارائه يك ساختار استاندارد براي توليد اين عناصر باشد.
    دو مدل استاندارد عمده تاکنون ، در اين زمينه مطرح و ارائه شده است.(DCOM(Distributed Component Object Model و CORBA Common Object RequestBroker Architecture ، مدل های استاندارد شده در اين زمينه می باشند.

  2. #2
    کاربرسایت PARS آواتار ها
    تاریخ عضویت
    ۸۷-۰۲-۲۵
    نوشته ها
    666
    سپاس ها
    0
    سپاس شده 0 در 0 پست

    Re: چالش های برنامه های توزيع شده

    تعاريف و اصطلاحات

    *

    Interface . مجموعه ای از متدها که مسئوليت ارائه عمليات وارائه قابليت ها را برعهده خواهند داشت .
    *

    Object class or class . نام مورد نظر برای پياده سازی يک و يا چندين اينترفيس
    *

    Object (or object instance . نمونه ئی از برخی کلاس ها
    *

    Object server . پردازه ای که مسئوليت ايجاد و ميزبانی نمونه هائی از برخی کلاس ها را برعهده دارد.
    *

    Client . پردازه ای است که متدی ازيک شی را فرا می خواند

  3. #3
    کاربرسایت PARS آواتار ها
    تاریخ عضویت
    ۸۷-۰۲-۲۵
    نوشته ها
    666
    سپاس ها
    0
    سپاس شده 0 در 0 پست

    Re: چالش های برنامه های توزيع شده

    مقايسه DCOM و CORBA
    دو استاندارد فوق از مدل سرويس گيرنده / سرويس دهنده برای ارتباطات خود استفاده می نمايند. در اين راستا سرويس گيرنده بمنظور اخذ يک سرويس ، متدی را توسط يک شی راه دور که بعنوان يک سرويس دهنده در مدل سرويس گيرنده / سرويس دهنده رفتار می نمايد ، فرا می خواند.سرويس ارائه شده توسط سرويس دهنده بصورت يک شی کپسوله می گردد. اينترفيس مربوط به شی توسط يک زبان تعريف اينترفيس (IDL) مشخص خواهد شد. اينترفيس های تعريف شده در يک فايل IDL بعنوان يک پيمان ارتباطی بين سرويس دهنده و سرويس گيرنده ايفای وظيفه می نمايد.سرويس گيرندگان با فراخوانی متدهای تشريح شده در IDL با سرويس دهنده ارتباط برقرار می نمايند.در اين راستا مدل و نحوه پياده سازی شی از ديدگاه سرويس گيرنده مخفی نگاه داشته می گردد. برخی از مفاهيم برنامه نويسی شی گراء نظير : Encapsulation,Polymorphism,Single inheritance در سطح IDL ارائه شده است . تکنولوژی CORBA در سطح IDL از ويژگی Multiple inheritance حمايت می کند.

    مدل ارتباطی بين يک پردازه سرويس گيرنده ويک شی سرويس دهنده در تکنولوژي های CORBA,DCOM ، تابع مدل مبتنی بر شی RPC است . شکل زير ساختار RPC را نشان می دهد.
    این عکس کوچک شده است برای مشاهده ی سایز اصلی کلیک کنید


    برای فراخوانی يک تابع راه دور ، سرويس گيرنده يک فراخوانی به Client Stub را انجام خواهد داد. Stub پارامترهای مربوط به فراخوانی تابع را در يک پيام درخواستی بسته بندی و يک Wire Protocol را بمنظور حمل پيام برای سرويس دهنده فرا می خواند. پس از حمل ، در سرويس دهنده ، پيام در اختيار Server stub گذاشته شده تا عمليات بازگشائی بسته ارسالی انجام و زمينه فراخوانی متدهای مربوط به شی مورد نظر فراهم گردد.در تکنولوژی DCOM ، وClient Stub بعنوان Proxy و Server Stub بعنوان Stub ناميده می شوند. در تکنولوژی CORBA ، و Client stub بعنوان stub و Server stub بعنوان Skeleton ناميده می گردد.


    تكنولوژی COM . مهمترين ويژگی تكنولوژی فوق قابليت استفاده مجدد و ارتباط متقابل براي عناصر( اشياء) توزيع شده است . بدين ترتيب پياده كنندگان نرم افزار اين امكان را پيدا خواهند كرد تا با در كنار هم قرار دادن اين عناصر و استفاده متعدد از آنان (حتي اگر توليدكنندگان آنها متفاوت باشند) ، قادر به خلق آثار ماندگار در سريعترين زمان ممكن و متكی بر اصول مهندسی نرم افزار باشند. تكنولوژی Com بصورت ناگهاني مطرح نگرديد و ريشه در تلاش هائی دارد كه از مدت ها قبل بعنوان يك نياز مطرح شده بود ، معرفي تكنولوژی OLE(Object Linking & Embedding) در سال ،1991 اولين تلاش در اين زمينه بود كه توسط شركت مايكروسافت برای ارتباط و پيوستگی بين مستندات مجموعه برنامه های آفيس مطرح گرديد. حوزه عملكرد تكنولوژی فوق بر روی مستندات ( Documents ) متمركزاست. در ادامه شركت مايكروسافت به اين نكته پی برد كه تكنولوژی فوق نبايد صرفا" متمركز بر روی مستندات باشد و مي تواند عملكردی جامع تر را داشته باشد. بدين منظور نسخه شماره 2 ، OLE در سال1995 مطرح گرديد و اين نسخه در ادامه تمامي عناصر و اجزای موجود در محيط ويندوز را شامل گرديد و بدين ترتيب COM مطرح شد. در اوايل ، تكنولوژی فوق در رابطه با عناصر و اجزای توزيع شده امكانات قابل توجه ای ارائه نكرده بود .شايد يكي از مهمترين دلايل آن ، عدم عرضه يك سيستم عامل شبكه ای از طرف مايكروسافت تا آن زمان بود.همزمان با عرضه ويندوز 95 و ويندوز NT در سال 1996 و مطرح شدن امكانات شبكه ای و ضرورت توزيع ، اجراء و ارتباط بين عناصر توزيع شده، تكنولوژی DCOM(Distributed COM) مطرح گرديد.سرانجام در سال 1997 نسخه توسعه يافته اين تكنولوژی با نام COM+ توسط شركت مايكروسافت ارائه گرديد.شکل زير معماری بکارگرفته شده درتکنولوژی DCOM را نشان می دهد.



    تكنولوژي CORBA . همزمان با گرايش بسمت طراحي و پياده سازی نرم افزارهاي متكي بر مدل N-Tier از يكطرف و نياز شديد به پياده سازي نرم افزار هاي متكی بر وب ، ضرورت توجه و بازنگری در نحوه طراحی و پياده سازی عناصر توزيع شده مورد اهتمام جدی شركت های بزرگ نرم افزاري قرار گرفت . شركت ماكروسافت در اين زمينه منادی تكنولوژی های COM/DCOM/COM+ ، Internet Explorer و ActiveX و ساير شرکت ها " کوربا" را مطرح كردند . اولين نسخه تکنولوژی فوق درسال 1992 توسط OMG كه بالغ بر ششصد عضو دارد، ارائه گرديد. آخرين نسخه آن ( نسخه شماره 2 ) در سال 1996 عرضه شده است . عملکرد تکنولوژی فوق شباهت زيادی به DCOM دارد. شکل زير معماری بکارگرفته شده در تکنولوژی فوق را نشان می دهد.



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

  4. #4
    کاربرسایت PARS آواتار ها
    تاریخ عضویت
    ۸۷-۰۲-۲۵
    نوشته ها
    666
    سپاس ها
    0
    سپاس شده 0 در 0 پست

    Re: چالش های برنامه های توزيع شده

    سرويس های وب : رويکرد جديد در برنامه های توزيع شده

    برای برنامه نويسی توزيع شده تاكنون متدلوژی های متفاوتی مطرح بوده است . سرويس های وب جديدترين رويکرد در اين زمينه می باشند. چرا با اين همه تنوع ، ما مجددا؛ به يك معماری جديد برای پردازش برنامه های توزيع شده نياز داريم ؟ چرا ما به سرويس های وب نياز داريم ؟ چرا خودمان را با يكی از متدهای موجود نظير RPC ، DCOM ، CORBA تطبيق نمی دهيم ؟ پاسخ به تمام سوالات فوق و موارد مشابه ظهور و رشد سريع اينترنت و وب است . در حقيقت اينرنت زمينه مناسب جهت تكامل برنامه های توزيع شده را فراهم نمود. تکنولوژی های پيش از اين، اغلب در شبكه های اختصاصی ايمن و اعتمادپذير مورد استفاده قرار می گرفتند.برنامه های توزيع شده كه بر روی اينترنت اجراء می گردند، دارای چالش های خاص خود بوده و با توجه به تنوع ، وسعت بسيار زياد و رشد فزاينده ، ضرورت وجود يك مدل جديد برای برنامه نويسی توزيع شده بدرستی احساس می گردد.

  5. #5
    کاربرسایت PARS آواتار ها
    تاریخ عضویت
    ۸۷-۰۲-۲۵
    نوشته ها
    666
    سپاس ها
    0
    سپاس شده 0 در 0 پست

    Re: چالش های برنامه های توزيع شده

    كالبد شكافی سرويس های وب

    سرويس های وب تصوير جديدی از برنامه های توزيع شده را ارائه داده اند . در اين راستا سه هدف عمده دنبال می شود :

    *

    برنامه ها بسادگی برنامه های ديگر بر روی وب را پيدا كرده و با آنها تبادل اطلاعاتی داشته باشند.
    *

    از تمامی توان اينترنت و پروتكل های مربوطه استفاده گردد.
    *

    يك متدولوژی ايمن برای تبادل اطلاعاتی را ارائه نمايد.

    در ادامه به بررسی نحوه تحقق هر يك از اهداف سه گانه فوق در تكنولوژی جديد سرويس های وب خواهيم پرداخت .

  6. #6
    کاربرسایت PARS آواتار ها
    تاریخ عضویت
    ۸۷-۰۲-۲۵
    نوشته ها
    666
    سپاس ها
    0
    سپاس شده 0 در 0 پست

    Re: چالش های برنامه های توزيع شده

    هدف اول :

    يكی از اولين مسائل موجود در رابطه با برنامه نويسی توزيع شده ، نياز به روشی جهت نمايش واستفاده از داده در برنامه ها است ، شايد يكي از اولين را ه حل های ممكن در اين خصوص طراحی يك ساختمان داده مشترك باشد كه تمامی برنامه ها جهت مبادله داده ها از آن استفاده و پيمان تفاهمی را امضاء كرده باشند ! . بديهی است در چنين وضعيتی تغيير در يك ساختمان داده ، مستلزم ايجاد تغييرات در برنامه هائی است كه بنوعی مصرف كننده داده های موجود در آن ساختمان داده هستند. مسئله فوق می تواند بعنوان يك مانع جدی جهت اعمال تغييرات در برنامه محسوب گردد. تمامی برنامه ها در اکثر اوقات می بايست، جهت استفاده از يك يا چند ساختمان داده به توافق رسيده باشند.و اين مسئله كوچكی نخواهد بود. XML پاسخی مناسب به اين نياز است . Xml يك متدولوژی مناسب برای استاندارد نمودن انتقال داده ها و رمز گشائی آنان است . يك فايل Xml ( يك مستند ) شامل داده ها و روشهای تشريح آنان است . بنابراين يك برنامه می تواند با دريافت يك فايل Xml قادر به تشخيص محتويات فايل و فورمت مربوط به المانهای داده ئی آن باشد. با استفاده از Xml ، فورمت داده ها می تواند تغيير كرده ، المانهای داده ئی تغيير ، افزايش و يا حتی حذف گردند، بدون اينكه نياز به انجام تغييرات در برنامه هائي باشيم كه از داده های فوق استفاده مي كنند. Xml شاه كليد طلائی سرويس های وب است . Xml الگوئی جهت تبادل داده ها بين برنامه ها و روتين هائی خواهد بود كه پايه و اساس آنها متكی بر سرويس های وب است . Xml يك عنصر استراتژيك در خط توليد محصولات شركت ما كروسافت بشمار مي آيد. اين عنصر حياتی هم در پروژه دات نت و هم در ساير محصولات شركت ماكروسافت نظير آفيس يك نقش محوری و تعيين كننده را برعهده دارد. با بهره گيری از تكنولوژی Xml برای تبادل داده ها يك بخش از جدول معمای سرويس های وب حل مي گردد.يكي ديگر از بخش های اين جدول معما ، يافتن پاسخی شايسته برای اين سوال است كه برنامه ها چگونه يكديگر را برای تبادل داده پيدا مي كنند؟در اغلب برنامه های توزيع شده و همچنين مدل سنتي Client Server ، برنامه ها مي بايست به روشنی و صراحت لهجه در رابطه با برنامه ها و روتين هائی كه می خواهند با آنها در ارتباط باشند ، آگاهي لازم را كسب نمايند . استفاده از درج كد بصورت مستقيم در متن برنامه ها ما را دچار مشكلاتی خواهد كرد كه در رابطه با تبادل داده ها نيز به آن اشاره شد. يعنی تغيير ساختار يك برنامه( برنامه توزيع شده ) كاری بس مشكل خواهد بود. تفكيك برنامه ها از يكديگر يكی از بزرگترين چالش ها و يكی از مهمترين رويكردها در رابطه با سرويس های وب است

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

    طراحی برنامه هائی از اين نوع ( مثال فوق ) با نگرش سرويس های وب ، اين سوال را مطرح مي سازد كه چگونه برنامه ها و روتين ها در يك محيط متكی بر سرويس های وب مي توانند يكديگر را پيدا نمايند؟چگونه برنامه موجود بر روی سرويس دهنده ( مثال فوق ) از محل برنامه ( روتين ) محاسبه ماليات آگاهی پيدا مي كند؟ برنامه های متكی بر معماری سرويس های وب با استفاده از دايركتوری ها (Directories) همديگر را پيدا خواهند كرد. نقش يك دايركتوري در دنيای سرويس های وب ، ارائه يك محل مركزي برای برنامه ها و روتين ها بگونه ای است كه آنها قادر به يافتن ساير برنامه ها و روتين های مورد نظر خود جهت ارتباط باشند. بموازات توسعه و فراگير شدن سرويس های وب ، مي توان اين انتظار را داشت كه چندين دايركتوری كه بر اساس نوع فعاليت خود ( Business ) طبقه بندی شده اند ، بوجود آيد مثلا؛ توليد كنندگان اتومبيل دارای يك دايركتوری مجزای از شركت های بيمه باشند. چه كسی مسئوليت توزيع و پشتيبانی اين نوع دايركتوريها را برعهده خواهد گرفت ؟ در برخی حالات يكی از شركت های فعال در يك خط تجاری خاص مي تواند اين مسئوليت را برعهده گيرد . مثلا؛ يك توليد كننده اتومبيل مي تواند يك دايركتوری را براي ساير اعضاي صنف خود ايجاد و پشتيباني نمايد و يا تمامی توزيع كنندگان اتومبيل مي توانند با يكديگر متحد و يك دايركتوری خاص ايجاد تا توسط تمامی توليد كنندگان اتومبيل مورد استفاده قرار گيرد. در حالات ديگر ، دايركتوری ها مي توانند Host گردنند و بعنوان يك حرفه جديد مورد توجه و مديريت قرار گيرند. مثلا؛ يك شركت تازه تاسيس مي تواند يك دايركتوری را بمنظور سرويس دهی به يك بخش خاص از فعاليت های تجاری پياده سازی و حق الزحمه خود را از ساير شركت هائی كه بهآن دستيابی دارند ، اخذ نمايد.پس از گذشت مدت زمانی ، قطعا" چندين دايركتوری با سرويس دهی مشابه در حرفه های گوناگون بوجود خواهد آمد و رقابت بين اين نوع از شركت ها بستر لازم جهت انتخاب را برای ساير شركت ها و موسسات تجاريی فراهم خواهد كرد.

    از بعد فني اين نوع از دايركتوری ها ( تطبيق سرويس های وب بايكديگر) با ساير دايركتوريهاي موجود مانند دايركتوريهائي جهت تاييد اعتبار كاربر و مديريت آنها نظير Active Directory در ويندوز و NDS ناول ، بسيار متفاوت خواهند بود.مثلا؛ دات نت ماكروسافت بگونه ای طراحي شده است كه قادر به تبعيت از استاندارد Universal Description Discovery and Integration(UDDI) ، باشد. UDDI يك ساختار مناسب تعريف شده برای يك برنامه است تا از يك طرف قادر به يافتن ساير برنامه ها بوده و از طرف ديگر به اين سوال پاسخ دهد كه خود چه سرويسی برای ارائه دادن به ساير برنامه ها را در اختيار دارد. با توجه به مثال گفته شده ( محاسبه ماليات ) ،برنامه فوق مي تواند يك دايركتوری را برای يافتن برنامه هائی كه جداول مالياتي و محاسباتی مربوطه را دراختيار دارند ، جستجو نمايد. دايركتوری ها يك روش مطمئن و اساسی جهت عملكرد برنامه ها بدون نياز به تغيير را ارائه مي دهند. (سخن دايركتوری به مخاطبان خود: من تغيير خواهم كرد ، شما لازم نيست تغيير كنی ، با خيال راحت كار خود را ادامه دهيد!)

    تا اينجا اين مسئله روشن شد كه چگونه Xml و دايركتوری های سرويس های وب برنامه نويسي توزيع شده را راحت تر كرده و يك زير ساخت مناسب جهت اين كاربا قابليت تسهيل در اعمال تغييرات قراهم شده است . بدون اتكاء به رويكرد فوق ، اضافه كردن يك Partner جديد و يا تغيير يك المان داده ئی مستلزم اعمال تغييرات زياد در تمامی برنامه ها در يك برنامه جامع توزيع شده است .

  7. #7
    کاربرسایت PARS آواتار ها
    تاریخ عضویت
    ۸۷-۰۲-۲۵
    نوشته ها
    666
    سپاس ها
    0
    سپاس شده 0 در 0 پست

    Re: چالش های برنامه های توزيع شده

    هدف دوم :

    اما چگونه مي توان اين سطح از دانش و تجربه را در محيط شبكه اي كه صرفا؛ قادر به درك مجموعه محدودي از پروتكل ها نظير Http , SMTP , FTP است ، معرفی و استفاده کرد؟ چگونه می توان يك تكنولوژی جديد در دنيائی مملو از سرويس دهندگان فايروال و Proxy را مطرح و عمومی نمود؟. پروتكل های موجود اينترنت برای انجام عمليات مورد نياز در محيط های متكي بر سرويس های وب اولا" به اندازه لازم انعطاف پذير نبوده و ثانيا" تعداد آنها محدود است . يك Partner نمي تواند صرفا" يك فايل Xml را بكمك پروتكل FTP برای يك Partner ديگر ارسال و در انتظار پاسخ مناسب باشد. SOAP(Simple Object Access Model) ، يك پروتكل متكي بر Xml بوده كه امكانات لازم جهت تبادل داده بين برنامه های هر partner با Partner ديگر را فراهم مي نمايد. از نكات جالب توجه پروتكل فوق مي توان به اين مسئله اشاره كرد كه امكان فعاليت بر روی ساير پروتكل های موجود اينترنت نظير Http , SMTP را دارا است . البته در اولين نسخه ای كه از پروتكل فوق پياده سازی مي گردد، استفاده بر روي Http مطرح شده است . بهرحال استفاده از SOAP بر روی Http ، سرويس های وب قادر به حركت بر روی اينترنت بدون نياز به اعمال تغييرات عمده در فايروال های موجود ، خواهند بود. از پروتكل SOAP ، علاوه براينكه براي انتقال داده های عمومی با فورمت Xml استفاده مي شود ، همچنين برای انتقال نوع خاصی از مستندات متكی بر Xml يعنی مستندات WSDL(Web Service Description Language) نيز استفاده مي گردد. مستنداتی از اين نوع جزئيات يك سرويس خاص ارائه شده توسط يك برنامه را تشريح و ساير اطلاعات ضروری در رابطه با نحوه ارتباط با برنامه را مشخص خواهند كرد. يك برنامه Partner ،برنامه ديگر را از طريق يك دايركتوری ، SOAP و WSDL بمنظور تعيين محدوديت ها و قوانين مربوط به گفتمان مشترك بين يك برنامه و برنامه ديگر ، آگاه مي سازد . ( عصر گفتگوی منطقی برنامه ها هم فرا رسيده است و برای آن چارچوب تعريف شده است ! ! ) . به مثال گفته شده برگرديم ، برنامه مالياتي مي تواند يك برنامه محاسبه مالياتی را براساس يك دايركتوری پيدا كند در ادامه از طريق پروتكل SOAP يك فايل WSDL را ارسال تا متوجه شود كه برنامه فوق چه نوع عمليات خاصی را مي تواند انجام و در صورت لزوم چه نوع داده ئی را مي بايبست مبادله نمايد.

  8. #8
    کاربرسایت PARS آواتار ها
    تاریخ عضویت
    ۸۷-۰۲-۲۵
    نوشته ها
    666
    سپاس ها
    0
    سپاس شده 0 در 0 پست

    Re: چالش های برنامه های توزيع شده

    هدف سوم :

    تصور اين موضوع كه ما مي خواهيم تمامی فعاليت های تجاری خود را بهمراه مسائل شخصی از طريق سرويس های وب در اينترنت انجام دهيم ، شايد تا اندازه ای نگران كننده باشد. اگر سرويس های وب مي خواهند جايگاهي بلند مرتبه را پيدا نمايند ، قبل از هر چيز مي بايست متدولوژيهای امنيتي قابل قبولی را ارائه نمايند. ماكروسافت در اين زمينه ايده جالب ، استفاده از متدولوژيهای تاييد اعتبار كاربر كه توسط IIS ارائه شده است را، مطرح كرده است . در دنيای دات نت برنامه های Partner مي بايست دارای اعتبارنامه معتبر و تصويب شده در مجلس IIS باشند. اعتبارنامه ها مي تواند بر اساس NT Lanmanager(NTLM) و يا Kerberos ( Active Directory ) باشند . اگر با يك نگاه منصفانه به مدل ارائه شده توسط شركت ماكروسافت نظری داشته باشيم ، در خواهيم يافت كه نوعی اطمينان از تاييد با مركزيت IIS بوجود خواهد آمد كه از يكطرف توانائی و از سوی ديگر انعطاف پذيری سرويس های وب را بيشتر خواهد كرد. چراكه برنامه هاي Partner ،مي بايست با شفافيت بدانند كه چگونه توسط برنامه های ديگر تاييد گردند. در حال حاضر يك مكانيزم قابل قبول و انعطاف پذير برای بدست آوردن يك مجوز عمومي ( جواز عمومي ) از يك منبع مستقل بين المللي وجود ندارد تا برنامه ها با اتكاء به آن همديگر را باور و تاييد نمايند.

    امنيت در دات نت زمانيكه نگاه خود را بر روي سرويس گيرندگان متمركز نمائيم ، قابل تامل است . چون سرويس هاي وب مي بايست بصورت يكسان و يكنواخت طراحي گردند تا بتوانند خدمات متكي بر سرويس گيرندگان را ارائه نمايند، داشتن يك روش تاييد صلاحيت براي سرويس گيرنده كه چندين برنامه موجود بر روي سرويس گيرنده را به به سرويس دهي فرا خواهد خواند ، بسيار مهم بوده و اگر چنين مدلي اين امكان را فراهم آورد كه كاربري يك بار تاييد گردد و صلاحيت آن در طول چندين برنامه موجود بر روي سرويس دهنده تاييد گردد بمراتب بهتر خواهد بود ( عالي است ! ) هدف محصول Passport شركت ماكروسافت تاييدي بر انعطاف پذيري سرويس گيرندگان است كه خود بخشي از پروژه بزرگ دات نت است . هدف Passport تاييد يك كاربر از طريق يك مرورگر وب و ارسال اعتبارنامه وی برای چندين برنامه است كه بر روی سرويس دهنده مشغول ارائه خدمات مي باشند. در حقيقت محصول فوق زمينه پيدايش فدراسيون برنامه ها ی كامپيوتري را فراهم كرده تا بدين طريق سرويس گيرندگانی كه بنوعی تاييد می گردنند ، صلاحيت استفاده از تمامی برنامه های موجود در فدراسيون را خواهند داشت .عليرغم برخی انتقادات كه به اين محصول شركت ماكروسافت انجام شده است ( منتقدين مي گويند كه با اين كار شركت ماكروسافت نمامي كاربران Online شبكه را كنترل مي كند) اين شركت همچنان بر آن مهر تاييد زده و آن را بعنوان يك بخش اساسی در پروژه دات نت خود قلمداد مي كند. ماكروسافت حتی بدنبال افزايش قابليت هايی Passport بگونه ای است كه تمامي محصولات خود را تحت پوشش قرار دهد. شايد در آينده اعتبارنامه Passport در Active Directory ذخيره و مجوزی برای استفاده از محصولات اين شركت هم باشد.

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

اطلاعات موضوع

کاربرانی که در حال مشاهده این موضوع هستند

در حال حاضر 1 کاربر در حال مشاهده این موضوع است. (0 کاربران و 1 مهمان ها)

موضوعات مشابه

  1. پاسخ ها: 0
    آخرين نوشته: چهارشنبه ۱۷ شهریور ۸۹, ۱۸:۰۸
  2. احتمال توزيع يارانه نقدي از زمستان
    توسط hrg1356 در انجمن بایگانی اخبار اقتصادی
    پاسخ ها: 0
    آخرين نوشته: چهارشنبه ۱۳ آبان ۸۸, ۲۲:۱۷
  3. علل نابرابري توزيع درآمدها
    توسط hamid192 در انجمن اقتصاد
    پاسخ ها: 0
    آخرين نوشته: دوشنبه ۱۴ بهمن ۸۷, ۲۱:۲۰
  4. پاسخ ها: 0
    آخرين نوشته: دوشنبه ۲۲ مهر ۸۷, ۲۰:۳۷
  5. واكسن آنفلوآنزا در داروخانههاي كشور توزيع شد
    توسط M.MEDICAL در انجمن اخبار پزشکی
    پاسخ ها: 0
    آخرين نوشته: جمعه ۳۰ شهریور ۸۶, ۰۱:۲۰

مجوز های ارسال و ویرایش

  • شما نمیتوانید موضوع جدیدی ارسال کنید
  • شما امکان ارسال پاسخ را ندارید
  • شما نمیتوانید فایل پیوست کنید.
  • شما نمیتوانید پست های خود را ویرایش کنید
  •