تبلیغات
تبلیغات متنی
محبوبترینها
قیمت انواع دستگاه تصفیه آب خانگی در ایران
نمایش جنگ دینامیت شو در تهران [از بیوگرافی میلاد صالح پور تا خرید بلیط]
9 روش جرم گیری ماشین لباسشویی سامسونگ برای از بین بردن بوی بد
ساندویچ پانل: بهترین گزینه برای ساخت و ساز سریع
خرید بیمه، استعلام و مقایسه انواع بیمه درمان ✅?
پروازهای مشهد به دبی چه زمانی ارزان می‌شوند؟
تجربه غذاهای فرانسوی در قلب پاریس بهترین رستوران‌ها و کافه‌ها
دلایل زنگ زدن فلزات و روش های جلوگیری از آن
خرید بلیط چارتر هواپیمایی ماهان _ ماهان گشت
سیگنال در ترید چیست؟ بررسی انواع سیگنال در ترید
بهترین هدیه تولد برای متولدین زمستان: هدیه‌های کاربردی برای روزهای سرد
صفحه اول
آرشیو مطالب
ورود/عضویت
هواشناسی
قیمت طلا سکه و ارز
قیمت خودرو
مطالب در سایت شما
تبادل لینک
ارتباط با ما
مطالب سایت سرگرمی سبک زندگی سینما و تلویزیون فرهنگ و هنر پزشکی و سلامت اجتماع و خانواده تصویری دین و اندیشه ورزش اقتصادی سیاسی حوادث علم و فناوری سایتهای دانلود گوناگون
مطالب سایت سرگرمی سبک زندگی سینما و تلویزیون فرهنگ و هنر پزشکی و سلامت اجتماع و خانواده تصویری دین و اندیشه ورزش اقتصادی سیاسی حوادث علم و فناوری سایتهای دانلود گوناگون
آمار وبسایت
تعداد کل بازدیدها :
1833590200
معماری سرويس های وب
واضح آرشیو وب فارسی:راسخون:
معماری سرويس های وب سرويس های وب يکی از مهمترين تحولات اخير در زمينه نرم افزار بوده که قطعا" دستاوردهای فراوانی را در ارتباط با طراحی و پياده سازی نرم افزار ، بدنبال خواهد داشت . سرويس های وب ، تسهيلات لازم بمنظورايجاد نسل جديدی از برنامه های وب را ارائه می نمايند. در مجموعه مقالاتی که ارائه گرديد با مفاهيم اوليه سرويس های وب آشنا شديم . در ادامه سلسله مباحث مربوط به سرويس های وب ، به بررسی معماری آنان خواهيم پرداخت .مقدمه بمنظور ايجاد برنامه های توزيع شده قدرتمند و انعطاف پذير ، موارد متعددی وجود دارد که می بايست به آنها توجه گردد: • در موارديکه قصد ارتبا ط بين منابع نرم افزاری وجود داشته باشد ، منابع می بايست بدرستی و بخوبی با يکديگر مرتبط گردند( منابع مشخص و از يکديگر متمايز گردند). • ارتباط بين برنامه ها می بايست متکی بر استانداردهای اينترنت باشد . • اينترفيس های ( بخش های مرتبط با استفاده کننده ) منابع نرم افزاری ، می بايست برای استفاده عموم منتشر و امکان دسترسی به تعاريف اينترفيس بهمراه مستندات مربوطه وجود داشته باشد . برنامه هائی که با لحاظ نمودن موارد فوق ، طراحی و پياده سازی می گردند ، مزايای زير را بدنبال خواهند داشت : • می توان از سرويس های نرم افزاری و منابع خارجی بمنظور طراحی و پياده سازی نرم افزار مورد نظر خود استفاده کرد. • امکان ايجاد منابع نرم افزاری بيشتری بصورت ماژولار ، وجود خواهد داشت ( کيت های نرم افزاری با قابليت استفاده مجدد ) . • هزينه توليد نرم افزار کاهش و بهره وری افزايش خواهد يافت . • مطرح شدن ايده عرضه نرم افزار بعنوان سرويس . بدين ترتيب در مقابل عرضه يک نرم افزار 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 پيکربندی می گردند .
این صفحه را در گوگل محبوب کنید
[ارسال شده از: راسخون]
[مشاهده در: www.rasekhoon.net]
[تعداد بازديد از اين مطلب: 382]
-
گوناگون
پربازدیدترینها