معماری سرویس های وب

سرویس های وب یکی از مهمترین تحولات اخیر در زمینه نرم افزار بوده که قطعا" دستاوردهای فراوانی را در ارتباط با طراحی و پیاده سازی نرم افزار ، بدنبال خواهد داشت . سرویس های وب ، تسهیلات لازم بمنظورایجاد نسل جدیدی از برنامه های وب را ارائه می نمایند. در مجموعه مقالاتی که ارائه گردید با مفاهیم اولیه سرویس های وب آشنا شدیم . در ادامه سلسله مباحث مربوط به سرویس های وب ، به بررسی معماری آنان خواهیم پرداخت .
●مقدمه
بمنظور ایجاد برنامه های توزیع شده قدرتمند و انعطاف پذیر ، موارد متعددی وجود دارد که می بایست به آنها توجه گردد:
▪در مواردیکه قصد ارتبا ط بین منابع نرم افزاری وجود داشته باشد ، منابع می بایست بدرستی و بخوبی با یکدیگر مرتبط گردند( منابع مشخص و از یکدیگر متمایز گردند).
▪ارتباط بین برنامه ها می بایست متکی بر استانداردهای اینترنت باشد .
اینترفیس های ( بخش های مرتبط با استفاده کننده ) منابع نرم افزاری ، می بایست برای استفاده عموم منتشر و امکان دسترسی به تعاریف ▪اینترفیس بهمراه مستندات مربوطه وجود داشته باشد .
برنامه هائی که با لحاظ نمودن موارد فوق ، طراحی و پیاده سازی می گردند ، مزایای زیر را بدنبال خواهند داشت :
▪می توان از سرویس های نرم افزاری و منابع خارجی بمنظور طراحی و پیاده سازی نرم افزار مورد نظر خود استفاده کرد.
▪امکان ایجاد منابع نرم افزاری بیشتری بصورت ماژولار ، وجود خواهد داشت ( کیت های نرم افزاری با قابلیت استفاده مجدد ) .
▪هزینه تولید نرم افزار کاهش و بهره وری افزایش خواهد یافت .
▪مطرح شدن ایده عرضه نرم افزار بعنوان سرویس . بدین ترتیب در مقابل عرضه یک نرم افزار Stand-alone ، می توان از رویکرد نرم افزار بعنوان سرویس ، استفاده نمود.
●عناصر معماری مبتنی بر سرویس
معماری مبتنی بر سرویس برای پیاده سازی برنامه های توزیع شده ،ایده آل می باشد . معماری فوق ،امکان پیاده سازی پویا ، آزاد و گسترده برنامه های توزیع شده را فراهم می نماید.
امروزه شاهد بکارگیری سیستم های متعددی می باشیم که خود از چندین برنامه و یا زیر سیستم استفاده می نمایند. با توجه به ارتباط بین سیستمها با یکدیگر ، ایجاد و اعمال یک تغییر در ارتباط با هر یک از زیر سیستمها می تواند باعث بروز اشکال در تعداد زیادی از عناصر وابسته و یا سایر برنامه ها گردد . رویکرد فوق ، افزایش هزینه نگهداری این نوع سیستم ها را بدنبال خواهد داشت .
معماری مبتنی بر سرویس ، وابسته به سه عنصر اساسی است که هر یک دارای جایگاه خاص خود می باشند : Service Provider ( ارائه دهنده سرویس ) ، Service consumer ( مصرف کننده سرویس ) و Service broker ( کارگزار سرویس ) . .
●ارائه دهنده سرویس ، گره ای در شبکه ( اینترانت و یا اینترنت ) است که امکان دستیابی به اینترفیس یک سرویس نرم افزاری را فراهم می نماید . گره ارائه دهنده سرویس ، امکان دستیابی به سرویس های یک سیستم تجاری ، یک زیر سیستم و یا یک عنصر را بوجود می آورد .مصرف کننده سرویس ، گره ای در شبکه است که به سرویس ارائه شده توسط یک ارائه دهنده سرویس مرتبط و از امکانات و پتانسیل های سرویس ارائه شده در جهت پیاده سازی سیستم خود استفاده می نماید. مصرف کننده سرویس را می توان بمنزله یک برنامه سرویس گیرنده بر روی یک گره در نظر گرفت . کارگزار سرویس ، گره ای در شبکه است که مسئول تشریح سرویس را برعهده داشته و می توان آن را بمنزله یک دفترچه آدرس در نظر گرفت که برای جستجو و یافتن سرویس ، مورد استفاده قرار می گیرد. مصرف کننده سرویس ( متقاضی ) ، درخواست خود را در ارتباط با سرویس موردنظر به کارگزار ارائه و کارگزار، سرویس درخواستی بهمراه ارائه دهنده مورد نظر را پیدا می نماید .
●ارتبا ط بین وظایف سه گانه
عناصر سه گانه اشاره شده در معماری مبتنی بر سرویس ، با یکدیگر مرتبط تا زمینه تحقق عملیات زیر فراهم گردد :
▪عرضه سرویس .
ارائه دهندگان سرویس ، سرویس ها ی خود را برای یک کارگزار سرویس ، عرضه می نمایند ( ثبت در دفترچه آدرس ) . اطلاعات ارائه شده شامل : تعریف اینترفیس سرویس ، محل ارائه دهندگان سرویس ، سایر اطلاعات حمایتی و یا مستندات ضروری خواهد بود.
▪یافتن سرویس .
مصرف کنندگان ، سرویس ها ی مورد نیاز خود را با کمک یک کارگزار ، پیدا خواهند کرد .
▪ارتباط به سرویس .
مصرف کنندگان سرویس به سرویس های خاصی که توسط یک ارائه دهنده سرویس ارائه شده است ، مرتبط و زمینه استفاده آنان از سرویس مورد نظر فراهم خواهد شد. فرآیند فوق ، شامل تائید مصرف کنندگان خواهد بود.
عملیات یافتن و نسبت دهی سرویس ها می تواند بصورت پویا انجام گیرد . بدین ترتیب برنامه ها قادر خواهند بود بصورت پویا خود را پیکربندی نمایند. مثلا" اگربرنامه ای تشخیص دهد که مدت زمان پاسخ از یک ارائه دهنده سرویس ، زمانی غیر معقول است ، می تواند در زمان اجراء ، تصمیم بر استفاده از یک ارائه دهنده سرویس دیگر نماید .
●معماری سرویس های وب و معماری مبتنی بر سرویس
عناصر اساسی در معماری سرویس وب عبارتند از :
▪ارائه دهنده سرویس وب .
گره ای در شبکه که مسئولیت میزبان نمودن یک سرویس وب را برعهده خواهد داشت .
▪مصرف کننده سرویس .
گره ای در شبکه که مسئولیت میزبان نمودن هر سرویس گیرنده ای را که قادر به ارتباط با استفاده از HTTP باشد را برعهده می گیرد. مرورگرها ، برنامه های کنسول و برنامه هائی با رابط کار گرافیکی سنتی ، نمونه هائی از برنامه های سرویس گیرنده می باشند.
▪کارگزار سرویس وب.
گره ای در شبکه که مسئولیت میزبان نمودن یک ریجستری سراسری از تمامی سرویس های وب در دسترس را برعهده خواهد داشت .( نظیر یک کتاب آدرس جامع ) .
تمامی گره های فوق ، قادر به ارتباط با یکدیگر از طریق شبکه های مبتنی بر پروتکل TCP/IP می باشند . در سرویس های وب ، سه گره تعریف شده در معماری مبتنی بر سرویس ، متناظر با عناصر سرویس های وب خواهند بود:
کارگزار سرویس ، مسئولیت میزبان نمودن UDDI)Universal Description,Discovery and Integration ) را برعهده خواهد داشت .
ارائه دهنده سرویس ، مسئولیت عرضه سرویس های وب از طریق صفحات ASP.NET با انشعاب asmx . را برعهده خواهد داشت .
مصرف کننده سرویس ، قابلیت برقراری ارتباط از طریق HTTP ویا SOAP)Simple Object Access Protocol) را دارا می باشد .
همانگونه که اشاره گردید، در معماری یک سرویس وب از سه عنصر اساسی استفاده می شود : ارائه دهنده سرویس وب ، استفاده کننده سرویس وب و کارگزار سرویس وب . در ادامه به تشریح هر یک از عناصر فوق خواهیم پرداخت . ( در این بخش از مقاله به بررسی ارائه دهنده سرویس پرداخته و در بخش دوم این مقاله ، مصرف کننده سرویس و کارگزار سرویس ، تشریح خواهند شد ) .
●ارائه دهنده سرویس
یکی از مهمترین عناصر در معماری سرویس وب ، جایگاه و نقش ارائه دهنده سرویس است . زیرساخت ایجاد شده توسط ارائه دهنده سرویس ، امکانات لازم حمایتی و میزبان نمودن سرویس های وب رافراهم می نماید. قابلیت پردازش پروتکل HTTP و سرویس اعتبار سنجی ، نمونه هائی از زیر ساخت ارائه شده توسط ارائه دهنده سرویس می باشند. درصورتیکه ارائه دهنده سرویس قادر به ارائه چنین زیرساختی نباشد ، سرویس وب می بایست خود این زیر ساخت را حمایت نماید .وضعیت فوق، طراحی و پیاده سازی سرویس های وب را با مشکل بیشتر مواجه خواهد کرد.
●سرویس دهنده وب
یک ارائه دهنده سرویس می بایست حداقل شامل یک گوش دهنده ( listener ) پروتکل باشد . برای سرویس های وبی که توسط فریمورک دات نت و یا ویژوال استودیو دات نت ، پیاده سازی می گردند ، گوش دهنده پروتکل می بایست یک HTTP listener باشد . با توجه به اینکه یک ارائه دهنده سرویس قادر به میزبان نمودن چندین سرویس وب خواهدبود ،ارائه دهنده سرویس ،می بایست امکان هدایت مناسب یک درخواست به سرویس وب مناسب را دارا باشد . ( قابل مقایسه با سرویس RPCCC) Remote Procedure Call Subsystem)، که مسئولیت پاسخگوئی به درخواست های وارده DCOM وهدایت آنان به یک سرویس دهنده مناسب COM است) .مصرف کنندگان ناشناخته سرویس وب ، قادر به دستیابی به یک ارائه دهنده سرویس می باشند . بنابراین لازم است ، سرویس دهنده وب سرویس های پایه امنیتی را حداقل در سطح پروتکل، ارائه نماید. IIS ، که یک سرویس دهنده وب است ، سرویس های مورد نیاز یک سرویس وب را ارائه می نماید :
▪IIS یک HTTP listener است
▪IIS با استفاده از معماری ISAPI ، می تواند بعنوان یک gateway در رابطه با سرویس های وب رفتار نموده و علاوه بر میزبانی از سرویس های وب متعدد ، زمینه هدایت صحیح آنان را نیز فراهم نماید.
▪IIS زیرساخت قابل ملاحظه ای در رابطه با امنیت را ارائه می نماید .
●IIS و سرویس های وب
یک سرویس دهنده وب نظیر IIS ، قادر به فراخوانی یک سرویس از جانب یک سرویس گیرنده با استفاده از گزینه های متعددی است . سرویس دهنده وب قادر به فعال نمودن ( اجراء ) یک برنامه CGI)Common Gateway Interface) ، اجرای یک مفسر اسکریپت بمنظور برخورد با صفحات ASP و یا فراخوانی یک برنامه ISAPI است .زمانیکه IIS همراه با CLR فعالیت می نماید ، از یک فیلتر ISAPI بمنظوربررسی درخواست هائی در ارتباط با صفحات با انشعاب asmx استفاده و در ادامه یک میزبان زمان اجراء را فعال می نماید . میزبان زمان اجراء ، کد مربوط به سرویس وب را که توسط فریمورک دات نت پیاده سازی شده است ، اجراء خواهد کرد.
●مصرف کننده سرویس
در این بخش با حداقل قابلیت های موردنیاز یک مصرف کننده سرویس وب بمنظور استفاده از یک سرویس وب ، نحوه یافتن یک سرویس وب توسط مصرف کننده سرویس وب ، نقش پروکسی ها در پیاده سازی مصرف کنندگان سرویس وب ونحوه استفاده از پروکسی ها بمنظور فراخوانی غیرهمزمان سرویس های وب ، آشنا خواهیم شد .
●حداقل توانائی : بمنظور استفاده از سرویس وب ، یک مصرف کننده سرویس وب ، می بایست متدهائی از سرویس وب را بهمراه پارامترهای مورد نیاز و بکمک استفاده از پروتکل های موجود ( مثلا" SOAP ) و حمایت شده توسط سرویس مورد نظر را فراخوانی نماید . فرمت دهی مناسب پیام ها قبل از ارسال برای یک سرویس وب ، آشنائی و برخورد مناسب با جزئیات پروتکل هائی که سرویس وب حمایت می نماید، از جمله مواردی می باشند که می تواند چالش هائی را در زمینه سرویس های وب بدنبال داشته باشد. فریمورک دات نت با ارائه کلاس هائی در این زمینه اکثر جزئیات سطح پائین را کپسوله می نماید . کپسوله نمودن جزئیات سطح پائین ، ضرورت پیاده سازی زیرساخت را از پیاده کنندگان سلب و آنان را از این فعالیت معاف می نماید .
●مکان یابی سرویس : قبل از امکان استفاده از یک سرویس وب ،مصرف کننده می بایست قادر به یافتن آن باشد . یکی از راهکارهای موجود در این زمینه درج کد بصورت دستی ( برخوردی کاملا" ایستا ) در مصرف کننده سرویس وب و در هنگام طراحی است .در چنین مواردی آدرس سرویس ارائه شده بصورت مستقیم در برنامه مصرف کننده سرویس درج خواهد شد . یکی دیگر از راهکارهای موجود در این زمینه ، امکان یافتن پویای یک سرویس وب توسط مصرف کننده سرویس وب و در زمان اجراء است . بدین ترتیب ، مصرف کننده سرویس وب دارای انعطاف لازم در خصوص انتخاب بین سرویس های وب رقیب با عملکرد مشابه و بر اساس ویژگی هائی خاص نظیر قیمت و کارآئی ، خواهد بود . روش استاندارد برای یافتن سرویس های وب ، تشریح سرویس و خدمات ارائه شده توسط آنان ، استفاده از یک ریجستری UDDI است . ( Universal Description,Discovery, and Integration )
●پروکسی ها : در زمان پیاده سازی یک مصرف کننده سرویس وب ، پیاده کنندگان می توانند زمان خود را صرف افزایش بهره وری نموده و خود را درگیر موارد زیر ننمایند .
▪فعالیت و در گیر شدن در ارتباط با پروتکل های زیربنائی
▪پارسینگ بایت ها بمنظور استخراج داده
▪بررسی صحت و اعتبار داده های ورودی ( دریافتی )▪ایجاد و ساخت بسته های اطلاعاتی بمنظور خروجی
علیرغم توصیه های انجام شده ، اغلب پیاده کنندگان بمنظور انجام عملیات فوق ، وقت خود را صرف انجام فعالیت های فوق می نمایند ، چراکه در این رابطه کد از قبل ایجاد شده ای وجود ندارد. یکی از رویکردهای متداول در این زمینه (هندل نمودن فعالیت ها ی فوق ) ، کپسوله سازی و یا پنهان نمودن جزئیات پیاده سازی در کلاسی است که بعنوان یک پروکسی برای سرویس وب ، رفتار می نماید . کلاس های پروکسی علاوه بر پنهان سازی جزئیات پیاده سازی ، یک مدل برنامه نویسی شناخته شده را بمنظور فراخوانی متدهای اشیاء در اختیار پیاده کنندگان قرار خواهند داد. تنها مسئله مرتبط با روش فوق ، پیاده سازی یک کلاس پروکسی برای هر اینترفیس سرویس وبی خواهد بود که یک مصرف کننده سرویس وب از آن بمنظور ارتباط استفاده خواهد کرد . مایکروسافت در این رابطه ابزاری با نام Wsdl.exe را ارائه که می توان از آن بمنظور پیاده سازی کلاس های پروکسی سرویس وب استفاده نمود. باتوجه به اینکه، یک اینترفیس سرویس وب با استفاده از XML تعریف می گردد ، شایسته تر است که ابزارهائی را ایجاد که قادر به تولید اتوماتیک کلاس های پروکسی باشند .
●فراخوانی غیرهمزمان : با توجه به اینکه دستیابی به سرویس های وب عموما" از طریق شبکه ها ( نظیر اینترنت ) که عمدتا" قابلیت اطمینان و سرعت شبکه های محلی را ندارند ،میسر می گردد ، شاید مناسبتر باشد که مصرف کنندگان سرویس وب ، بگونه ای پیاده سازی گردند که قادر به ایجاد فراخوانی غیرهمزمان به سرویس های وب باشند . پروکسی ها ئی که با استفاده از Wsdl.exe تولید و ایجاد می گردند ، این امکان را به صدازنندگان سرویس خواهند داد که فراخوانی غیرهمزمان به یک سرویس وب را داشته باشند. کلاس پروکسی با ترکیب RunTime ، مسئولیت برخورد با جزئیات مدیریت Thread pool ، اتمام یک متد callback notification و سایر موارد مرتبط را برعهده خواهند داشت .
●نمونه هائی از مصرف کنندگان سرویس وب : برنامه های تجاری ( زمینه های متعدد تجاری ) اولین کاربران و متقاضیان سرویس های وب می باشند ولی تعداد زیادی فعالیت تجاری دیگر نیز وجود دارد که می توانند بعنوان مصرف کنندگان سرویس وب مطرح گردند . روزنامه های Online و ASP :Application Service Provider ، دو نمونه در این زمینه می باشند . یک روزنامه Online ، ممکن است از جندین سرویس وب خبری بمنظور تامین اخبار نشریه خود استفاده نماید . اخبار ورودی می توانند قالب بندی و فیلتر شده و برای آنان فهرست توصیفی تهیه و قابلیت جستجو بر روی آنان با توجه به خواست مصرف کننده ایجاد گردد . یک ASP ممکن است سرویس های وب متعددی را میزبان و یا خود راسا" اقدام به تولید سرویس های وب مورد نیاز و ارائه آنان به مشتریان مربوطه نماید.
●کارگزار سرویس وب
همانگونه که یک معماری مبتنی بر سرویس نیازمند یک کارگزار سرویس است ، یک معماری سرویس وب ، نیز نیازمند یک کارگزار سرویس خواهد بود. بمنظور تسهیل در ارتباط ، بنگاههای تجاری نیازمند یک راه حل جامع و فراگیر بمنظور نشر اطلاعات خود به هر یک از مشتریان و یا شرکاء تجاری خود در سطح جهان می باشند .یک کارگزار سرویس وب ، هم با ارائه دهنده سرویس وب و هم با مصرف کننده سرویس وب ارتباط تا زمینه استفاده از امکانات ارائه شده توسط ارائه دهندگان سرویس های وب و استفاده از سرویس های وب ارئه شده برای مصرف کنندگان سرویس های وب ، فراهم گردد. سازمان ها با نشر اطلاعات مرتبط با سرویس ها و خدمات تجاری خود ، به پتانسیل های زیر دست خواهند یافت :
▪امکان یافتن سریع همکاران تجاری از بین میلیون ها بنگاه تجاری Online
▪تعریف نحوه مدیریت فعالیت های تجاری پس از یافتن بنگاههای تجاری مورد نظر
▪ایجاد یک رویکرد گسترده صنعتی برای فعالیت های تجاری که ارتباط و همبستگی سریع و آسان با مشتریان و شرکاء تجاری بر روی اینترنت را بدنبال خواهد داشت .در این رابطه ، سازمانها قادر به ارائه اطلاعات مشترک در ارتباط با محصولات و خدمات خود بوده و امکان حق انتخاب در رابطه با گزینش نوع ارتباط با سایر فرآیندهای تجاری و سیستم ها نیز فراهم می گردد .
●ارتباط بین کارگزار سرویس وب و ارائه دهنده سرویس وب : کارگزاران بمنظور ارائه صحیح سرویس های وب از ارائه دهندگان سرویس های وب درخواست اطلاعات متنوعی در رابطه با سرویس ارائه شده را خواهند داشت . اطلاعات اخذ شده بمنزله شناسنامه یک سرویس وب خواهد بود که پس از ارائه و تائید و طی مراحل مربوطه در ریجستری UDDI ذخیره تا امکان در اختیار قرار دادن آنان برای مصرف کنند گان سرویس های وب فراهم گردد .کارگزاران سرویس های وب ، اطلاعات عمومی زیر را در ارتباط با یک سرویس وب منتشر خواهند کرد :
▪اطلاعات طبقه بندی شده ای که امکان گروه بندی سرویس وب را فراهم نماید .
▪اطلاعات مورد نیاز بمنظور ارتباط با سرویس وب
▪شرح خدمات ارائه شده توسط سرویس های وب
▪لینک های مورد نیاز بمنظور استفاده از سایر مستندات که شامل اطلاعاتی در رابطه با سرویس وب است .
▪آدرس ( مکان ) نهائی سرویس های وب . آدرس های فوق ، عموما" بصورت URL)Uniform Resource Locators) بوده و مکان و موقعیت سرویس های وب اعلام شده را مشخص می نمایند . با توجه به عدم توانائی ذخیره سازی تمامی اطلاعات بر روی رسانه های ذخیره سازی کارگزار سرویس وب ، از اشاره گرهائی خاص در این زمینه استفاده که باعث تسهیل در یافتن اطلاعات تکمیلی و مورد نیاز در ارتباط با سرویس وب خواهد بود. ماهیت برخی از اطلاعات مرتبط با یک سرویس وب نیز بگونه ای است که امکان استقرار آنان بر روی کارگزار وجود نداشته و می بایست از لینک های مورد نظر و معرفی شده توسط کارگزار بمنظور اخذ اطلاعات تکمیلی استفاده گردد (اطلاعات مرتبط با ملزومات مورد نیاز برای تائید اعتبار) .
●ارتباط بین کارگزار و مصرف کننده سرویس : اولین و در عین حال مهمترین نوع ارتباط بین مصرف کنندگان سرویس وب و کارگزار سرویس وب ، جستجو برای یافتن سرویس وب است . کارگزاران می بایست تسهیلات لازم در خصوص جستجوی سرویس های وب را فراهم تا امکان یافتن آنان بسادگی و با سرعت مناسب برای مصرف کنندگان ، فراهم گردد .
●ریجسترهای UDDI : کارگزاران ، بمنظور ارائه سرویس های وب از رویکردهای متعددی استفاده می شود . یکی از ساده ترین رویکردهای موجود در این زمینه ، استفاده از یک روش خاص با توجه به هدف مورد نظر برای مبادله اطلاعات و الزام تمامی همکاران تجاری برای تبعیت از آن است . در این رویکرد ،عملا" به یک کارگزار نیاز نخواهد بود . مثلا" برخی سازمانها از مبادله اطلاعات الکترونیکی ( EDI:Electronic Data Interchange ) استفاده و بسادگی مستندات EDI مورد نیاز همکاران تجاری را بر روی سایت سازمان خود قرار می دهند .در رابطه با رویکرد فوق ، می بایست به این نکته ( مسئله) اشاره نمود که روش فوق ، مکانیزم مناسب و ساده ای برای یافتن فعالیت های تجاری خارجی و سازگار با فعالیت تجاری سازمان مربوطه ، نخواهد بود .
یکی دیگر از رویکردهای موجود در این زمینه ، الزام تمامی همکاران تجاری برای استقرار یک فایل خاص بمنظور تشریح سرویس وب بر روی سایت های خود می باشد . در ادامه جستجو کننده وب می تواند بصورت اتوماتیک به یک URL ریجستر شده، دستیابی و ایندکس مناسبی از هر یک از فایل های تشریح سرویس های وب که بر روی هر یک از سایت ها پیدا می نماید ، ایجاد نماید . یک کارگزار سرویس وب می تواند در ادامه یک Portal را ایجاد که امکان دستیابی به ایندکس هائی که جستجو کننده وب آنها را ایجاد نموده است ، فراهم گردد. اتکاء و وابستگی به جستجو کنندگان وب برای ارائه ایندکس های سرویس های وب دارای مسائل مشابهی با روش استاندارد موتورهای جستجو است که ما امروزه با آن سروکار داریم . مشکل اساسی رویکرد فوق ، عدم وجود مکانیزم لازم بمنظور اطمینان از انسجام و یکنواختی در فرمت تشریح سرویس و ردیابی آسان و آگاهی از زمان مورد نظر دررابطه تغییرات اعمال شده است . همانگونه که ممکن است یک موتور جستجوی وب تعداد زیادی لینک غیر معتبر را برگرداند ، استفاده از روش فوق در ارتباط با سرویس های وب نیز ممکن است نتایج غیر معتبری در ارتباط با تشریح سرویس ها را ارائه نماید.
رویکرد کارگزاری ، که در ارتباط با سرویس های وب انتخاب شده است ، مبتنی بر یک ریجستری توزیع شده از بنگاههای تجاری و تشریح سرویس های مربوطه آنان با فرمت XML است . راه حل ارائه شده بمنظور پیاده سازی رویکرد فوق و برطرف نمودن مسئله یافتن سرویس های وب ، UDDI ) Universal Description,Discovery, and Integration ) نامیده می شود .
UDDI ، مشخصه ای برای اطلاعات مبتنی بر وب توزیع شده از سرویس های وب ریجستر شده است . با استفاده از UDDI ، بنگاه های تجاری قادر به ریجستر نمودن اطلاعات مرتبط با سرویس های خود بوده و بنگاه های تجاری متقاضی ، قادر به یافتن و استفاده از سرویس های وب خواهند بود . عنصر اساسی در یک ریجستری UDDI ، فایلی است که موجودیت یک بنگاه تجاری را بهمراه سرویس های وب مربوطه آن تشریح می نماید . اطلاعات مورد نظر بمنظور ریجستر نمودن یک فعالیت تجاری از سه بخش اساسی تشکیل شده است :
▪آدرس بنگاه تجاری و اطلاعات لازم بمنظور ارتباط
▪لیست طبقه بندی صنعتی منطبق بر استاندارد های موجود
▪اطلاعات فنی در رابطه با سرویس های وب عرضه شده توسط بنگاه تجاری . اطلاعات فوق ، شامل مرجع لازم به مشخصه های اینترفیس سرویس وب ، پتانسیل ها واشاره گرهائی به فایل های متعدد اطلاعاتی است.
●مدل برنامه نویسی سرویس های وب
بمنظور پیاده سازی و یا استفاده از یک سرویس وب ، لازم است با ویژگی های اساسی مدل برنامه نویسی سرویس های وب آشنا شویم .
●پروتکل های وب :
اولین ویژگی مدل برنامه نویسی سرویس های وب ، پروتکل ارتباطی است که معمولا" HTTP خواهد بود. پروتکل HTTP ، بطور ذاتی مفهوم استفاده از یک متد را حمایت نمی نماید . با توجه به محدودیت فوق ، مصرف کنندگان سرویس های وب اغلب از XML-Based SOAP ، بر روی HTTP برای فراخوانی ( صدا زدن ) متدهای سرویس های وب استفاده می نمایند . بنابراین ، لازم است پیاده کنندگان دارای دانش مناسبی در ارتباط با پروتکل HTTP و SOAP باشند .
●StateLess :
اکثر پیاده کنندگان با یک مدل شی Stateful آشنائی لازم را دارند. بعبارت دیگر ، نمونه ای از یک کلاس ایجاد و در ادامه عملیات متفاوتی بر روی شی انجام خواهدشد . بین هر فراخوانی متد ، شی وضعیت خود را نگهداری می نماید . در یک محیط stateless ، شی وضعیت خود را بین فراخوانی ها ، نگهداری نمی نماید. هر وضعیتی که می بایست بین فراخوانی ها نگهداری گردد ، در یک بانک اطلاعاتی و یا کوکی ذخیره می گردد . سرویس های وب اشیائی با رویکردهای سنتی نمی باشند. زمانیکه از ASP.NET بمنظور پیاده سازی یک سرویس وب استفاده می گردد ، می توان از یک کلاس سی شارپ بمنظور پیاده سازی آن استفاده نمود. صفحات ASP.NET برای مراجعه به کلاس فوق ، از یک فایل با انشعاب asmx . استفاده می نمایند. زمانیکه صفحه پردازش می گردد ، یک نمونه از کلاس ایجاد می گردد . مدت زمان حیات صفحه asmx . ، به عمر شی نتیجه محدود و یک نمونه شی متفاوت دیگر سایر فراخوانی ها به متد را پاسخ خواهد داد بنابراین ، کلاس هائی که یک سرویس وب را پیاده سازی می نمایند ، Stateless خواهند بود . با اینکه طراحی سیستم های Stateless در مرحله اول مشکل تر بنظر می آید ولی همزمان با افزایش حجم عملیاتی سیستم ، توان آنان در سرویس دهی افزایش خواهد یافت .
●Loosely coupled .
در یک برنامه غیر توزیع شده ، اگر هر یک از منابع نرم افزاری مورد نیاز، نظیر یک تابع کتابخانه ای در یک DLL)Dynamic Link Library) ، زمانیکه یک برنامه فعال می گردد در دسترس باشند ، امکان دستیابی به منابع فوق در مدت زمان حیات نرم افزار ، میسر خواهد بود . برای برنامه های توزیع شده ، خصوصا" برنامه های توزیع شده ای که از منابع نرم افزاری بر روی اینترنت استفاده می نمایند ، ممکن است منابع نرم افزاری مورد نیاز همواره در دسترس نباشند. برنامه های توزیع شده که با استفاده از سرویس های وب پیاده سازی می گردند ، می بایست دارای انعطاف لازم و بمراتب بیشتری در ارتباط با منابع نرم افزاری غیرقابل دسترس حتی در زمان اجراء باشند . بنابراین ، راه حل های مبتنی بر سرویس های وب ، می بایست دارای پتانسیل لازم بمنظور پیکربندی مجدد و پویای خود باشند (در مواردیکه منبع مورد نیاز دردسترس نمی باشد ) .
●فرمت عمومی داده
فرمت عمومی داده در سرویس های وب ، XML است . در این رابطه ذکر نکات زیر ضروری است :
▪پروتکل SOAP مبتنی بر XML است .
▪داده برگردانده شده از یک سرویس وب ، یک سند XML است .
▪سرویس های وب با استفاده از اسناد XML در یک ریجستری UDDI ریجستر می گردند .
▪برنامه های ASP.NET با استفاده از فایل های پیکربندی XML پیکربندی می گردند .

منبع : شرکت سخاروش