تبیان، دستیار زندگی

در قسمت قبل این مقاله دیدید که چگونه به کمک وب سرویس گوگل در وب جستجو می کنیم. در قسمت دوم خواهیم دید که چگونه می توان یک موتور جستجوی شبه گوگل ایجاد کرد.

ساختن یک موتور جستجوی کاربردی تر

برای ساختن یک موتور جستجوی کاربردی تر با وب سرویس گوگل، اجازه دهید تا یک صفحه وب ASP.NET بسازیم که به کاربر امکان وارد کردن عبارت مورد جستجو و همچنین صفحه بندی داده های بدست آمده از جستجو را بدهد. یک راه برای انجام این کار، تقلید از گوگل است به این معنی که کلمه مورد جستجو و شماره صفحات را در Query String قرار دهیم. به عنوان مثال اگر کاربر کلمه "ASP" را جستجو کند و 10 نتیجه از 20 نتیجه بدست آمده نمایش داده شود، آدرس درخواستی چیزی شبیه به این خواهد بود :
< BR>http://www.yourserver.com/Search.aspx?q=ASP&first=10&last=20

یک انتخاب دیگر استفاده از postback است. اما استفاده از Query String این حسن را دارد که کاربر می تواند نتایج یک جستجوی خاص را bookmark کند (توجه کنید که در روش postback به دلیل استفاده از هدرهای HTTP POST، آدرس و Query string موقع جستجو یا صفحه بندی نتایج تغییری نمی کنند).

با وجود مزیت bookmark شدن در روش Query String من تصمیم گرفتم تا کار را به کمک Postback در وب فرم ها انجام دهم، اما شما اگر بخواهید، می توانید روش Query String را تعریف و استفاده کنید. سورس کد روش Postback را در زیر مشاهده می کنید :

مهمترین و اصلی ترین و پر کارترین تابع در کد بالا DisplaySearchResults است که وب سرویس را فراخوانی می کند، داده ها را به دیتالیست مقید ( bind ) می کند و اطلاعات متفرقه در مورد نتیجه پیدا شده مثل عدد تخمینی تعداد نتایج، زمان اجرای کوئری و... را نمایش می دهد. این تابع همچنین فعال یا غیر فعال بودن دکمه لینکی مربوط به صفحه بندی نتایج را مشخص می کند.

هنگامی که وب سرویس را فراخوانی می کنیم، باید شاخص شروع نتایج و نیز تعداد نتایجی که می خواهیم در یک صفحه ببینیم را مشخص کنیم. برای اینکه 10 رکورد اول نتایج جستجو را ببینیم، عدد صفر را به عنوان شاخص شروع و عدد 10 را به عنوان تعداد رکوردهای بازگشتی پاس می کنیم. برای دیدن 10 نتیجه بعدی، فقط کافی است که عدد 10 را به عنوان شاخص شروع پاس کنیم (تعداد رکوردهای بازگشتی در این حالت هم همان 10 تاست). توجه کنید که ViewState برای مدیریت عدد شاخص شروع به کار رفته است. تعداد رکوردهایی که در هر صفحه نمایش داده می شوند توسط ثابت PAGE_SIZE مشخص می شود.

برای امکان صفحه بندی نتایج از دو دکمه لینکی استفاده شده است که وقتی روی آن ها کلیک می شود هندلرهای nextRecs و prevRecs شروع به کار می کنند. این هندلرها تنها عدد شروع رکوردها را به روز رسانی کرده و سپس DisplaySearchResults() را فراخوانی می کنند.

یک نکته مهم در رابطه با وب سرویس گوگل :

API وب سرویس گوگل در حال حاضر در مرحله تست بتا قرار دارد و تنها برای مصارف شخصی آماده شده است، برای محدود کردن استفاده افراطی، گوگل از استفاده کنندگان این سرویس می خواهد تا یک license key منحصر به فرد داشته باشند (که به صورت مجانی قابل دریافت است)، توضیح روش دریافت license key در قسمت اول این مقاله آمده است . این license key برای محدود کردن فراخوانی وب سرویس به کمتر از 1000 بار در روز استفاده می شود.

منبع: Searching Google Using the Google Web Service

کسانی که با صنعت IT آشنایی دارند حتما ً نام وب سرویس را شنیده اند. برای مثال، بیش از ۶۶ درصد کسانی که در نظر سنجی مجله InfoWorld شرکت کرده بودند بر این توافق داشتند که وب سرویس ها مدل تجاری بعدی اینترنت خواهند بود. به علاوه گروه گارتنر پیش بینی کرده است که وب سرویس ها کارآیی پروژه های IT را تا ۳۰ در صد بالا می برد. اما وب سرویس چیست و چگونه شکل تجارت را در اینترنت تغییر خواهد داد؟

برای ساده کردن پردازش های تجاری، برنامه های غیرمتمرکز (Enterprise) باید با یکدیگر ارتباط داشته باشند و از داده های اشتراکی یکدیگر استفاده کنند. قبلا ً این کار بوسیله ابداع استانداردهای خصوصی و فرمت داده ها به شکل مورد نیاز هر برنامه انجام می شد. اما دنیای وب و XML تکنولوژی آزاد برای انتقال دیتا انتقال اطلاعات بین سیستم ها را افزایش داد. وب سرویس ها نرم افزارهایی هستند که از XML برای انتقال اطلاعات بین نرم افزارهای دیگر از طریق پروتکل های معمول اینترنتی استفاده می کنند. به شکل ساده یک وب سرویس از طریق وب اعمالی را انجام می دهد (توابع یا سابروتین ها) و نتایج را به برنامه دیگری می فرستد. این یعنی برنامه ای که در یک کامپیوتر در حال اجراست اطلاعاتی را به کامپیوتردیگری می فرستد و از آن درخواست جواب می کند. برنامه ای که در آن کامپیوتر دوم است کارهای خواسته شده را انجام می دهد و نتیجه را بر روی ساختارهای اینترنتی به برنامه اول برمی گرداند.

وب سرویس ها می توانند از پروتکل های زیادی در اینترنت استفاده کنند اما بیشتر از HTTP که مهم ترین آنهاست استفاده می شود. وب سرویس هر نوع کاری می تواند انجام دهد. برای مثال در یک برنامه می تواند آخرین عنوان های اخبار را از وب سرویس Associated Press بگیرد یا یک برنامه مالی می تواند آخرین اخبار و اطلاعات بورس را از طریق وب سرویس بگیرد. کاری که وب سرویس انجام می دهد می تواند به سادگی ضرب دو عدد یا به پیچیدگی انجام کلیه امور مشترکین یک شرکت باشد.

وب سرویس دارای خواصی است که آن را از دیگر تکنولوژی ها و مدل های کامپیوتری جدا می کند. Paul Flessner، نایب رییس مایکروسافت در dot NET Enterprise Server چندین مشخصه برای وب سرویس در یکی از نوشته هایش ذکر کرده است. اول اینکه وب سرویس ها قابل برنامه ریزی هستند. یک وب سرویس کاری که می کند را در خود مخفی نگه می دارد. وقتی برنامه ای به آن اطلاعات داد وب سرویس آن را پردازش می کند و در جواب آن اطلاعاتی را به برنامه اصلی بر می گرداند. دوم، وب سرویس ها بر پایه XML بنا نهاده شده اند. XML و XML های مبتنی بر SOAP یا Simple Object Access Protocol تکنولوژی هایی هستند که به وب سرویس ها این امکان را می دهد که با دیگر برنامه ها ارتباط داشته باشد حتی اگر آن برنامه ها در زبانهای مختلف نوشته شده و بر روی سیستم عامل های مختلفی در حال اجرا باشند.

همچین وب سرویس ها خود-توصیف هستند. به این معنی که کاری را که انجام می دهند و نحوه استفاده از خودشان را توضیح می دهند. این توضیحات به طور کلی در WSDL یا Web Services Description Language نوشته می شود. WSDL یک استاندارد بر مبنای XML است. به علاوه وب سرویس ها قابل شناسایی هستند به این معنی که برنامه نویس می تواند به دنبال وب سرویس مورد علاقه در دایرکتوری هایی مثل UDDI یا Universal Description , Discovery and Integration جستجو کند. UDDI یکی دیگر از استاندارد های وب سرویس است.

نکات تکنولوژی وب سرویس
همانطور که در ابتدا توضیح داده شد یکی از دلایل اینکه وب سرویس از دیگر تکنولوژی های موجود مجزا شده است استفاده از XML و بعضی استاندارد های تکنیکی دیگر مانند SOAP، WSDL و UDDI است. این تکنولوژی ها زمینه ارتباط بین برنامه ها را ایجاد می کنند به شکلی که مستقل از زبان برنامه نویسی، سیستم عامل و سخت افزار است. SOAP یک مکانیزم ارتباطی را بین نرم افزار و وب سرویس ایجاد می کند. WSDL یک روش یکتا برای توصیف وب سرویس ایجاد می کند و UDDI یک دایرکتوری قابل جستجو برای وب سرویس می سازد. وقتی اینها با هم در یک جا جمع می شوند این تکنولوژی ها به برنامه نویس اجازه می دهد که برنامه های خود را به عنوان سرویس آماده کرده و بر روی اینترنت قرار دهد.

XML یا eXtensible Markup Language
XML یک تکنولوژی است که به شکل گسترده از آن پشتیبانی می شود، همچنین این تکنولوژی Open است به این معنی که متعلق به شرکت خاصی نیست. اولین بار در کنسرسیوم WWW یا W3C در سال ۱۹۹۶ برای ساده کردن انتقال دیتا ایجاد شده است. با گسترده شدن استفاده از وب در دهه ۹۰ کم کم محدودیت های HTML مشخص شد. ضعف HTML در توسعه پذیری (قابلیت اضافه و کم کردن خواص) و ضعف آن در توصیف دیتاهایی که درون خود نگهداری می کند برنامه نویسان را از آن ناامید کرد. همچنین مبهم بودن تعاریف آن باعث شد از توسعه یافتن باز بماند. در پاسخ به این اشکالات W3C یک سری امکانات را در جهت توسعه HTML به آن افزود که امکان تغییر ساختار متنهای HTML مهم ترین آن است. این امکان را CSS یا Cascade Style Sheet می نامند.

این توسعه تنها یک راه موقتی بود. باید یک روش استاندارد شده، توسعه پذیر و دارای ساختار قوی ایجاد می شد. در نتیجه W3C استاندارد XML را ساخت. XML دارای قدرت و توسعه پذیری SGML یا Standard Generalized Markup Language و سادگی که در ارتباط در وب به آن نیاز دارد است.

استقلال اطلاعات یا جدا بودن محتوا از ظاهر یک مشخصه برای XML به حساب می آید. متنهای XML فقط یک دیتا را توصیف می کنند و برنامه ای که XML برای آن قابل درک است بدون توجه به زبان و سیستم عامل قادر است به اطلاعات درون فایل XML هر گونه شکلی که مایل است بدهد. متنهای XML حاوی دیتا هستند بدون شکل خاص، بنابراین برنامه ای که از آن می خواهد استفاده کند باید بداند که چگونه می خواهد آن اطلاعات را نمایش دهد. بنابراین نحوه نمایش یک فایل XML در یک PC با PDA و تلفن همراه می تواند متفاوت باشد.

وقتی یک برنامه با متن XML مواجه می شود باید مطمئن باشد که آن متن حاوی دیتای مورد نظر خود است. این اطمینان توسط برنامه هایی با نام XML Parser حاصل می شود. تجزیه کننده ها دستورات متن XML را بررسی می کنند. همچنین آنها به برنامه کمک می کنند تا متن های XML را تفسیر کند. به صورت اختیاری هر متن XML می تواند به متن دیگری اشاره کند که حاوی ساختار فایل XML اصلی باشد. به آن متن XML دوم DTD یا Document Type Definition گفته می شود.

وقتی فایل XML به DTD اشاره می کند برنامه تجزیه کننده فایل اصلی را با DTD بررسی می کند که آیا به همان ساختاری که در DTD توصیف شده شکل گرفته است یا خیر. اگر یک تجزیه کننده XML بتواند یک متن را به درستی پردازش کند متن XML نیز به شکل صحیحی فرمت شده است.

وقتی که اکثر نرم افزارها امکانات وبی خود را افزایش دادند این طور به نظر می رسد که XML به عنوان یک تکنولوژی جهانی برای فرستادن اطلاعات بین برنامه ها انتخاب شود. تمامی برنامه هایی که از XML استفاده می کنند قادر خواهند بود که XML ِ همدیگر را بفهمند. این سطح بالای تطابق بین برنامه ها باعث می شود که XML یک تکنولوژی مناسب برای وب سرویس باشد. چون بدون اینکه احتیاج به سیستم عامل و سخت افزار یکسان باشد می تواند اطلاعات را جابجا کند.

SOAP یا Simple Object Access Protocol
SOAP یکی از عمومی ترین استاندارد هایی است که در وب سرویس ها استفاده می شود. طبق شواهد اولین بار توسط DeveloperMentor، شرکت UserLand و مایکروسافت در سال ۱۹۹۸ ساخته شده و نسخه اول آن در سال ۱۹۹۹ ارایه شده است. آخرین نسخه SOAP، نسخه 1.2 بود که در دسامبر سال ۲۰۰۱ در W3C ارایه شد. نسخه 1.2 نشان دهنده کار زیاد بر روی آن و نمایانگر اشتیاق زیاد صنعت IT برای استفاده از SOAP و وب سرویس است.

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

به عنوان یک پروتکل مبتنی بر XML، پروتکل SOAP تشکیل شده از یک سری الگوهای XMLی است. این الگوها شکل پیغام های XML را که بر روی شبکه منتقل می شود را مشخص می کند. مانند نوع دیتاها و اطلاعاتی که برای طرف مقابل تفسیر کردن متن را آسان کند. در اصل SOAP برای انتقال دیتا بر روی اینترنت و از طریق پروتکل HTTP طراحی شده است ولی از آن در دیگر مدلها مانند LAN نیز می توان استفاده کرد. وقتی که وب سرویس ها از HTTP استفاده می کنند به راحتی می توانند از Firewall عبور کنند.

یک پیغام SOAP از سه بخش مهم تشکیل شده است: پوشش یا Envelope ،Header، بدنه یا Body. قسمت پوشش برای بسته بندی کردن کل پیغام به کار می رود. این بخش محتوای پیغام را توصیف و گیرنده آن را مشخص می کند. بخش بعدی پیغام های SOAP، Header آن است که یک بخش اختیاری می باشد و مطالبی مانند امنیت و مسیریابی را توضیح می دهد. بدنه پیغام SOAP بخشی است که دیتاهای مورد نظر در آن جای می گیرند. دیتاها بر مبنای XML هستند و از یک مدل خاص که الگوها (Schemas) آن را توضیح می دهند تبعیت می کنند. این الگو ها به گیرنده کمک می کنند تا متن را به درستی تفسیر کند. پیغام های SOAP توسط سرورهای SOAP گرفته و تفسیر می شود تا در نتیجه آن، وب سرویس ها فعال شوند و کار خود را انجام دهند.

برای اینکه از SOAP در وب سرویس استفاده نکنیم از تعداد زیادی پروتکل باید استفاده شود. برای مثال XML-RPC تکنولوژی قدیمی تری بود که همین امکانات را ایجاد می کرد. به هر حال، خیلی از سازندگان بزرگ نرم افزار SOAP را بر تکنولوژی های دیگر ترجیح دادند. دلایل زیادی برای انتخاب SOAP وجود دارد که خیلی از آنها درباره پروتکل آن است که فراتر از این متن می باشد. سه برتری مهم SOAP نسبت به تکنولوژی های دیگر عبارتند از قابلیت توسعه، سادگی و قابلیت عملکرد داخلی.

پیغام های SOAP معمولا ً کدهای زیادی ندارند و برای فرستادن و گرفتن آن به نرم افزارهای پیچیده نیاز نیست. SOAP این امکان را به برنامه نویس می دهد تا بنا به نیاز خود آن را تغییر دهد. در آخر بدلیل اینکه SOAP از XML استفاده می کند می تواند بوسیله HTTP اطلاعات را انتقال بدهد بدون اینکه زبان برنامه نویسی، سیستم عامل و سخت افزار برای آن مهم باشد.

WSDL یا Web Services Description Language
استاندارد دیگری که نقش اساسی در وب سرویس بازی می کند WSDL است. همانطور که قبلا ً اشاره کردیم یکی از خواص وب سرویس ها توصیف خود آنهاست به این معنی که وب سرویس دارای اطلاعاتی است که نحوه استفاده از آن را توضیح می دهد. این توضیحات در WSDL نوشته می شود، متنی به XML که به برنامه ها می گوید این وب سرویس چه اطلاعاتی لازم دارد و چه اطلاعاتی را بر می گرداند.

وقتی که سازندگان نرم افزار برای اولین بار SOAP و دیگر تکنولوژی های وب سرویس را ساختند دریافتند که برنامه ها قبل از اینکه شروع به استفاده از یک وب سرویس بکنند باید اطلاعاتی درباره آن را داشته باشند. اما هر کدام از آن سازندگان برای خودشان روشی برای ایجاد این توضیحات ابداع کردند و باعث شد که وب سرویس ها با هم هماهنگ نباشد. وقتی IBM و مایکروسافت تصمیم گرفتند تا استاندارد های خود را یکسان کنند WSDL بوجود آمد. در ماه مارس سال ۲۰۰۱ مایکروسافت، IBM و Ariba نسخه 1.1 را به W3C ارائه کردند. گروهی از W3C بر روی این استاندارد کار کردند و آن را پذیرفتند. هم اکنون این تکنولوژی در دست ساخت است و هنوز کامل نشده. ولی هم اکنون اکثر سازندگان وب سرویس از آن استفاده می کنند.

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

این مهم است که بدانیم WSDL برای برنامه ها طراحی شده است نه برای خواندن آن توسط انسان. شکل فایلهای WSDL پیچیده به نظر می آید ولی کامپیوترها می توانند آن را بخوانند و تجزیه و تحلیل بکند. خیلی از نرم افزارهایی که وب سرویس می سازند فایل WSDL مورد نیاز وب سرویس را نیز تولید می کنند بنابراین وقتی برنامه نویس وب سرویس خود را ساخت به شکل خودکار WSDL مورد نیاز با آن نیز ساخته می شود و احتیاجی به آموزش دستورات WSDL برای ساختن و استفاده از وب سرویس نیست.

UDDI یا Universal Description , Discovery and Integration
سومین استاندارد اصلی وب سرویس ها، یعنی UDDI، به شرکتها و برنامه نویسان اجازه می دهد تا وب سرویس های خود را بر روی اینترنت معرفی کنند. این استاندارد در اصل بوسیله مایکروسافت، IBM و Ariba و پنجاه شرکت بزرگ دیگر ساخته شده است. با استفاده از UDDI شرکتها می توانند اطلاعات خود را در اختیار شرکت های دیگر قرار بدهند و مدل B2B ایجاد کنند. همان طور که از نام آن مشخص است شرکت ها می توانند وب سرویس خود را معرفی کنند، با وب سرویس دیگران آشنا شوند و از آن در سیستم های خود استفاده کنند. این استاندارد جدیدی است و در سال ۲۰۰۰ ساخته شده است و کنسرسیومی از شرکتهای صنعتی در حال کار بر روی آن هستند. نسخه دوم UDDI در ماه ژوئن سال ۲۰۰۱ ارائه شد و نسخه سوم آن در دست ساخت است.

UDDI یک متن مبتنی بر XML را تعریف می کند که در آن شرکت ها توضیحاتی درباره چگونگی کار وب سرویس شرکتشان و امکانات خود می دهند. برای تعریف این اطلاعات از شکل خاصی که در UDDI توضیح داده شده استفاده می شود. شرکت ها می توانند این اطلاعات را در UDDI شرکت خود نگهداری کنند و تنها به شرکت های مورد نظرشان اجازه دستیابی به آنها را بدهند یا آنها را در مکان عمومی و در اینترنت قرار دهند.

بزرگترین و مهمترین پایگاه UDDI پایگاه UDDI Business Registry یا UBR نام دارد و توسط کمیته UDDI طراحی و اجرا شده است. اطلاعات این پایگاه در چهار نقطه نگهداری می شود: مایکروسافت، IBM، SAP و HP. اطلاعاتی که در یکی از چهار پایگاه تغییر کند در سه تای دیگر نیز اعمال می شود.

اطلاعات درون این پایگاه ها شبیه دفترچه تلفن است. White Pages که در آنها اطلاعات تماس شرکت ها و توضیحات متنی آنهاست، Yellow Pages حاوی اطلاعات طبقه بندی شده شرکتها و اطلاعات درباره توانایی های الکترونیکی آنها می باشد، Green Pages، حاوی اطلاعات تکنیکی درباره سرویس های آنها و نحوه پردازش اطلاعات شرکت آنها می باشد.

اطلاعات تجاری و سرویس های شرکت ها کاملا ً طبقه بندی شده است و اجازه می دهد که به راحتی در آنها جستجو کرد. سپس متخصصان IT می توانند از این اطلاعات استفاده کرده و شرکت ها را برای خدمات بهتر به هم متصل کنند. با این شرح UDDI امکان پیاده سازی مدل B2B را ایجاد می کند و شرکتها می توانند از سرویس های یکدیگر استفاده کنند.

شرکت هایی که به UDDI علاقه نشان داده اند قدرتمند هستند و خیلی از آنها از وب سرویس و استانداردهای آن در محصولات خود استفاده می کنند. NTT Communications of Tokyo یکی از شرکت هایی است که در حال اضافه کردن توضیحاتی به ساختار UDDI است. در هر حال حاضر شرکت ها هنوز کمی درباره وارد کردن خود در پایگاه های عمومی محتاط هستند. این چیز عجیبی نیست. شرکتها ابتدا این امکانات را فقط برای شرکای خود ایجاد می کنند. شرکتهای بزرگ نیز برای مدیریت بر سرویس های خود و اشتراک آنها بین قسمت های مختلف از این استاندارد استفاده می کنند. وقتی این استاندارد به حد بلوغ خود برسد و کاربران با آن احساس راحتی بکنند استفاده از آن نیز در مکان های عمومی فراگیر خواهد بود.

این تغییر رویه برای شرکت های بزرگی که B2B را به روش های قدیمی اجرا کرده بودند مشکل است. بعضی نیز اشکال امنیتی بر این روش می گیرند و مایل نیستند اطلاعاتشان را بدهند. اما با گذشت زمان و کامل شدن این تکنولوژی و درک لزوم استفاده از آن شرکت ها چاره ای جز استفاده از آن ندارند.

متن اصلی از سایت http://www.deitel.com گرفته شده است.

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

تكامل تدریجی سرویس های وب
تكنولوژی سرویس های وب در حقیقت یك تكامل تدریجی در برنامه نویسی توزیع شده است نه یك انقلاب! بمنظور شناخت بهتر سرویس های وب لازم است كه به دو مدل رایج كه در پردازش های توزیع شده از آنها استفاده می شود یعنی Remote Procedure Call یا RPC و Client Server نگاهی اجمالی داشته باشیم.

ارتباطات مبتنی بر RPC نسبت به Client Server دارای قدمت بیشتری بوده و بعنوان شاه كلید برنامه های توزیع شده در محیط یونیكس مطرح بوده است. یونیكیس یكی از اولین سیستم های عامل در زمینه استفاده كامل از امكانات ارتباطی پروتكل TCP/IP است. پروتكل فوق بهمراه استانداردهای مربوطه آن بعنوان ستون فقرات شبكه های مبتنی بر یونیكس مطرح بوده است. مثلا استاندارد Domain Name System یا DNS جهت همترازی آدرس یك كامپیوتر و نام آن، File Transfer Protocol یا FTP امكانی جهت تبادل فایل ها و پروتكل TelNet ارائه دهنده تسهیلاتی جهت دستابی به ترمینال ها. اگر امروز ما در دنیائی زندگی می كنیم كه پروتكل TCP/IP محور اساسی گفتمان در شبكه های كامپیوتری قرار گرفته است، بیش از بیست سال قبل یونیكیس چنین وضعیتی را درا بوده است. برنامه نویسان تحت یونیكیس بخوبی از توانائی های آن برای نوشتن برنامه های توزیع شده استفاده كرده اند. برنامه نویسان فوق از ارتباطات مبتنی بر Socket جهت نیل به اهداف خود استفاده می كردند. بر اساس رویكرد فوق اگر برنامه ای قصد ارتباط با برنامه دیگری را داشت بر اساس آدرس TCP/IP و یك شماره پورت یك لینك با آن برنامه ایجاد می كرد. این رویكرد تا مدت ها بعنوان یك راه حل مناسب جهت طراحی و اجرای برنامه های توزیع شده حضوری موفق در عرصه برنامه های توزیع شده داشت. پس از مدت زمانی رویكرد فوق با دو چالش جدی مواجه گردید:

۱- برنامه نویسان مجبور بودند كه نام و یا آدرس سرویس دهنده و شماره پورت مورد نیاز جهت ارتباط را در Source برنامه های مستقیما مشخص نمایند.
۲- برنامه نویسان گوناگون می توانستند از پورت های یكسان برای برنامه های متفاوت استفاده نمایند.

بدیهی است در چنین حالتی Conflict بین شماره پورت ها امری اجتناب ناپذیر بود. بمنظور برخورد با دو چالش فوق، كمیته یونیكیس مفهوم ارتباطات مبتنی بر RPC را مطرح كرد. بر اساس رویكرد فوق برنامه ای با نام Portmapper بر روی هر سرویس دهنده اجرا و بین برنامه های اجرائی بر روی سیستم های متفاوت حكمیت خواهد كرد. بر این اساس هر برنامه بجای تلاش جهت ایجاد یك ارتباط با یك پورت خاص بر روی یك سیستم، درخواست خود را برای Portmapper ارسال و وی مسئول ایجاد اطلاعات لازم جهت ارتباط خواهد بود. راه حل فوق با اینكه مسئله ارتباطات بین پردازه های توزیع شده را بگونه ای حل كرده بود، ولی در رابطه با فورمت داده های مبادله شده بین برنامه ها سكوت اختیار كرده بود. در این راستا تكنولوژی دیگری با نام eXternal Data Representation یا XDR روشی را جهت تشریح داده ها توسط یك برنامه برای برنامه دیگر تعریف نمود. می توان گفت كه 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 و مطرح گردیدنند. تمامی تكنولوژیهای فوق بدنبال ارائه تسهیلات، انعطاف پذیری بیشتر و اعتماد سازی بیشتر در برنامه های توزیع شده بودند.

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

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

۱- برنامه ها بسادگی برنامه های دیگر بر روی وب را پیدا كرده و با آنها تبادل اطلاعاتی داشته باشند.
۲- از تمامی توان اینترنت و پروتكل های مربوطه استفاده گردد.
۳- یك متدولوژی ایمن برای تبادل اطلاعاتی را ارائه نماید.

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

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

یكی دیگر از بخش های این جدول معما، یافتن پاسخی شایسته برای این سوال است كه برنامه ها چگونه یكدیگر را برای تبادل داده پیدا می كنند؟در اغلب برنامه های توزیع شده و همچنین مدل سنتی Client Server، برنامه ها می بایست به روشنی و صراحت لهجه در رابطه با برنامه ها و روتین هائی كه می خواهند با آنها در ارتباط باشند، آگاهی لازم را كسب نمایند. استفاده از درج كد بصورت مستقیم در متن برنامه ها ما را دچار مشكلاتی خواهدا كرد كه در رابطه با تبادل داده ها نیز به آن اشاره شد یعنی تغییر ساختار یك برنامه یا معرفی یك برنامه بعنوان یك برنامه توزیع شده را كاری بس مشكل خواهد كرد. تفكیك برنامه ها از یكدیگر یكی از بزرگترین چالش ها و یكی از مهمترین رویكردها در رابطه با سرویس های وب است. 

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

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

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

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

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

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

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

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

در این مقاله به شرح نسبتا كاملی از سرویس های وب پرداخته شد ولی هنوز ما با سوالات متعددی روبرو هستیم: نحوه ارتباط سرویس های وب مایكروسافت با سرویس های وب سایر شركت های رقیب نظیر Sun، IBM، BEA به چه صورت است؟ دات نت برای خانواده بزرگ محصولات مایكروسافت چه سرنوشتی را رقم خواهد زد؟ آیا می بایست در انتظار نسخه هائی نظیر Office.NET، SQL Server.NET، و یا حتی بازی معروف Age of Empires.NET باشیم؟ فقط گذشت زمان است كه پاسخی شایسته برای هر یك از سوالات فوق و نظایر این نوع سوالات را خواهد داد. مایكروسافت و سایر رقبای سرویس های وب آن در حال حاضر مباحث بسیار مهمی را در رابطه با استاندارد نمودن SOAP و UDDI و سایر بخش های دات نت دنبال می كنند. نتایج مباحث فوق، درجه و میزان ارتباط پذیری بین محصولات رقبا را مشخص خواهد كرد. از همه اینها گذشته یك خبر مسرت بخش این است كه حتی اگر نتایج مباحث در جریان موفقیت آمیز نباشد، با استفاده از XML همچنان می شود داعیه ارتباط پذیری بین سرویس های وب را دنبال كرد(با مشكل و كندی، ولی چاره چیست!).

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

بهرحال علیرغم تمامی مباحث و موارد گفته شده، مهم این است كه ما از مرحله پردازش سنتی متكی بر Client Server و متدولوژیهای برنامه نویسی توزیع شده به یك مدل جدید متكی بر XML و بستر اینترنت دست یافته ایم و یك حس درونی و شیرین به ما می گوید این مدل را هر كس هر چه می خواهد بنامد. دات نت و یا...!