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

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

منبع:  http://www.srco.ir/tutorial/Component.asp