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