تبلیغات
دانشگاه علوم وفنون مازندران مهندسی صنایع - سیر تکامل پردازش های توزیع شده
 
دانشگاه علوم وفنون مازندران مهندسی صنایع
موفقیت یعنى سازگارى با حوادث روزگار
                                                        
درباره وبلاگ

مدیریت وب سایت:
مهندس محمد جواد مهدوی
کارشناس برنامه ریزی و کنترل پروژه (با استفاده از
نرم افزارهای primavera&Microsoft Project)
کارشناس مدیریت ریسک پروژه (با استفاده از نرم افزار permaster)
کارشناسی:مهندسی صنایع – برنامه ریزی و تحلیل سیستمها
دانشگاه علوم و فنون مازندران
کارشناسی ارشد: مهندسی صنایع - صنایع
دانشگاه آزاد قزوین
----------------------------------------------------
Engineer Mohammad Javad Mahdavi
Expert:Project Planning & Control
(Oil & Gas & Construction Projects)
Email : Mohammadjavad.mahdavi@yahoo.com
Web Site : http://mjm0123.mihanblog.com
مدیر وبلاگ : محمد جواد مهدوی
نظرسنجی
نمره شما به وبلاگ من چند میتونه باشه؟







آمار وبلاگ
  • کل بازدید :
  • بازدید امروز :
  • بازدید دیروز :
  • بازدید این ماه :
  • بازدید ماه قبل :
  • تعداد نویسندگان :
  • تعداد کل پست ها :
  • آخرین بازدید :
  • آخرین بروز رسانی :
از گذشته تا کنون دو مدل اساسی  در پردازش های توزیع شده مورد توجه قرار گرفته است . 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 و CORBACommon Object Request Broker Architecture ، مدل های استاندارد شده در این زمینه می باشند.

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

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

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

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

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

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

مقایسه 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 دارد. شکل زیر معماری بکارگرفته شده در تکنولوژی فوق را نشان می دهد.

 مشاهده تصویر با ابعاد بزرگتر

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

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

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

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

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

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

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

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

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

هدف اول :

یكی از اولین مسائل موجود در رابطه با برنامه نویسی توزیع شده ، نیاز به روشی جهت نمایش واستفاده از داده  در برنامه ها است ،  شاید یكی از اولین را ه حل های ممكن در این خصوص طراحی یك ساختمان داده مشترك باشد كه تمامی برنامه ها جهت مبادله داده ها از آن استفاده و  پیمان تفاهمی را امضاء كرده باشند ! . بدیهی است در چنین وضعیتی تغییر در یك ساختمان داده ، مستلزم ایجاد تغییرات در برنامه هائی است كه بنوعی مصرف كننده داده های موجود در آن ساختمان داده هستند. مسئله فوق می تواند بعنوان یك مانع جدی جهت اعمال تغییرات در برنامه محسوب گردد. تمامی برنامه ها در اکثر اوقات می بایست، جهت استفاده از یك یا چند ساختمان داده به توافق رسیده باشند.و این مسئله كوچكی نخواهد بود. 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 جدید و یا تغییر یك المان داده ئی مستلزم اعمال تغییرات زیاد در تمامی برنامه ها در یك برنامه جامع توزیع شده است .

هدف دوم : 

اما چگونه می توان این سطح از دانش و تجربه را در محیط شبكه ای كه صرفا؛ قادر به درك مجموعه محدودی از پروتكل ها نظیر 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 را ارسال تا متوجه شود كه برنامه فوق چه نوع عملیات خاصی را می تواند انجام  و در صورت لزوم  چه نوع داده ئی را می بایبست  مبادله نماید.

هدف سوم : 

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

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

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





نوع مطلب : مهندسی صنایع، 
برچسب ها :
لینک های مرتبط :




دوشنبه 30 مرداد 1396 02:52 ب.ظ
excellent put up, very informative. I wonder why the opposite experts of
this sector don't notice this. You should continue your writing.

I am confident, you have a great readers' base already!
یکشنبه 24 اردیبهشت 1396 10:34 ب.ظ
Hey there, You've done an incredible job. I'll definitely digg it and personally suggest to my friends.
I am sure they'll be benefited from this web site.
 
لبخندناراحتچشمک
نیشخندبغلسوال
قلبخجالتزبان
ماچتعجبعصبانی
عینکشیطانگریه
خندهقهقههخداحافظ
سبزقهرهورا
دستگلتفکر